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@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@radvision.com To: ITU-SG16@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@radvision.com -----Original Message----- From: Michael Welser michael.welser@AON.AT To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@acm.org)

...

-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.intel.com]On Behalf Of Paul E. Jones Sent: Monday, June 26, 2000 12:23 PM To: ITU-SG16@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@mailbag.intel.com