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

[Flemming Andreasen <[e-mail]>]

On 11/15/12 4:06 AM, [e-mail] wrote:
>
> Hi Flemming, Paul, Keith, and all,
>
> When going through 
> http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt 
> <http://tools.ietf.org/id/draft-ietf-mmusic-sdp-cs-13.txt> for 
> publication, Flemming had a comment on the format of global telephone 
> numbers.
>
> The draft currently says in Section 5.2.1:
>
>   This memo exclusively uses the international representation of E.164
>
> numbers, i.e., those initiated with a '+' sign.  The syntax (see
>
> Section 5.7) refers to the representation of a 'global-number'
>
> construction already specified in RFC 3966 [RFC3966].  This
>
> representation requires the presence of the '+' sign. Additionally,
>
> this representation allows for the presence of one or more 'visual-
>
> separator' constructions.  Implementations confirming to this
>
> specification and using the "E164" address type together with the
>
> "PSTN" network type MUST only use international E.164, i.e., those
>
> starting with a '+' sign and SHOULD NOT use visual-separators.
>
> This was discussed earlier on the list, see 
> http://www.ietf.org/mail-archive/web/mmusic/current/msg09630.html
>
> Flemming's comment was that referencing to RFC3966 but saying that the 
> syntax is invalid because we only use parts of it is not a good idea.
>
> The question is, could we just refer to RFC3966 and allow visual 
> separators?
>
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.

Thanks

-- Flemming

> In my understanding the tradeoff is between slightly increased 
> complexity in parser implementation versus being clear on the syntax. 
> I would be inclined to prefer the latter.
>
> Regards,
>
> Simo
>