H.323 URL Specification

Callaghan, Robert Robert.Callaghan at icn.siemens.com
Tue Sep 5 10:37:30 EDT 2000


Paul,
 
I agree that HTML can be a problem, that I know of.  I only replied to the
thread.
 
See below.
 
Bob
 
------------------------------------------------------------------
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/20000905/af8661ef/attachment-0004.html>


More information about the sg16-avd mailing list