Subject: [Ecrit] RE: Review of draft-ietf-ecrit-service-urn-02

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 10 Apr 2006 14:24:47 -0400

Re: 1-800-LAWYER.  The number you gave (1-800-Lawyer) is an e.164
telephone number.  To make this work using service urns, you would have
to have the result of an enum dip for this number result in a urn that
is not currently a valid enum service.  However, if you did make a new
service, it would work:

e.164 is looked up in enum
result is service urn
urn is mapped with LoST
call is sent where indicated, based on location of caller.

Now, the caller would have to voluntarily put location on the call for
this to work.

I read:
   Apart from attempting resolution of a URN, a URN namespace may
       provide mechanisms for "validating" a URN -- i.e., determining
       whether a given string is currently a validly-assigned URN.   

quite literally.  urn:service.sos is a validly-assigned URN because
there is an RFC that says it is (which is the same as saying it's in the
IANA registry of services).  "Validly-assigned" does not mean "currently
active in a domain" to me.

Brian

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Sunday, April 09, 2006 9:23 PM
To: Rosen, Brian
Cc: [email-masked]
Subject: Re: Review of draft-ietf-ecrit-service-urn-02

More responses:

On Apr 5, 2006, at 10:47 AM, Rosen, Brian wrote:

> I have reviewed service-urn-02 and have the following comments:
>
> A little concerned about 1-800-LAWYER as an example.  The problem here
> is that there is no obvious mechanism to translate the e.164
> 1-800-LAWYER to the service urn.  I suppose someone could propose an
> enumservice for this purpose, but until they do, we might consider
> removing this particular example

Removing lawyers is always a good idea. (The similarity is that  
dialing this number will get you a lawyer anywhere in the US, with  
the law office depending on where you're calling from.) I don't quite  
understand your concern about needing an enum service.

>
> You need a statement that points out the obvious: since the service  
> urn
> is a protocol labeling mechanism, it has no i18n implications.

I'll add an I18N section.

>
> My biggest problem is the DDDS stuff (section 3).  There is no
> discussion of what domain you query the DNS for.  This is an area well
> worked over by other emergency stuff, and 'fragile' because what you
> normally want is your "local" (as in access network) domain, and it's

I don't think that's really true in general. Why should my access  
network have better information about these services, particularly if  
it has no interest in VoIP or emergency calls? I suspect that,  
initially, the service lookup will be offered by the VSP. They have  
an interest and obligation to provide the service and can't wait  
until every last ISP has decided to provide a mapping service.

> not all that easy to determine what that is.  Read the HELD and LCP
> documents, and the discussion about this point.  I think this document
> needs to handle this.  I think whatever it says is likely to have  
> to be
>

I didn't see any description of this in draft-winterbottom-geopriv- 
held-sighting-00. LCP seems to define, besides the usual suspects of  
manual configuration and DHCP, a broadcast request, not specified  
further. (This would be essentially a one-off version of SLP.)

I think there are at least two plausible approaches to find an ISP- 
operated domain name, besides DHCP:

(1) SLP or Bonjour; the practical problem is that SLP is seeing  
limited new deployments and Bonjour seems to be under the cloud of  
being non-IETF-developed (but comparatively widely deployed), with  
the IETF competitor having been sent back to the WG for a do-over  
(somebody might know more about this).

(2) Inverse DNS: Get public IP address (via STUN, say); obtain domain  
name (via the usual reverse DNS lookup); use SRV or NAPTR record for  
that domain. This relies on the user's public IP address having a DNS  
entry. As far as I can tell, this seems to be almost universally true  
for residential broadband. (For enterprise users, I suspect that the  
DHCP solution is easiest.)

I had suggested a version of (2).

> the same as any other similar mechanism in the milieu (for example,  
> how
> you find your LoST server).  We need to decide what this text is, and
> copy it into all the relevant documents.

Actually, you find your LoST server via this mechanism, since it  
performs the translation.

>
> I am confused by the "Validation Mechanism" in Section 2.  First of  
> all
> the word "resource" is used here for the first time.  I am assuming it
> has the meaning of 3406 resource.  The real problem is that the  
> section
> in 3406 that talks about validity defines it as "is there a valid
> service" rather than "is the service available".  Using the DDDS
> mechanism would only tell you if a service was available (in the sense
> of configured, rather than in the sense of functioning) within a  
> domain.
> While I think you could keep most of this text if you qualify it, I
> think the actual answer is that the validation mechanism is IANA
> assignment.

I agree that this doesn't quite fit; I reread 3406 and 3406 defines  
validation thusly:

   Apart from attempting resolution of a URN, a URN namespace may
       provide mechanisms for "validating" a URN -- i.e., determining
       whether a given string is currently a validly-assigned URN.   
[...]

This seems to imply that this mechanism would allow to determine  
whether urn:service:timezone, say, exists or not. This would  
presumably be done by the lookup mechanism.

I'll reword the paragraph to hopefully make the distinction clearer.

(more to follow)

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Apr 2006 21:24:02 -0400

Maybe part of the confusion is that I meant this as an analogy. In  
other words, I don't this literally as translating an E.164 number.  
Rather, this 800# has the same properties as 411 or 911: The phone  
system uses location-related information (caller phone number or  
location) to select one of several possible destinations.

In the service URN case, the N11 and 1-800-something cases would be  
treated similarly, as

urn:service:lawyer

in this case.