Subject: [Ecrit] Forward of Off-List Service URN Draft Discussions (9)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Wed, 16 Aug 2006 14:27:36 +0200

-----Ursprüngliche Nachricht-----
Von: Leslie Daigle [mailto:[email-masked]] 
Gesendet: Freitag, 28. Juli 2006 03:47
An: Henning Schulzrinne
Cc: Marc Linsner; Tschofenig, Hannes; 'James M. Polk'; [email-masked]
Betreff: S-NAPTR Re: Moving forward with the Service URN Draft

I only want to comment on one aspect here, and then
I'll forward some mail I had after chatting with Ted
a few days ago (and I'll add him to the cc line):

Henning Schulzrinne wrote:

>> And then, the $64k question -- *what* is the FQDN that is to
>> be queried for the NAPTR records?
>>
>> I couldn't quite figure that out between the service URN and
>> LoST documents.  Is it "hostname"?  Or...?  It seems like
>> the basic purpose is to say "given I'm *here*, for some
>> value of *here*, where is my LoST service in protocol
>> A, B or C".  So, what is *here* expressed in a relevant FQDN?
>> That really needs to be made clear in defining the use of S-NAPTR.
>>
> 
> This is described in "Finding the Mapping Server", albeit less precisely 
> than I'd like. Currently, it says that the domain is "typically the home 
> or service provider domain". I don't know if it would be helpful to give 
> an example for the SIP case, where this would be the AOR domain. The 
> cut-and-paste fragmented text in -03 starting with 'until a working 
> server' gives three options: DHCP domain, DNS PTR lookup for all ICE 
> derived addressed and the application service provider, tried in order.
> 
> I wish I had a better answer; designating a particular domain 
> immediately means that we have to pick somebody to run it and I'd rather 
> not repeat the e164.arpa experience. (Unlike in ENUM, this is altogether 
> unnecessary here since any number of entities can operate localized 
> translation servers.)

You really do need a better answer, or at least a more assertive one!
If I'm a programmer wishing to implement to this as a library, what does
that text mean?  That I can pick one?  That all approaches will be
supplied everywhere?  Or that there some bit of critical documentation
that I can't get my hands on?  It would be more complete to say it's
a configuration option of the client software and will be supplied
out of band of this protocol, but that seems to run you into operational
difficulties -- will all clients know what approach to use? (Failure
of interoperability).

Even listing an order in which to test each of these, saying "stop
when you get an answer" would be more definitive and implementable, IMO.

Leslie.

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Aug 2006 21:11:58 -0400

> when you get an answer" would be more definitive and implementable,  

This sounds very similar to the questions faced by RELO (in GEOPRIV),  
which is related to this whole problem set.  When having to query DNS  
for bootstrapping information when the access network, IP-providing  
network (ISP), and the voice service network may not be related is an  
issue.  The answer to both cases may be the same, and I do not think  
either is difficult to decided.  We just need to sit down and figure  
it out.

-andy