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

[Jae Woo Lee <[e-mail]>]

> 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.

> 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.
>

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.

> 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.
>

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.

> 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:[e-mail]", the request must be sent
>    to cube2214a.chicago.com.
>
> If "cube2214a.chicago.com" has SRV records, this may not be correct as
> written.
>

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.

> 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.)
>

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.

> 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.
>

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

> 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?

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
> 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:[e-mail]>'
>
> [2] E.g., 'sip:[e-mail];transport=tcp' is not the URI
> 'sip:[e-mail];transport=tcp', it's the URI
> 'sip:[e-mail]' with the meaningless field parameter
> 'transport=tcp'.  To specify the URI
> 'sip:[e-mail];transport=tcp', one must write
> '<sip:[e-mail];transport=tcp>'.
>

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




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