My comments are inside the text. Orit

-----Original Message----- From: Callaghan, Robert Robert.Callaghan@icn.siemens.com To: 'Orit Levin' orit@radvision.com; ITU-SG16@mailbag.cps.intel.com ITU-SG16@mailbag.cps.intel.com Date: Thursday, August 31, 2000 4:44 PM Subject: RE: H.323 URL Specification

Paul, Orit,

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

a.. The default protocol should be mandatory. In this case, flexibility kills interworking. b.. OL: I agree.So the default for EACH ommited field is separately to be specified. c.. The port should be specified as belonging the specified protocol. d.. OL: Only Semantically? or also syntactically? I vote for syntactically as well. e.. For protocol, use “h225rs” or “h323rs” instead of “ras”. This controls the confusion with the dial-in protocol know as RAS. f.. For protocol, use “h225cs” or “h323cs” instead of “q931”. This controls the confusion with real Q.931 g.. For protocol, use “h225ar” or “h323ar” instead of “annex-g”. h.. OL: I don't mind. i.. 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”. j.. OL: Yes, LRQ is definitely limiting k.. Do we need annex-f to be specified as a protocol? It appears to me that we have this need. l.. OL: I don't think so. We have the whole RAS procedure to negotiate it. As all other things, like the protocol to start from (i.e. the pre-granted ARQ). It is an never ending story. On the other hand, the specification for the TRANSPORT protocol is needed. Therefore, I would prefer to define a triple of (signalling, transport and the transport-port) - the way it is defined in the "Annex O" draft. m.. Is “escaped” limited to two hexdigits? How does one escape to Unicode characters? This should be possible. n.. OL: This has to be taken care of. o.. If nesting is supported, how is this defined or used? If not, then there is no nesting. p.. OL: The nesting has eventually be supported. I think, we can leave it to "Annex O" without breaking backwords compatibility. The nesting is done using the "user" field and is described in draft "Annex O". The "user-parameter" is added for that. If the parameter is not included, it is the destination domain policy to define and support the nesting. q.. When this URL is used in the url-id field, is the URL name inclusion mandatory? If not, what is the default? r.. OL: the scheme-name MAY be included. For H.323 url it is not mandatory. s.. 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). t.. OL: Yes, I thinks it is one procedure less, which is definitely a positive thing. If we agree on that, may we disallow the "user only" URL? It will solve additional issues...

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