Chip, I agree and taking care of that.
Before the decision where to register H323 url (and after the reading of BCP-35) this is my take on it: To register H323 url under a new ITU tree may be a quicker process and more flexible for later changes. The disadvantage is that we (ITU) need to define procedures for ITU tree maintenance/"change control". To register H323 url under IETF would require either RFC standard track document (I don't believe in such a thing for H.323) or Informational RFC carefully inspected by IESG for all possible implications. Your opinions, please! 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: Chip Sharp chsharp@CISCO.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: Thursday, June 22, 2000 9:14 AM Subject: Re: H.323 URL
I don't disagree with your proposal; however... :-)
If it is going to be called a URL, it needs to be registered as per BCP35. Otherwise, use of the term URL will be confusing to the industry.
Chip
At 01:46 AM 6/22/00 -0400, Paul E. Jones wrote:
Bob,
Perhaps the simplest solution is for the white paper to contain the agreed syntax thus far from TD-40, without any of the other content. I agree that it is probably illegal to say that the H.323 URL can be copied into the e-mail ID field. However, if the syntax following h323: suggested that what follows is some generic identifier and its attributes, an e-mail address, or telephone number based on the format, then I believe it would be valid to say we could copy the e-mail address into that alias field. However, I don't know how to interpret the octets following the
h323:.
Could we agree to have a section that defines the shows the URL syntax without procedure and agree that the procedural text will be added to Annex O? I would even suggest to put the URL definition in Annex O, too, but we have a timing problem with respect to Annex K-- it needs that definition now.
Thoughts?
Paul
----- Original Message ----- From: mailto:Robert.Callaghan@ICN.SIEMENS.COMCallaghan, Robert To: mailto:ITU-SG16@mailbag.cps.intel.comITU-SG16@mailbag.cps.intel.com Sent: Monday, June 19, 2000 2:46 PM Subject: Re: H.323 URL
Orit,
I am not now sure what was agreed to, other that to let TD-40a to move forward.
I do agree with the three points in your note.
I do not agree that the proposal was limited to Call Control Messages. I see no difference between the use of H.323-URLs on a Web page and the use of H.3233-URLs in Call Control. The one directly leads to the latter.
I am not sure if you are implying that only H.323-URL can be used to direct a call to an H.323 destination. If so, I disagree. All alias formats work equally well. My understanding is that Paul Jones wanted the E.164 format of the H.323-URL in order to access the gateway using the H.323 client as a telephony client. This definitely does not point to an H.323 URL.
I am afraid that we may not know what we agreed to, other than to proceed. That is why I objected that the URL be included in v4 instead of and annex or appendix. Now our lack of understanding as to what we understood will jeprodice v4 if it remains as is. But that was the agreement, so we must proceed forward.
Bob
-----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Monday, June 19, 2000 10:06 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: H.323 URL
Dear all! There are two faces to H323-URL. The first one is when H.323-URL is used as an alias in H.323 Call Control messages. The second is when H.323-URL is used in Web pages or other hyperlinks. (Although, when both are in place, from procedural point of view their order is vice versa.)
In my contribution in Osaka, I chose to address "the first case" first. There are number reasons for this:
- URL concept exists in H.323 since version 2. The procedures, how URLs
should be used, haven't been defined. This clearly invites interoperability problems. 2. H323-URL hasn't been defined at all. This leads to interpretation of other URLs, to be used INSTEAD, while reaching pure H.323 entities! This clearly invites interoperability problems. 3. Standard H323-URL can greatly facilitate address translation procedure, when H.323 runs on Internet.
As it can be seen from TD-40a, it has been agreed, that H323-URL should be used to POINT TO H.323 DESTINATION. Other URLs may/should be used in H.323 messages to point to other destinations. Personally, I see this approach as the best. Also Bob and Francoise supported this in their last e-mails. Please, lets try not to open already agreed things before the next meeting, jeopardizing by that H.323v4 decision. Specifically on H323-URL topic, we have to clean things (such as the use of email ID alias) and put the basic version onto H.323v4. Then we will have "Annex O" to expand on additional "complimentary to H.323" procedures.
One of these procedures is "the second face" of H323-URL: while used in WEB pages. It is clear that H.323-URL should be expanded with additional parameters to be used as such. It is also mentioned in TD-40a. Contributions are mostly welcome.
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 http://www.radvision.comwww.radvision.com mailto:orit@radvision.comorit@radvision.com
-----Original Message----- From: Paul E. Jones
<mailto:paulej@PACKETIZER.COMpaulej@PACKETIZER.COM>
To: mailto:ITU-SG16@MAILBAG.INTEL.COMITU-SG16@MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COMITU-SG16@MAILBAG.INTEL.COM> Date: Monday, June 19, 2000 3:27 AM Subject: Re: H.323 URL
Francois,
If I want to provide a means of allowing somebody to call me by placing a URL on a web page, I need to provide something that can be resolved universally by H.323 endpoints. Bob mentioned querying a database-- that's certainly a possibility, assuming that that database contains all of the information it needs to resolve an address.
What I am afraid of here is that we are introducing syntax to reach a resource without defining any procedure.
If I see this url: mailto:h323:paulej@packetizer.comh323:paulej@packetizer.com
What does that tell the H.323 entity? Is there a GK that is expecting a LRQ, AccessRequest, or is it something else entirely? Perhaps the right solution is to define (in normative text) the procedure for using SRV DNS records to query the packetizer.com domain.
As Pete rightfully pointed out, an H.323 URL would be the perfect place to place conference identifiers for multipoint conferences:
mailto:h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXXh323:co
nf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX
I think we need to work on the procedural part of this now. Who is working on that?
Paul
----- Original Message ----- From: mailto:audet@NORTELNETWORKS.COMFrancois Audet To:
mailto:ITU-SG16@mailbag.cps.intel.comITU-SG16@mailbag.cps.intel.com
Sent: Friday, June 16, 2000 11:48 AM Subject: Re: H.323 URL
I would agree with Bob here. Using an H.323 URL for a telephone number would imply that you can only be reached using H.323. Is this you intention?
-----Original Message----- From: Callaghan, Robert
[mailto:Robert.Callaghan@ICN.SIEMENS.COMmailto:Robert.Callaghan@ICN.SIEMEN S.COM]
Sent: Friday, June 16, 2000 5:39 AM To: mailto:ITU-SG16@MAILBAG.INTEL.COMITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 URL
Paul,
I think that this is getting complicated.
I did not envision the use of the H.323-URL to encompase a telephone number. I only conceede for the purpose of progress.
I saw the H.323-URL to be an identifier that would be used to access
a
database. The DNS portion would identify the database, the userID would be the entry in the database. The database would then return the necessary information to complete the call. It is highly propable that this information would include an E.164 or PNP address. This is especially true when the call must be ompleted over the SCN.
I saw telephone numbers being defined in the "Tel:" URL defined in RFC2806. This URL covers many of optional fields needed to make an SCN call which are not presently covered in H.323.
If we are to have multiple forms of an H.323 URL, I would prefer to have multi-URL IDs.
Bob
P.S. (By the way, the complex, cover everything, is where the last try at an H.323 URL diaappeared.)
Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com
-----Original Message----- From: Paul E. Jones
[mailto:paulej@packetizer.commailto:paulej@packetizer.com]
Sent: Friday, June 16, 2000 3:11 AM To: Callaghan, Robert; 'Orit Levin' Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) Subject: Re: H.323 URL
Bob,
I'm still surprised that you don't want to see the URL expanded... especially to address party number types. Here is is currently:
H323-URL = "H323:" user ["@" hostport] user = username | phone-number username = *( unreserved | escaped | "&" | "=" | "+" | "$" | "," ) hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | "," digits = 1*DIGIT
However, to be useful, information that follows the "h323:" should
be
something in a form that an H.323 Gatekeeper can resolve. Those things include: dialedDigits h323-ID email-ID partyNumber or one of the transportAddress types.
This seems to be a reasonable syntax:
H323-URL = "H323:" Address Address = AliasAddress / TransportAddress AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber dialedDigits = "dialedDigits=" 1*digit h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the BMPString email-ID = "email-ID=" email-ID-spec partyNumber = e164Number / dataPartyNumber / telexPartyNumber / privateNumber / nationalStandardPartyNumber email-ID-spec = mailbox / group group = phrase ":" [ mailbox ] ";" phrase = 1*word word = atom / quoted-string atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "" / <"> ; string, to use / "." / "[" / "]" ; within a word. quoted-string = mailbox = addr-spec / phrase route-addr addr-spec = local-part "@" domain local-part = word *("." word) domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom domain-literal = "[" *(dtext / quoted-pair) "]" dtext = 1*CHAR ; Any CHAR excluding "[", "]", "" & CR, ; & including linear-white-space> linear-white-space = 1*([CRLF] LWSP-char) LWSP-char = SP / HTAB quoted-pair = "" CHAR phrase = 1*word route-addr = "<" [route] addr-spec ">" route = "@" domain ":" e164Number = "e164Number=" publicTypeOfNumber "," digits digits = 1*(DIGIT / "#" / "*" / ",") publicTypeOfNumber = "unknown" / "internationalStandard" / "nationalNumber" / "networkSpecificNumber" / "subscriberNumber" / / "abbreviatedNumber" dataPartyNumber = "dataPartyNumber=" digits telexPartyNumber= "telexPartyNumber=" digits privatePartyNumber = "privatePartyNumber=" privateTypeOfNumber "," digits privateTypeOfNumber = "unknown" / "level2RegionalNumber" / "level1RegionalNumber" / "pISNSpecificNumber" / "localNumber" / "abbreviatedNumber" TransportAddress = ipAddress / ipSourceRoute / ipxAddress /
ip6Address
/ netBios / nsap / nonStandardAddressipAddress = ip ":" port ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT port = 1*DIGIT ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" / "loose") ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" netBios = ;; and so forth nsap = nonStandardAddress =
Now, there may be an error or two in there, but at least it is more complete and an H.323 system knows how to work with these. (Note I did not address the new V4 alias "mobileIUM")
If we used this grammar, I don't think we would need a lot of strange rules about what you do with the URL. Basically, you take it apart according to its internal parts to form an alias address that a Gatekeeper can resolve.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Orit Levin'" orit@radvision.com; "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "Mailing list for parties associated with ITU-T Study Group 16 (E-mail)" ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, June 14, 2000 3:50 PM Subject: RE: H.323 URL
> Orit, > > In my opinion, an email-ID alias conforms to RFC-822 and is interpreted > according the rules stated in H.225.0. An H.323-URL-ID conforms
to
> TD-40a/Osaka and is interpreted according to the rules stated in TD-40a. An > H.323-ID is a character string without any rules of interpretation. I see > no need to blend these contexts. All three addressing modes can be use; > each in its own context. > > However, these are my opinion. Maybe more work is needed in Portland. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan@ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Orit Levin
[mailto:orit@radvision.commailto:orit@radvision.com]
> Sent: Wednesday, June 14, 2000 11:45 AM > To: Callaghan, Robert; 'Paul E. Jones' > Cc: Mailing list for parties associated with ITU-T Study Group 16 > (E-mail) > Subject: Re: H.323 URL > > > Hello Bob and Paul! > I don't see backwards compatibility problem, when the URL says explicitly > H323-URL. An appropriate change may be to state, that the default meaning of > url, encoded into email-ID alias, is according to RFC-822. > Now, I feel a need to put a chapter explaining what is the meaning of email > URL (apart from its syntax) when used in H.323 Network. There is some > explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? > 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: Callaghan, Robert Robert.Callaghan@icn.siemens.com > To: 'Paul E. Jones' paulej@PACKETIZER.COM; 'Orit Levin' > orit@radvision.com > Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) > ITU-SG16@mailbag.cps.intel.com > Date: Wednesday, June 14, 2000 9:56 AM > Subject: H.323 URL > > > >Paul, > > > >I have a backward compatibility item for you to think about. > > > >TD-40/Osaka states that the H323-URL may be coded into the email-ID for > >alias address. However, H.225.0 states that the email-ID shall conform to > >RFC822. This is an exclusionary requirement in that other standards may > not > >be used. Also, Note 4 of the BNF definition of the H323-URL clearly states > >that that the H323-URL is *not* compatible with RFC822. > > > >Therefor, I propose that the H323-URL cannot be coded into the email-ID for > >alias address because of compatibility problems. > > > >Bob > > >
> >Robert Callaghan > >Siemens Enterprise Networks > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 > >Email: Robert.Callaghan@ICN.Siemens.com >
> > >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org
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