Re: Comments on RFC2806bis

It would not be a good idea to use a local dial plan in an international 
number format as suggested for Vienna.

I assume that E. Timor as a newly created country might not have one now, 
but would likely get one quickly.

Finally a random number, if the first few digits matched a dial plan could 
be routed.  Excess digits could be ignored.  But random hex digits might 
have a harder time.

Mike


At 10:28 AM 5/21/2002 +0100, Lawrence Conroy wrote:
>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>:
>_______________________________________________
>IPTEL mailing list
>[email protected]
>http://lists.bell-labs.com/mailman/listinfo/iptel