H.323 URL Specification

Paul E. Jones paulej at PACKETIZER.COM
Wed Sep 6 22:13:25 EDT 2000


I think we're agreement on all points below, but I still have concerns about the case issue.

I whole heartedly agree that using case insensitive names is ideal-- it reduces a lot of confusion for the user.  However, I know that 'A' and 'a' are the same and it's very easy to write software to do the same.  One easy way to do that is to use a function like "tolower()" in C when before storing/comparing values.  However, is there a Unicode equivalent?  Such a function would have to be aware of the complete set Unicode characters and know which ones are the upper/lower case versions of the others.  Is that something we can assume that people will implement or do you think imposing such a requirement will be met with resistance?

My biggest fear is that some GKs will properly handle all characters and most will not.


  ----- Original Message ----- 
  From: Callaghan, Robert 
  To: 'Paul E. Jones' ; Mailing list for parties associated with ITU-T Study Group 16 
  Cc: Orit Levin 
  Sent: Tuesday, September 05, 2000 10:37 AM
  Subject: RE: Re: H.323 URL Specification



  I agree that HTML can be a problem, that I know of.  I only replied to the thread.


  See below.





  Robert Callaghan

  Siemens Enterprise Networks

  Tel: +1.561.923.1756              Fax: +1.561.923.1403

  Email:      Robert.Callaghan at ICN.Siemens.com



  -----Original Message-----


  ·       For protocol, use “h225rs” or “h323rs” instead of “ras”.  This controls the confusion with the dial-in protocol know as RAS. 

  ·       For protocol, use “h225cs” or “h323cs” instead of “q931”.  This controls the confusion with real Q.931 For protocol, use “h225ar” or “h323ar” instead of “annex-g”. 

  I really like the use of "ras", even though there are conflicts in other contexts.  However, I agree that q931 is not really ideal.  How about these:  lrq, setup, ar (for AccessRequest)?  So rather than specifying a protocol, we specify the message to use?

  [RWC] I definitely don’t like q931 and annex-g.


  As a secondary question, how is an endpoint to handle ras and annex-g?  Obtain the information directly or go through the GK?  This should be stated.

  My view on this is that the endpoint should have one of two options:

  1) It contacts the endpoint directly, or

  2) It sends to URL to the GK for resolution

  [RWC]  I agree with this as long as GK resolution is performed via normal RAS.


  ·       Is “escaped” limited to two hexdigits?  How does one escape to Unicode characters?  This should be possible. 

  It has never been proposed to use unicode, so, yes, the "escaped" set is limited to two bytes (the data type is actually IA5String).  However, we could add a statement that says that the entire H323-URL is UTF-8 encoded.  In that way, characters from other languages could converted to UTF-8 and then escaped where necessary.

  [RWC] We cannot have UTF-8 in the domain part of the URL.   I would like to see UTF-8 in the user part of the name through the use of escaped characters.

   So perhaps the user part of the name should be defined as a UTF-8 encoded string of characters, with the only restrictions being that "%" and "@" must be escaped if they exist in the user part.  Sound good?

  However, this does bring to my attention the fact that the character set is now very limited.  Any character can be represented, but it would be nice to allow François to enter his name like that, rather than Fran%83ois.  What character set limitations does IA5 impose on us?  Can we use any binary value between 0-255 for each character?  If so, I would also like to propose that we change the "unreserved" production to allow any character between 0-255, excluding % and @ (since those have special meanings).  What do you think?

  [RWC] 0-255 is not sufficient.

  I believe that the above mentioned change (re: UTF-8) will give us the means of allowing the full range of unicode characters for the user name part.


  However, this raises another question: how do we enforce the rule that names are not case sensitive.  That would suggest that for any given character set within unicode, the manufacturer will have to know which characters are the upper and lower case ranges.  Is this desirable to recommend?  I like names that are not case sensitive, but this might be overly complex to try to do.  It would make internationalization of a Gatekeeper, for example, much more difficult than it is today-- I suspect some vendors will not go through the effort.


  Should we re-think the "case insensitive" issue?

  [RWC]  I don’t see case insensitive as being in conflict with UTF-8.  Part of the characters as defined as case oriented and some are not.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000906/1258b0b7/attachment-0001.htm>

More information about the sg16-avd mailing list