Subject: [Sip] draft-lee-sip-dns-sd-uri-00 - SIP URI Service Discovery using DNS-SD

From: [email-masked]
Date: Tue, 6 Mar 2007 11:07:30 -0500

A few comments concerning draft-lee-sip-dns-sd-uri-00:

Substantive:

In regard to DNS SD, realize that most of your readers are not
familiar with it, so it might be helpful to give at the beginning a
high-level description of the service that DNS SD provides.  Viz.,
once one has decided upon a domain, one can use DNS to find all
service instances (of a particular type) that advertise themselves in
that domain using DNS SD.

5.2.  Request Destination

It seems to me that this could be both simplified and corrected by
just saying that if a "contact" attribute is available, it should be
used as the request-URI of any out-of-dialog SIP request.  Since this
definition automatically refers to RFC 3263, it allows a lot of
generality while behaving correctly in various special cases.

For example, consider

   If the "contact" attribute of the TXT record is available, the host
   part MUST be taken as the destination host to which to send the
   request.  For example, if the TXT record contains
   "contact=sip:[email-masked]", the request must be sent
   to cube2214a.chicago.com.

If "cube2214a.chicago.com" has SRV records, this may not be correct as
written.

The revision also explains what to do with the user-part of the
contact, etc., which may be significant.  (E.g., as a SPIT
preventative, some SIP phones demand the correct user-part or a
specific URI-parameter in the request-URI of incoming requests.)

Editorial:

4.3.  contact

   See Section 25.1 of [RFC3261] for the precise definitions of these
   elements as well as those of contact-extension and display-name.

Please also add a reference to the last paragraph of section 20 of
[RFC3261], which contains a vital rule that resolves an ambiguity in
the BNF of section 25.1.

However, you need to be more careful discussing the syntax.  Do you
intend for the value of the "contact" attribute to be parsed as a
"contact-param" as defined in RFC 3261?  If so, you should make it
clear that contact-parm admits strings that are not URIs (though they
contain URIs) [1], and that some strings that appear to be URIs are
not [2].  In general, don't refer to a contact-param a URI, say it
contains a URI.  Parsing contact-param should not be undertaken
lightly!

[1] E.g., '"Dale Worley" <sip:[email-masked]>'

[2] E.g., 'sip:[email-masked];transport=tcp' is not the URI
'sip:[email-masked];transport=tcp', it's the URI
'sip:[email-masked]' with the meaningless field parameter
'transport=tcp'.  To specify the URI
'sip:[email-masked];transport=tcp', one must write
'<sip:[email-masked];transport=tcp>'.

Dale

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jae Woo Lee <[email-masked]>
Date: Thu, 8 Mar 2007 09:52:46 -0500

> A few comments concerning draft-lee-sip-dns-sd-uri-00:

Thank you very much for your insightful comments.  We will  
incorporate them into the next iteration of the draft.  Please find  
some further inline comments.

> that domain using DNS SD.

We have a paragraph in the Intro section describing DNS-SD, but I  
agree that another one describing the enumeration aspect (as you  
described) would be helpful.  Such an introduction would also set the  
stage for the UI discussion that comes later.

> generality while behaving correctly in various special cases.

We specify in Section 5.1 that the Request-URI must be set from the  
SIP URI from the service instance name (which SHOULD be AOR.)  We  
look at the contact attribute to determine where to send the  
request.  We felt that this is natural since the Request-URI then  
reflects the logical recipient who advertised the service.

> If "cube2214a.chicago.com" has SRV records, this may not be correct as

You raise an excellent point.  We must specify how the UA should  
resolve cube2214a.chicago.com, and it's missing from this draft.   
There are two possibilities:

1) Do an SRV lookup first and then do an A/AAAA lookup if SRV fails.   
This follows the RFC3263, Section 4.2.

2) Don't do SRV lookup and just do A/AAAA lookup.

The argument for 2) is that, in the most common case of local DNS-SD/ 
mDNS environment (that is, Bonjour network), we'll most likely end up  
doing A/AAAA lookups, so we shouldn't do something that'll fail most  
of the time anyway.  Besides, DNS-SD uses SRV in a different way, so  
it might be confusing.

The argument for 1) is that, first, it is consistent with existing  
SIP UA behavior (RFC3263 that is), and second, SRV might come in  
handy in an hybrid environment such as a PBX advertising its  
subscribers.

We'll raise this issue in the IETF meeting if this I-D see the light  
of day in there.

> specific URI-parameter in the request-URI of incoming requests.)

Yes, we are ignoring the user part of the contact SIP URI, but the  
Request-URI is the SIP URI of the advertised service instance name,  
which should have the user part if that endpoint requires it.

> [RFC3261], which contains a vital rule that resolves an ambiguity in

Thank you for pointing this out.  We'll add that reference.

> "contact-param" as defined in RFC 3261?

Pretty much, except we removed "q" and "expires" parameters from the  
syntax and disallowed non-SIP URIs (hence the subtle replacement of  
'addr-spec' with 'uri'.)

> If so, you should make it

We will add the reference to the last paragraph of Section 20 and  
Section 20.10 of RFC3261 as you pointed out, with a warning sentence  
or two about the pitfalls of parsing the contact header.

> Dale

Thank you again for your comments.

Jae

---

From: [email-masked]
Date: Thu, 8 Mar 2007 23:03:23 -0500

From: Jae Woo Lee <[email-masked]>

I'd suggest that you change this so that the SIP URI from the service
instance name is the To value, and the URI part of the contact becomes
the request-URI.  This gives DNS SD the same redirection power as a
proxy/registrar.  It also allows you to not have to specify how the
contact value is to be interpreted, because you inherit all the rules
of RFC 3263 automatically.

Dale