Paul! 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 O work. 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 general things). BTW: I am going on vacation for two weeks starting from Saturday. (I really need it.) 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; ITU-SG16@mailbag.cps.intel.com ITU-SG16@mailbag.cps.intel.com Date: Thursday, July 06, 2000 12:35 AM Subject: Re: Re: [V4] H.323 URL
Orit,
- TD-40a defines user without "1*" on purpose, keeping the possibility
to
have an empty user defintion. In this way both user and host are
"optional",
but you can exactly parse and understand their meaning. This may be
useful
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?
- Use of DNS technology is the main reason... It is not the only
one...
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.
- "Note 4" says "The H323-URL is defined to use a form without
brackets".
Perhaps I am missing something here. Specifically what needs to be corrected? Currently, the syntax does not use brackets for IPv4 addresses.
- 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?
Thanks, Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com