Orit,

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