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

[Robert Sparks <[e-mail]>]

On 3/7/17 10:02 PM, Dale R. Worley wrote:
> 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.
I'll use a variation of that.
>
> 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.
s/formed/intended/?

But I don't think changing will to might is correct.

Can you construct a case where the refined guidance says you have to use 
the <>, and if  leave them out you get the same interpretation?


>
> 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?
Good question, but not this document's problem, and I don't remember if 
using Updates for this doc was discussed at the time (it should have 
been at least discussed).  In any case, I propose the answer is no, for 
the reasons below.
>
> (Perhaps I'm not understanding how the "Reference" column of that table
> is to be used.)
So this is hard.

My opinion is that it would be a mistake to try to mark updates in the 
iana registry as you suggest.
Rather, the registry should point to the main defining document, and 
only the main defining document.
Readers can follow the Updates links from the RFC pages.
(Note that we _have_ changed that registry to reflect Obsoletes, which 
is consistent with the above.)

My rational for that opinion is that we already have the Updates 
metadata in two databases (the RFC Editor and the datatracker). We have 
had, an expect will continue to have, conversations about moving to one 
authoritative database for that. If we were to try to also track this in 
the IANA registries, that unification gets even harder.

I also note that if we _were_ to update the IANA registry column as you 
suggest, it's unusually easy
to figure out which ones to modify for this particular draft's case. It 
becomes much murkier for the
general case. Why, for example, would you not list 6141 along with every 
row that says 3261 (at least
for any header field involved in reINVITE and target-refresh request 
handling). That could lead, in the
extreme to a lot of noise, with most of the rows in that table saying:
[RFC3261][RFC6665][RFC4320][RFC3265][RFC5954][RFC5630][RFC5393][RFC7463][RFC5626][RFC6878][RFC3853][RFC7462][RFC6026][RFC5621][RFC5922][RFC4916][RFC6141]

I really think the right way to approach this is to keep the table as it 
is now.


>
> 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.
Again, I don't think the change from will to may is correct.
>
> [END]
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore