See inline comments
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
* The port should be specified as belonging the specified protocol. What do you mean? Are you in favor of this: h323:paulej@packetizer.com:1719 mailto:h323:paulej@packetizer.com:1719 or do you want this: h323:paulej@packetizer.com;proto=ras,port=1719 mailto:h323:paulej@packetizer.com;proto=ras,port=1719 [RWC] I prefer choice one in the base specification.
* 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.
Or how about this-- make it easier for those not familiar with the protocols. Specify the type of device: h323:paulej@packetizer.com;dev=gk mailto:h323:paulej@packetizer.com;device=gk Or dev=ep or dev=be [RWC] This was a mistake on my part. I meant annex-k for the API link. We don’t need a device field.
The software/hardware can then determine the protocol. This might be the best solution, since "h323" is supposed to represent the protocol in the first place.
* The specification of “ras” belonging to LRQ is limiting. For me, the first contact is over ARQ to my GK. Then the GK may use LRQ or any other means to resolve the address. From this view point, there is no difference between “ras” and “annex-g”. If we just specify the type of device the URL is associated with it will resolve this issue. [RWC] The type of device for what: the endpoint for the contact point. I don’t think the URL should change the normal procedure of an endpoint using the GK, if one is present. Annex-g should never be used by and endpoint (see annex g). The only applies to GKs or boarder elements.
* 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.
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 see no need for the URL ARQ be resolved to a URL. It could be resolved to any alias using the alias replacement rules. The means that an URL in and ARQ could be replaced with a partyNumber (last paragraph). You lost me here. If you are saying that there's no need to put a partyNumber inside a URL or that the GK should be allowed to map the URL alias to a partyNumber when returning an ACF, I agree. Otherwise, I need some clarification. [RWC] It is possible to pass a URL to a GK and have it respond with a partyNumber under the rules of alias substitution by the GK. Then the SETUP is sent using the partyNumber alias not the url alias.
Paul