Bob and others,
Please see my comments inline:
a.. The default protocol should be mandatory. In this case, flexibility kills interworking. Agreed. a.. 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 or do you want this: h323:paulej@packetizer.com;proto=ras,port=1719
a.. For protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the dial-in protocol know as RAS. b.. 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?
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 Or dev=ep or dev=be
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.
a.. 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. a.. Do we need annex-f to be specified as a protocol? It appears to me that we have this need. We could add "dev=a-set" as an option (audio SET), but I'm not fond of that idea. I suppose it might be useful in the enterprise environment where one may, indeed, have all SET devices and calls are placed directly between each other. a.. 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.
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? a.. If nesting is supported, how is this defined or used? If not, then there is no nesting. I don't envision nesting one address type inside the URL, if that's what you are asking. You convinced me before that, if the user alias is not sufficient, then other URL schemes should suffice, such as "tel" for reaching phone numbers. a.. When this URL is used in the url-id field, is the URL name inclusion mandatory? If not, what is the default? I would say "yes" and double "yes". If the scheme name is not present, one could not determine that it was the H323-URL. We definitely want to allow the usage of "http" or "tel" or even "sip". I can image an H.323 endpoint that gets launched and the only address on hand is sip:paulej@packetizer.com and the Gatekeeper must route the call to an IP gateway than can provide interworking functions. a.. 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.
Paul