[V4] H.323 URL
orit at radvision.com
Thu Jul 6 12:32:58 EDT 2000
These are my comments:
1) I prefer that both, syntax and text, explicitly say the same. (So how
about my syntax + your wording ?)
3) Agreed. It is up to you to come up with the text, that will be clear
enough, but, in the same time, will not be restrictive for the sake of Annex
4) Nothing is required to be corrected here. We can drop this Note 4 at all.
May be it is more confusing then clarifying. It just says, that in other
protocols, the IP address definition may be different.
5) RFC2396 clearly defines and explains the "escaped" part (among other
BTW: I am going on vacation for two weeks starting from Saturday. (I really
575 Corporate Drive Suite 420
Mahwah, NJ 07430
Tel: 1 201 529 4300 (230)
Fax: 1 201 529 3516
orit at radvision.com
From: Paul E. Jones <paulej at packetizer.com>
To: Orit Levin <orit at radvision.com>; ITU-SG16 at mailbag.cps.intel.com
<ITU-SG16 at mailbag.cps.intel.com>
Date: Thursday, July 06, 2000 12:35 AM
Subject: Re: Re: [V4] H.323 URL
>> 2) TD-40a defines user without "1*" on purpose, keeping the possibility
>> have an empty user defintion. In this way both user and host are
>> but you can exactly parse and understand their meaning. This may be
>> in Discovery Procedures (as mentioned in TD-40a).
>I changed the syntax as follows:
> H323-URL = "H323:" [ user ] [ "@" hostport ]
>and I changed the text below to read
>``As indicated in the syntax, the user string and the hostport string are
>both optional, though at least one shall be present.''
>How is that?
>> 3) Use of DNS technology is the main reason... It is not the only
>> Agreed, of cause. Still, a short "motivation" phrase to be included into
>> H.323v4 is desired. (I also agree that Annex O should describe the
>> recommended procedures :-)
>Motivation without procedure is not very helpful. We must have a
>contribution that clearly defines the procedure.
>> 4) "Note 4" says "The H323-URL is defined to use a form without
>Perhaps I am missing something here. Specifically what needs to be
>corrected? Currently, the syntax does not use brackets for IPv4 addresses.
>> 6) In regards to "escaped". I had the same dilemma while writing the
>> original APC-1775. "One of the RFCs " summarizes the explanations already
>> existing in referenced by us general RFCs. So, I think, we don't need a
>> summary here.
>Do you recall which RFC and section discusses the "escaped" production?
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd