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

Dale.Worley@comcast.net Tue, 06 March 2007 16:08 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcCu-0008Dn-3p; Tue, 06 Mar 2007 11:08:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOcCr-00088t-0z for sip@ietf.org; Tue, 06 Mar 2007 11:08:05 -0500
Received: from alnrmhc16.comcast.net ([206.18.177.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOcCn-0004OZ-NJ for sip@ietf.org; Tue, 06 Mar 2007 11:08:05 -0500
Received: from dragon.ariadne.com (dworley.hsd1.ma.comcast.net[24.34.79.42]) by comcast.net (alnrmhc16) with ESMTP id <20070306160731b16008qkv7e>; Tue, 6 Mar 2007 16:08:01 +0000
Received: from dragon.ariadne.com (dragon.ariadne.com [127.0.0.1]) by dragon.ariadne.com (8.12.8/8.12.8) with ESMTP id l26G7U6f032015 for <sip@ietf.org>; Tue, 6 Mar 2007 11:07:30 -0500
Received: (from worley@localhost) by dragon.ariadne.com (8.12.8/8.12.8/Submit) id l26G7UID032011; Tue, 6 Mar 2007 11:07:30 -0500
Date: Tue, 06 Mar 2007 11:07:30 -0500
Message-Id: <200703061607.l26G7UID032011@dragon.ariadne.com>
To: sip@ietf.org
From: Dale.Worley@comcast.net
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Subject: [Sip] draft-lee-sip-dns-sd-uri-00 - SIP URI Service Discovery using DNS-SD
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org

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:carol@cube2214a.chicago.com", 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:Dale.Worley@comcast.net>'

[2] E.g., 'sip:Dale.Worley@comcast.net;transport=tcp' is not the URI
'sip:Dale.Worley@comcast.net;transport=tcp', it's the URI
'sip:Dale.Worley@comcast.net' with the meaningless field parameter
'transport=tcp'.  To specify the URI
'sip:Dale.Worley@comcast.net;transport=tcp', one must write
'<sip:Dale.Worley@comcast.net;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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip