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

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

Robert Sparks <[e-mail]> writes:
>> 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/?

You could phrase it that way.

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

Let me see if I made a mistake here...

If you form the header and violate the guidance by not using <>, the
header will necessarily be parsable *by the BNF alone* in the way it was
constructed.  It might also be parsable by the BNF alone in another
way.  What the guidance does is resolve the parsing ambiguity by
favoring the interpretation of comma, etc. as separators in the header
rather than as characters in the URI.

So if you want a From header containing "sip:10.0.0.1,sip:x@10.0.0.0",
which has user "10.0.0.1,sip" and password "x", you should write:

      From: <sip:10.0.0.1,sip:x@10.0.0.0>

and if you write

      From: sip:10.0.0.1,sip:x@10.0.0.0

it's interpreted as two URIs, "sip:10.0.0.1" and "sip:x@10.0.0.0", which
is syntactically correct but not what was intended.  (It's also
semantically incorrect.)

If you want a From header containing "sip:10.0.0.1,@10.0.0.0", which has
user "10.0.0.1,", you should write

      From: <sip:10.0.0.1,@10.0.0.0>

but if you do it wrong and write

      From: sip:10.0.0.1,@10.0.0.0

there's only one way to parse it with the BNF, and that is as you
intended it.

There's sort of an open issue as to what to do with that last header.
Since the guidance forbids its use, there's no requirement for
implementations to successfully parse it.  But since there's only one
way to parse it with the BNF, it's likely that a considerable number of
implementations parse it as it was intended.

At this point, I think the discussion is getting into the weeds
regarding exactly how you describe the bad things that might happen if
one violates the guidance, and I'll leave it to you!

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

And putting the updates information in the registry would be an
additional duplication, which is undesirable in general.  The loss is
that in following the "RFC X updates RFC Y" links, RFC X may not update
RFC Y in regard to a particular registry item, and there's no recording
of that.

I'm OK with this as a policy.

Dale