Subject: [Ecrit] On DDDS discovery

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Mar 2006 14:34:53 -0600

In relation to my suggestion that S-NAPTR be used for discovery of LoST.
 
The main argument I heard against this was that it could delay the service URN document, which is important and already running slightly late -- a fair comment.  In light of the fact that the discovery section is now being moved to the LoST draft, which is less constrained by time, I would like to re-float the argument.
 
S-NAPTR simplifies the deployment of NAPTR.  For LoST, I don't see any need for the extra features that are excluded from the S-NAPTR profile.  S-NAPTR would reduce the complexity of resolvers and the provisioning/data management effort at the DNS.  A better argument for the use of S-NAPTR is in RFC 3958 (Section 5).
 
A small update to RFC 3958, one that the authors agree would be (relatively) easy to acheive and quite desirable, is to add support for URI results (the "U" flag).
 
I do have a draft (available on request - it needs a rewrite) that includes the both the change to S-NAPTR and additional information that can be used to retrieve a service URI or a WSDL document that describes the service in more detail.
 
The following example might apply to LoST:
     example.com.
     ;;       order weight flags service           regexp
     ;;                    replacement
     IN NAPTR 100   10     "U"   "LOST:https"      "" (
                           "https://ws.example.com/services/myws" )
     IN NAPTR 200   10     "U"   "LOST:http"       "" (
                           "http://ws.example.com/services/myws" )

This example uses a set of newly defined S-NAPTR application protocol tags.  SOAP and BEEP was the other option.  The result is the base URI for the service.

The other option is to retrieve a WSDL document for the service that can include additional information about the service:

     example.com.
     ;;       order weight flags service           regexp
     ;;                    replacement
     IN NAPTR 100   10     "U"   "LOST:WSDL"       "" (
                           "https://ws.example.com/wsdl/lost.wsdl" )

The only thing that this solution doesn't include is the way that the path component of the URI is populated with the service tag ("sos", "sos.fire", etc...).  Personally, even though I understand some of the benefits of this approach, I don't think that this is the place for that sort of information.  That is information for request bodies and the LoST protocol.  These parameters can form part of the request URI using the above results as a base URI, but if the URI contains protocol data, its format should be specified in a protocol document, not DNS.

Regards,
Martin

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Mar 2006 16:54:34 -0500

On Mar 21, 2006, at 3:34 PM, Thomson, Martin wrote:
> A small update to RFC 3958, one that the authors agree would be  
> (relatively) easy to acheive and quite desirable, is to add support  
> for URI results (the "U" flag).

Yes, and to clarify a misunderstanding in the session today... the  
authors of RFC 3958 do support the addition of the U flag.  That is  
the opposite of what people claimed they heard.

> The only thing that this solution doesn't include is the way that  
> the path component of the URI is populated with the service tag  
> ("sos", "sos.fire", etc...).  Personally, even though I understand  
> some of the benefits of this approach, I don't think that this is  
> the place for that sort of information.  That is information for  
> request bodies and the LoST protocol.  These parameters can form  
> part of the request URI using the above results as a base URI, but  
> if the URI contains protocol data, its format should be specified  
> in a protocol document, not DNS.

I totally agree.  The interactions for this belong in LoST where  
there is better flexibility to apply this to the mapping.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Mar 2006 22:51:04 -0500

Maybe it's a useful to step back a minute and look at possible 
requirements. I'd like the DDDS mechanism to address two requirements:

(1) It should be possible to have other mapping protocols in the future, 
beyond just different encodings than, say, WSDL or plain HTTP.

(2) It must be possible to have different services resolve to different 
mapping servers. A fictitious "doctor locator service" is likely to use 
a completely different mapping hierarchy than emergency services. 
Indeed, for a pizza delivery service, you might have one run by Pizza 
Hut and one run by Domino's. I'm not suggesting these are necessarily 
good examples of service URNs, but provide the flavor.

I chose the should/must difference intentionally, i.e., I don't quite 
care about (1) as much as (2).

For (2), we can either have DHCP or SIP configuration point to different 
DNS records for each service or we need to be able to handle this by 
NAPTR indirection, e.g., that my ISP or VSP domain points to their 
preferred mapping servers for a set of services.

 From my reading of 3598, I have concerns. In particular, Section 6.1 says:

  The Application Unique String is domain label for which an
    authoritative server for a particular service is sought.

This is *not* quite what we want, at least if we want to incorporate the 
service itself into the server selection decision. If all of the server 
selection decision based on services is punted to DHCP or 
SIP-configuration, it is not clear to me that we need NAPTR indirection 
at all, since that first step might as well include the protocol name 
and we can directly proceed to SRV, which is simpler still.

One possible approach is to define the service string as something like

MP.sos.fire:LOST.http

I don't know if that fits into the 3589 framework. (You'd have to define 
prune-back matching, i.e., if MP.sos.fire doesn't exist, try MP.sos.)

Henning

Thomson, Martin wrote:
> The main argument I heard against this was that it could delay the
> service URN document, which is important and already running slightly
> late -- a fair comment.  In light of the fact that the discovery
> section is now being moved to the LoST draft, which is less
> constrained by time, I would like to re-float the argument.
> 
> S-NAPTR simplifies the deployment of NAPTR.  For LoST, I don't see
> any need for the extra features that are excluded from the S-NAPTR
> profile.  S-NAPTR would reduce the complexity of resolvers and the
> provisioning/data management effort at the DNS.  A better argument
> for the use of S-NAPTR is in RFC 3958 (Section 5).
> 
> I do have a draft (available on request - it needs a rewrite) that
> includes the both the change to S-NAPTR and additional information
> that can be used to retrieve a service URI or a WSDL document that
> describes the service in more detail.
> 
> The following example might apply to LoST: example.com. ;;
> order weight flags service           regexp ;;
> replacement IN NAPTR 100   10     "U"   "LOST:https"      "" ( 
> "https://ws.example.com/services/myws" ) IN NAPTR 200   10     "U"
> "LOST:http"       "" ( "http://ws.example.com/services/myws" )
> 
> This example uses a set of newly defined S-NAPTR application protocol
> tags.  SOAP and BEEP was the other option.  The result is the base
> URI for the service.
> 
> The other option is to retrieve a WSDL document for the service that
> can include additional information about the service:
> 
> example.com. ;;       order weight flags service           regexp ;;
> replacement IN NAPTR 100   10     "U"   "LOST:WSDL"       "" ( 
> The only thing that this solution doesn't include is the way that the
> path component of the URI is populated with the service tag ("sos",
> "sos.fire", etc...).  Personally, even though I understand some of
> the benefits of this approach, I don't think that this is the place
> for that sort of information.  That is information for request bodies
> and the LoST protocol.  These parameters can form part of the request
> URI using the above results as a base URI, but if the URI contains
> protocol data, its format should be specified in a protocol document,
> not DNS.
> 
> Regards, Martin
> 
> 
> 
> 
> 
> 
>  This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, please notify the sender immediately and
> delete the original.  Any unauthorized use of this email is
> prohibited. 
> _______________________________________________ Ecrit mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Wed, 22 Mar 2006 07:40:03 -0500

On Mar 21, 2006, at 10:51 PM, Henning Schulzrinne wrote:
> I don't know if that fits into the 3589 framework. (You'd have to  
> define prune-back matching, i.e., if MP.sos.fire doesn't exist, try  
> MP.sos.)

Yes, you could do this with 3958, but I think it would be a hack and  
therefore probably inappropriate.  But I thought Martin's whole point  
was that you don't need to do it since the service URN is being  
handed to the mapping server in the LoST protocol itself.  And I have  
to confess that I now find the purpose of the service URN confusing.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 09:48:32 -0500

Andrew,

you didn't answer my two requirements earlier in that message, namely 
(restated), in particular, that I think that we need to be able to 
support having different resolvers for different services and that a 
seeker needs to be able to identify those automatically and easily.

I'm also not quite convinced yet that we want to tie the service URN 
completely to one lookup protocol, forever and across all services. This 
seems unnecessary and unwise.

Henning

Andrew Newton wrote:
> was that you don't need to do it since the service URN is being handed 
> to the mapping server in the LoST protocol itself.  And I have to 
> confess that I now find the purpose of the service URN confusing.
> 
> -andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 22 Mar 2006 10:27:33 -0500

On Mar 22, 2006, at 9:48 AM, Henning Schulzrinne wrote:
> you didn't answer my two requirements earlier in that message,  
> namely (restated), in particular, that I think that we need to be  
> able to support having different resolvers for different services  
> and that a seeker needs to be able to identify those automatically  
> and easily.

Sorry.  To be specific to your earlier email, I believe both items  
are covered by 3958.  However, this text says something different.  I  
don't know what you mean by "resolver" because we are talking about  
DNS resource records and the term "resolver" has a very specific  
meaning in that context... one I'm hoping you are not suggesting.

> I'm also not quite convinced yet that we want to tie the service  
> URN completely to one lookup protocol, forever and across all  
> services. This seems unnecessary and unwise.

Neither Martin nor I are suggesting any such thing, and 3958 is  
obviously not saying this as the examples in that RFC are explicitly  
about using multiple protocols for services.

At the moment, I am not exactly comfortable suggesting that 3958 is  
applicable but the same goes for DDDS in general.  That is why I said  
I am confused about where this URN is being used and for what  
purpose.  Is this about describing the service universally or about  
describing a service contextually?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 18:05:30 -0500

> Sorry.  To be specific to your earlier email, I believe both items are 
> covered by 3958.  However, this text says something different.  I don't 
> know what you mean by "resolver" because we are talking about DNS 
> resource records and the term "resolver" has a very specific meaning in 
> that context... one I'm hoping you are not suggesting.

Sorry for the name confusion... I was talking about the LoST resolver, 
not the DNS resolver.

>> completely to one lookup protocol, forever and across all services. 
>> This seems unnecessary and unwise.
> 

Right - but then it makes sense to have a common mechanism for the URN.

> applicable but the same goes for DDDS in general.  That is why I said I 
> am confused about where this URN is being used and for what purpose.  Is 
> this about describing the service universally or about describing a 
> service contextually?

The abstract model is that a communication protocol (SIP, XMPP, maybe 
even email or HTTP...) requests to be connected to a (possibly) 
location-dependent abstract service, offered by many different service 
providers. Since the service URN isn't routable, a proxy then invokes a 
mapping protocol that performs the following operation:

URL = function(service, [location])

where 'URL' is routable.

Does that help?

---

From: Andrew Newton <[email-masked]>
Date: Wed, 22 Mar 2006 18:14:59 -0500

On Mar 22, 2006, at 6:05 PM, Henning Schulzrinne wrote:

> The abstract model is that a communication protocol (SIP, XMPP,  
> maybe even email or HTTP...) requests to be connected to a  
> (possibly) location-dependent abstract service, offered by many  
> different service providers. Since the service URN isn't routable,  
> a proxy then invokes a mapping protocol that performs the following  
> operation:
>

Is the order?

1) get URIs from LoST
2) do the URN DDDS on LoST output

or

1) do URN DDDS
2) use output of URN to know which LoST servers to query

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 22 Mar 2006 19:03:15 -0500

More than latter; in a little bit more detail:

(1) do URN DDDS: obtains URL (such as http://something) for LoST
(2) perform LoST operation: provides URL (e.g., SIP URL)
(3) if SIP, do another DDDS/NAPTR operation (standard operation)