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@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.