Re: Comments on RFC2806bis

At 11:13 pm -0400 20/5/02, Henning Schulzrinne wrote:
in response to James' comments -
>  Also, the syntax allows
>>more than one "context" parameter.  Is it possible to have more than one
>>"context" in real situation?  If yes (e.g., two domain names plus one
>>prefix), which one is to be used?  Suggest to add some discussions about the
>>allowed situation where more than one contexts occur.
>
>This was supposed to be an "OR", i.e., the number applies in all 
>such contexts. However, come to think of it, that's probably a bad 
>idea. I don't think URIs typically have multiple parameters with the 
>same name. Some parsers are likely to not take this gracefully. For 
>the OR case, the pickings are slim, however:
>
>- + is taken
>- comma and semicolon are not allowed (without escaping)
>- / doesn't fit well and would be confusing
>- . doesn't work for domain names
>- : is one possibility, as in
>
>tel:1234;phone-context=example.com:+12345
>
>Other suggestions welcome.

Actually, I can think of a number of situations in which an identifier
can be used for different objects.

The context is a qualifier on the applicability of the URI. It's not
really more than one parameter - The single parameter 'phone-context' can
have more than one value. This can happen due to introduction of relief codes,
or the Vienna case, where there are two codes to dial Vienna (within Austria).
Thus a Viennese phone could have two values for its phone context (01 and the
old code - can't remember what this is, off hand). As an aside, the old code
is not valid outside Austria, so writing this in International form is strange.

[Also, for example, the tel: number might be associated with voice telephony
or fax or mms or... I understand that one can use SIP as a "Service Resolution
Service" and am still thinking on whether or not such explicit service idents
are ever needed, but these could indeed have more than one value to 
the hypothetical
parameter 'service' - I suspect that these would be 'hints' rather 
than mandatory]

This, BTW, is why I originally asked the dumb question on comma separated list
values. The conclusion of that is that there will be a set of params, each with
one value. The alternative (there is one parameter with multiple values) needs
to be syntactically valid, but may be more compact.

Any ideas on value separators - is the above an exhaustive list?

>>
>>I've the "global routing number" parameter that begin with the country code
>>followed by hex digits.  Is it possible for you to describe "country code"
>>part of the global-number-part so that I can use it in my I-D.  I hate to
>>see that the "extensions" defines something in more details.  The first one
>>to three digits of the global-number-part identify the country code.
>
>Done. Can the country code contain hex digits? Is there the 
>possibility that country codes need more than three digits? Does 
>East Timor have its own country code?

Hmm...should be in E.164, IMHO. Will look.

BTW, James, the conclusion we had was that a RN is not in International format
so that a local number is OK when using HEXDIG. I can't think of a situation
where one needs a "pseudo-E.164" number with HEXDIG in the 
country/service code.
Was this your intention?

atb,
   Lawrence
-- 
[email protected]: +44 1794 833666::<my opinions>: