Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance

[[e-mail] (Dale R. Worley)]

Of course, I favor approval of draft-ietf-sipcore-name-addr-guidance.

I do think there are some nits that need to be resolved.  Though since I
haven't been following this draft closely, these points may already have
been discussed.

Dale
----------------------------------------------------------------------
Abstract

   It
   also updates those extension SIP header fields that use the
   alternative to clarify that the constraint applies (RFCs 3325, 3515,
   3892, 4508, 5002, 5318, 5360, and 5502).

This isn't parallel to the 1st sentence of the paragraph, where the
object of "updates" is "RFC3261".

Perhaps

   It also updates the RFCs (3325, 3515, 3892, 4508, 5002, 5318,
   5360, and 5502) that define the extension SIP header fields that
   use the alternative to clarify that the constraint applies.

1.  Introduction

   It is important to note that a message formed without honoring the
   constraint will still be syntactically valid, but would be
   interpreted differently.

This is a subtle point...  If the <...> is omitted, the header will
necessarily still be syntactically valid according to the BNF, reading
the original URI as an addr-spec -- the BNF is ambiguous in that way.
What *might* happen is that the header becomes parsable according to
the BNF in a different way also, one that parses the URI as multiple
elements.  E.g.,

    From: sip:10.0.0.1,sip:x@10.0.0.0

can be either parsed as one URI with user "10.0.0.1,sip" and password
"x", or two URIs, one "sip"10.0.0.1" and one "sip:x@10.0.0.0.

OTOH,

    From: sip:10.0.0.1,@10.0.0.0

can only be parsed with the BNF as a single URI, because "@10.0.0.0"
doesn't parse as a URI.

So it's more accurate to say

   It is important to note that a header formed without honoring the
   constraint will still be syntactically valid, but might be
   syntactically ambiguous and interpreted differently than it was
   formed.

4.  IANA Considerations

   This memo has no considerations for IANA.

Shouldn't the new RFC be listed in the IANA table of SIP header fields
(http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2)
as a reference for these header fields:

     P-Asserted-Identity
     P-Preferred-Identity
     P-Profile-Key
     P-Refused-URI-List
     P-Served-User
     Permission-Missing
     Refer-To
     Referred-By
     Reply-To

And while we're at it, shouldn't RFC 4508 be a reference for Refer-To?

(Perhaps I'm not understanding how the "Reference" column of that table
is to be used.)

5.  Security Considerations

   One pre-existing consideration is worth reiterating:
   messages produced without honoring the constraint will be mis-
   interpreted by the receiving element.

This should say "may be mis-interpreted", as discussed in the item for
section 1.

[END]