Paul, Orit,

This proposal looks good, but I have a few suggestions:

• The default protocol should be mandatory. In this case, flexibility kills interworking.
• The port should be specified as belonging the specified protocol.
• 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”.
• 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”.
• Do we need annex-f to be specified as a protocol? It appears to me that we have this need.
• Is “escaped” limited to two hexdigits? How does one escape to Unicode characters? This should be possible.
• If nesting is supported, how is this defined or used? If not, then there is no nesting.
• When this URL is used in the url-id field, is the URL name inclusion mandatory? If not, what is the default?
• 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).

Sorry about being so picky, but details are important when it must be correct forever.

Bob

------------------------------------------------------------------

Robert Callaghan

Siemens Enterprise Networks

Tel: +1.561.923.1756 Fax: +1.561.923.1403

Email: Robert.Callaghan@ICN.Siemens.com

------------------------------------------------------------------

-----Original Message-----
From: Orit Levin [mailto:orit@radvision.com]
Sent: Thursday, August 31, 2000 12:48 PM
To: ITU-SG16@mailbag.cps.intel.com
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