[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