Re: [MMUSIC] E.164 and visual separators in draft-ietf-mmusic-sdp-cs

[Paul Kyzivat <[e-mail]>]

On 11/15/12 12:58 PM, Flemming Andreasen wrote:
>
> On 11/15/12 11:37 AM, Adam Roach wrote:
>> On 11/15/12 09:51, Flemming Andreasen wrote:
>>> To be clear, the "global-number" production in RFC 3966 allows for a
>>> number of parameters that are not part of the International E.164
>>> format and thus I have two concerns with the current text
>>> 1) The visual-separator exclusion although the ABNF allows for it
>>> 2) The apparent disconnect between all of these optional extra
>>> parameters and the above text suggesting they are not allowed.
>>
>> I don't think these really are issues. There are a lot of
>> specifications where the ABNF would allow for certain productions,
>> while the normative specification making use of that ABNF restricts
>> those productions. For example, there is nothing in the ABNF of RFC
>> 3261 that restricts SIP messages from having multiple CSeq header
>> fields, although it doing so certainly isn't allowed.
>>
>
> I think there is a big difference between having an ABNF that includes
> terminals and non-terminals in productions that may not be used at all
> as opposed to having an ABNF with certain semantic restrictions on what
> constitutes valid semantic values based on otherwise valid syntax. The
> former is generally well understood and accepted whereas the latter is
> not (and for good reason IMO - what's the point of having an ABNF
> otherwise ?).

Yes, I agree that this kind of constraint is a bit more of a stretch 
than the usual sort of things we revert to text for. (But I often have 
to make a tradeoff when constructing ABNF, between constraints that 
*can* be done syntactically with complex ANBF, and more forgiving ABNF 
and textual constraints.)

This is at least the third place I have come across in the last few 
months that had a need to represent a phone number, and where a 
reference into the 3966 ABNF could *almost* fit the bill. The last time 
was with TERQ. There I raised the possibility to Jon P that maybe it is 
time to revise 3966, so that it is more suited to being a source of 
definitions of phone number stuff that can be referenced. I have mixed 
feelings about that - I think it would be a good thing to do, but I 
don't know how many will consider it worth the trouble.

	Thanks,
	Paul