[V4] H.323 URL
Orit Levin
orit at radvision.com
Wed Jul 5 12:23:38 EDT 2000
1) I agree with
"An H.323 entity may accept any valid URL that it understands, but should
support the H.323 URL as defined in this section.''
I am not sure that it should be in this specific place in H.323v4, because
it invites more questions then clarifies the H323-URL topic, ... but I will
not object.
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).
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 :-)
4) "Note 4" says "The H323-URL is defined to use a form without brackets".
5) I completely agree that IPv6 addresses should be included. The
definition seems syntactically correct to me... till somebody finds an
error.
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.
Best Regards,
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: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: Friday, June 30, 2000 5:10 PM
Subject: [V4] H.323 URL
>Orit,
>
>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
>endpoints:
>``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
>networks.''
>
>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
>the text.
>
>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.
>
>Paul
>
>----- 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
>of
>> 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
>makes
>> 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.
>> Regards,
>> 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: 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
>> >digits.
>> >
>> >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?
>> >
>> >Cheers,
>> >
>> >Michael
>> >(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
>>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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