(0) The use of url means the "address resolution" is done (by the local GK) using the DNS, not RAS! This is why the "user only" url of H.323, is really an exceptional case. It is a question, if we want to keep it within the url. It lets the local (source) GK know, that the "address resolution" procedure should performed by other, then DNS, means. The "protocol" means: the signaling H.323 protocol to contact the (next hop towards the) destination, after the IP address had been resolved. (1) Since "user only" is an exception in H.323, I still believe, that it is dangerous to leave it just as an "user"... (2) If you would like to say that the destination can be reached by either "RAS on UDP on port #n" or by "H.225.0/Q.931 on "Annex E" port #m", you need to advertise two different URL for the same (?) service. It may be OK, but we all have to agree on the meaning.

BTW, I think that specifying the "message name" instead of the protocol is a great idea. It really fits the URL concept. On the other hand, I disagree with the "dev" proposal, from the same reason.

Now you have the job to put all the interleaving and agreed upon comments in the new url draft text and start the next round. It is fun to work on the mailing list... Cheers, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Paul E. Jones paulej@packetizer.com To: Orit Levin orit@radvision.com Cc: ITU-SG16@mailbag.cps.intel.com ITU-SG16@mailbag.cps.intel.com Date: Friday, September 01, 2000 10:13 AM Subject: Re: Re: H.323 URL Specification (second try)

Orit, 1.. The reason for suggesting LRQ for RAS is simply that if you have a URL and I tell you that you use RAS to resolve this, how do you expect to resolve it? The endpoint may pass it to the GK, but the GK still has to resolve the address somehow. I don't mind removing the statement about LRQ. After all, we really need explicit procedure in Annex O to really use this URL properly. 2.. I do not like having URLs like this: h323:paulej@. I would much rather follow the conventions of UNIX programs like "finger", which allows one to do such things as "finger @hostname.com" and "finger user". It seems much more logical, in my opinion. I really only want to associate the "@" with the hostport. 3.. I don't understand your comments here. Can you clarify? Let me comment on the revisions you made to the document: "The only url-parameter defined.." -> "Currently, the only url-parameter defined" I would prefer to leave the that sentence there as it is, or modify is as follows: "The protocol parameter shall be interpreted as the..." thus removing all references to what is "currently" defined. Below, there is a statement that says that the definition of additional semicolon-delimited url-parameters, so that will address future changes.

When no protocol is specified, I said that the interpreting entity shall assume the protocol is ras. I would prefer to leave it as shall to avoid any interoperability issues.

Also, I agree that the last proposed sentence you provided about unknown parameters shall be ignored is good-- I will add that to the document.

Paul

----- Original Message ----- From: Orit Levin To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, August 31, 2000 12:47 PM Subject: Re: H.323 URL Specification (second try)

Hi Paul, Bob and others! I am attaching a slightly modified version with changes, that I think, are MUST. In addition, I have the following reservations: 0. I have a problem with explicitly binding "RAS" with "LRQ". May be, the default should be "SHALL", "RAS" and "LRQ". But "RAS" shall NOT mean "LRQ first". 1. In case only the "user" is specified, I would prefer to always have the "@" sign: "user@". Indeed, it is visually deferent from the simple "user", but - It is going to be placed in a different alias type - It will make the parsers' logic easier when distinguishing between the cases: "h323-user@; parameters" and "foreign-url-with-its-own-parameters@" - We may not predict today all possible complications. I am not sure, we will always be able to keep the user part in a clean "escaped" format. 2. Once we go forward with the currently proposed definition, we allow for each url link FOR THE REST OF THE H323-URL LIFE only a single combination of (signaling-protocol, transport-protocol, transport-protocol-port). In order to specify more then one possibility for the START procedures, separate URLs will need to be provided. Any opinions? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Paul E. Jones paulej@PACKETIZER.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: Thursday, August 31, 2000 2:07 AM Subject: H.323 URL Specification (second try)

Orit, Bob, and Others,

Please disregard the previous e-mail. It contained a slightly out-of-date revision of the text. I believe the URL proper is the same in both documents, but the surrounding text has changed.

Again, I welcome feedback.

Best Regards, Paul