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
Orit,
- I prefer that both, syntax and text, explicitly say the same. (So how
about my syntax + your wording ?)
1* indicates that one can have one or more user parts.. I don't think that was your intent, was it? The syntax I suggested below is equivelent to *1(user). It's all the same.
- 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.
We did not have a contribution that defined this procedure, so I cannot just put something into the document. This needs to be done with care and I do not want a half-baked solution inserted into H.323. I'd prefer to wait to see contributions brought to Portland or Geneva.
- RFC2396 clearly defines and explains the "escaped" part (among other
general things).
OK.. I'll try to make some reference to that document in the text.
BTW: I am going on vacation for two weeks starting from Saturday. (I
really
need it.)
I need a vacation, too :-) Am I the one causing you so much grief that you need this vacation? :-)
Paul
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
participants (2)
-
Orit Levin -
Paul E. Jones