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@radvision.com -----Original Message----- From: Paul E. Jones paulej@PACKETIZER.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@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@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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com