Re: 2806bis-3 comments

Thank you. Your comments will be incorporated into -04.

Lawrence Conroy wrote:
> Hi Henning, Folks,
> 
> Re. ABNF on lines 198 to 204.
> 
> A minor point, but one that would be convenient for the future:
> I would like a slight expansion to the ABNF (but one with no syntactic 
> change to the URI).
> 
> When discussing the elements that make up a uri-value, it is useful to 
> be able to name that portion consisting of the "raw" number-part (for 
> lack of a better term), as well as separating out the other parameters 
> from the core one(s).
> 
> thus:
>         telephone-uri      =  "tel:" subscriber *other                <
>         subscriber         =  global-number / local-number            |
>         global-number      =  global-number-part [isdn-subaddress]    <
> 
>>
>         global-number-part =  "+" 1*globaldigit                      <<
>         local-number       =  local-number-part                       <
>                               [isdn-subaddress]                       |
>                               1*(context)                             |
> 
>>
>         local-number-part  =  1*localdigit                           <<
> 
> Where a trailing | denotes unchanged line, < denotes a changed line, << 
> indicates an added line, and > denotes a line has been removed.
> 
> The goal here is to allow a named non-terminal to define just the 
> "number part" of the 'tel:' URI, and to define the overall telephone-uri 
> as being in three parts, so meaning that a 'subscriber' does not include
> the 'other' parameter(s). The isdn-subaddress and context attributes
> are bound closely to the rest of the 'subscriber', whilst the 'other'
> parameters may or may not be so closely bound.
> 
> This will allow the ABNF for subscriber, global-number-part and 
> local-number-part to be re-used in other documents without requiring 
> other-parameters to be included. With the benefit of hindsight, it would 
> have been useful for the PINT RFC (and saved me personally a great deal 
> of discussion when debugging the first parser we produced for this :).
> 
> all the best,
>   Lawrence