[V4] H.323 URL
Paul E. Jones
paulej at PACKETIZER.COM
Thu Jul 6 16:17:43 EDT 2000
Orit,
> 1) 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.
> 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.
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.
> 5) 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 at radvision.com
> -----Original Message-----
> 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
>
>
> >Orit,
> >
> >> 2) 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?
> >
> >> 3) 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.
> >
> >> 4) "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.
> >
> >> 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?
> >
> >Thanks,
> >Paul
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
mailing list