[V4] H.323 URL
Paul E. Jones
paulej at PACKETIZER.COM
Fri Jun 30 17:00:07 EDT 2000
You proposed to remove this sentence:
``An endpoint may accept any valid URL that it understands, but H.323
entities should also support the H.323 URL as defined in this section.''
However, I prefer to keep it or something like it. I do not want people to
believe that the H.323 URL is the only valid URL that may be used within an
H.323 entity. I changed the sentence to this to not be restrictive to
``An H.323 entity may accept any valid URL that it understands, but should
support the H.323 URL as defined in this section.''
You suggested this line addition:
``...by using the DNS technology widely deployed in Internet and other IP
Bob mentioned that he might want to query a non-DNS database. Certainly,
DNS will not work for a URL of this form: h323:+19193876899
We should probably expand the text a bit more and say that if the URL is in
the form of "user at hostport", the host portion may be considered for some
type of DNS query. However, we do not have any defined procedures for DNS
queries using this scheme.. and that's a topic for Annex O, I guess. I'd
hate to be restrictive in this section until we have defined the procedures.
Regarding comments (4) and (5)... I assume you mean "Note 4" and "Note 5"?
If you want the IP address to be enclosed in brackets when it is IPv4, we
need to modify the syntax. However, I don't think that it is necessary.
RFC 2396, which is the source of much of this syntax, does not use brackets
for IPv4 addresses. They are, however, used in IPv6 addresses as Michael
Welser in an earlier message. Note 5 is a valid note and I have added it to
I also question the "escaped" production. I understand what it's for, but
we do not explain it. Do we need a paragraph explaining it or is there a
reference we should make? I suspect there is text one of the RFCs that
already describes this clearly.
I have attached the modified section of text this e-mail for review.
----- Original Message -----
From: "Orit Levin" <orit at radvision.com>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: Friday, June 30, 2000 3:43 PM
Subject: H.323 URL
> Hi Paul and all the others!
> This is my attempt to articulate the H323-URL motivation and use in the
> shortest way.
> I don't have any problem with expanding or/and tightening the definition
> the H.323 URL.
> I think we should incorporate the real syntax corrections now.
> Nevertheless, I would prefer to decide a BASIC H323-URL in a way which
> it possible for later backwards compatible modifications.
> I addition to that, I think that comments (4) and (5) from TD-40a should
> appear in the decided document.
> Orit Levin
> RADVision Inc.
> 575 Corporate Drive Suite 420
> Mahwah, NJ 07430
> Tel: 1 201 529 4300 (230)
> Fax: 1 201 529 3516
> orit at radvision.com
> -----Original Message-----
> From: Michael Welser <michael.welser at AON.AT>
> To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
> Date: Friday, June 30, 2000 5:43 AM
> Subject: Re: H.323 URL Text
> >I propose to change the ABNF to the following:
> > H323-URL = "H323:" user [ "@" hostport ]
> > user = 1*( unreserved / escaped )
> > hostport = host [":" port]
> > host = hostname / IPv4address / IPv6reference
> > hostname = *( domainlabel "." ) toplabel [ "." ]
> > domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum
> > toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
> > IPv6reference = "[" IPv6address "]"
> > IPv6address = hexpart [ ":" IPv4address ]
> > IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
> > IPv6prefix = hexpart "/" 1*2DIGIT
> > hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
> > hexseq = hex4 *( ":" hex4)
> > hex4 = 1*4HEXDIG
> > port = 1*DIGIT
> > unreserved = alphanum / mark
> > alphanum = ALPHA / DIGIT
> > mark = "-" / "_" / "." / "!" / "~" / "*" / "'"
> > / "(" / ")" / "&" / "=" / "+" / "$" / ","
> > escaped = "%" HEXDIG HEXDIG
> >This introduces IPv6 adresses according to RFCs 2732, 2373 and 2396. The
> >ABNF still relies on RFC 2234.
> >It also corrects the IPv4 address by limiting each segment to three
> >I am not too sure about the 'port'. Although 1*DIGIT makes absolutely
> >sense, most schemes currently in use are more relaxed about it and just
> >do a DIGIT.
> >I am also not too sure about the extended user definition and the
> >password extension which are used e.g. in SIP and HTTP:
> > H323-URL = "H323:" userinfo [ "@" hostport ]
> > userinfo = user [ ":" password ]
> > user = *( unreserved / escaped
> > / "&" / "=" / "+" / "$" / "," )
> > password = *( unreserved | escaped
> > / "&" / "=" / "+" / "$" / "," )
> > etc.
> >Could we need that?
> >(welser at acm.org)
> >> -----Original Message-----
> >> From: Mailing list for parties associated with ITU-T Study Group 16
> >> [mailto:ITU-SG16 at mailbag.cps.intel.com]On Behalf Of Paul E. Jones
> >> Sent: Monday, June 26, 2000 12:23 PM
> >> To: ITU-SG16 at mailbag.cps.intel.com
> >> Subject: H.323 URL Text
> >> Folks,
> >> I have attached the text that I propose adding to the H.323v4 document
> >> relating to the H.323 URL scheme. I think this text is weak,
> >> but I expect
> >> contributions to be brought to define the usage of this
> >> scheme-- presently,
> >> there really is no procedural text.
> >> I'd like to point out that I removed the telephone number
> >> portions of the
> >> URL, which should make both Orit and Bob happy :-)
> >> Please review the text and the ABNF grammar for errors. You
> >> will note one
> >> small bit of procedural text near the end where it discusses
> >> the fact that a
> >> Gatekeeper may modify the alias provided to the Gatekeeper.
> >> The substance
> >> of that existed in TD-50 (Osaka) and I thought that it was
> >> important to go
> >> ahead and include that at the very least.
> >> Please, give me feedback. Mr. Bowen and I plan to post H.323v4 and
> >> H.225.0v4 this week for review. A formal announcement will
> >> be made later
> >> today or tomorrow.
> >> Best Regards,
> >> Paul
> >For help on this mail list, send "HELP ITU-SG16" in a message to
> >listserv at mailbag.intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3474 bytes
Desc: not available
More information about the sg16-avd