H.323 URL
Chip Sharp
chsharp at CISCO.COM
Tue Jun 20 12:38:38 EDT 2000
Read the following concerning registering a URL scheme:
ftp://ftp.isi.edu/in-notes/bcp/bcp35.txt
SG16 must first decide if it wants to register the scheme as an IETF scheme
or if it wants to start a new registration tree, say the ITU registration tree.
If the latter, SG16 (or ITU) would have to develop a document that defines
the registration procedures for new URL schemes registered under the ITU
tree.
You would then follow those procedures for registering the H.323 URL. Note
that BCP35 implies that the IESG must approve the document defining the
registration procedures and change control for new trees.
For example, if the new tree is named "itu" then the h323 URL should
probably be named "itu-h323". I don't believe there is any requirement to
publish the new scheme in IETF, but it could be published as an I-D and
Informational RFC for wider review.
If you choose to allocate a scheme from the IETF tree, I believe the
document defining the scheme has to be published as a standards-track IETF
document. BCP35 also lists several other requirements.
I've never done this. The above info is just taken from BCP35. If I find
out anything further, I'll let you know.
Chip
At 11:54 AM 6/20/00 -0400, Orit Levin wrote:
>Bob, sorry for being unclear. This is why face-to-face discussions are,
>after all, more efficient.
>I agree with all (?) your points. What I wanted to say is, that H323-URL,
>in its current format, provides sufficient means for
>- originator's local application to activate H.323 application, while
>configured consistently within its zone policies
>- zone's server (most probably a GK.) to invoke DNS based address
>resolution procedure, based on the received H323-URL
>
>The current H323-URL definition and the proposed text are NOT sufficient
>(but BOTH are expandable) to provide more functionality to that, we have
>today, such as:
>- meaning of non-H323 URLs in H.323 messages and the corresponding procedures
>- H323-URL used in WEB pages when extensive configuration means are not
>available and/or not sufficient
>
>Now, to Chip's remarks. It seems to me helpful to add this kind of "url
>tutorial" to Annex O. After all, what may be seen obvious to the authors,
>is not necessarily obvious to the readers/implementers of H.323.
>Chip, I have a question to you. I send a request to IANA, as to the
>procedures to add the new H323-URL identifier. No answer so far. Any
>help/guidance would be appreciated.
>
>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.com>www.radvision.com
><mailto:orit at radvision.com>orit at radvision.com
>>-----Original Message-----
>>From: Callaghan, Robert
>><<mailto:Robert.Callaghan at ICN.SIEMENS.COM>Robert.Callaghan at ICN.SIEMENS.COM>
>>To: <mailto:ITU-SG16 at MAILBAG.INTEL.COM>ITU-SG16 at MAILBAG.INTEL.COM
>><<mailto:ITU-SG16 at MAILBAG.INTEL.COM>ITU-SG16 at MAILBAG.INTEL.COM>
>>Date: Monday, June 19, 2000 2:51 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 at radvision.com]
>>Sent: Monday, June 19, 2000 10:06 AM
>>To: ITU-SG16 at 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:
>>1. 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.com>www.radvision.com
>><mailto:orit at radvision.com>orit at radvision.com
>>>-----Original Message-----
>>>From: Paul E. Jones <<mailto:paulej at PACKETIZER.COM>paulej at PACKETIZER.COM>
>>>To: <mailto:ITU-SG16 at MAILBAG.INTEL.COM>ITU-SG16 at MAILBAG.INTEL.COM
>>><<mailto:ITU-SG16 at MAILBAG.INTEL.COM>ITU-SG16 at 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 at packetizer.com>h323:paulej at 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 at packetizer.com;cid:XXXX-XXXX-XXXX-XXXX>h323:conf-server1 at 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 at NORTELNETWORKS.COM>Francois Audet
>>>>To: <mailto:ITU-SG16 at mailbag.cps.intel.com>ITU-SG16 at 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 at ICN.SIEMENS.COM>mailto:Robert.Callaghan at ICN.SIEMENS.COM]
>>>>
>>>> > Sent: Friday, June 16, 2000 5:39 AM
>>>> > To: <mailto:ITU-SG16 at MAILBAG.INTEL.COM>ITU-SG16 at 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 at ICN.Siemens.com
>>>> > ------------------------------------------------------------------
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: Paul E. Jones
>>>> [<mailto:paulej at packetizer.com>mailto:paulej at 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 / nonStandardAddress
>>>> > ipAddress = 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 at icn.siemens.com>
>>>> > To: "'Orit Levin'" <orit at radvision.com>; "'Paul E. Jones'"
>>>> > <paulej at PACKETIZER.COM>
>>>> > Cc: "Mailing list for parties associated with ITU-T Study
>>>> > Group 16 (E-mail)"
>>>> > <ITU-SG16 at 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 at ICN.Siemens.com
>>>> > > ------------------------------------------------------------------
>>>> > >
>>>> > >
>>>> > > -----Original Message-----
>>>> > > From: Orit Levin
>>>> [<mailto:orit at radvision.com>mailto:orit at 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 at radvision.com
>>>> > > -----Original Message-----
>>>> > > From: Callaghan, Robert <Robert.Callaghan at icn.siemens.com>
>>>> > > To: 'Paul E. Jones' <paulej at PACKETIZER.COM>; 'Orit Levin'
>>>> > > <orit at radvision.com>
>>>> > > Cc: Mailing list for parties associated with ITU-T Study
>>>> > Group 16 (E-mail)
>>>> > > <ITU-SG16 at 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 at ICN.Siemens.com
>>>> > > >------------------------------------------------------------------
>>>> > > >
>>>> > >
>>>> >
>>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> > For help on this mail list, send "HELP ITU-SG16" in a message to
>>>> > listserv at 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 at mailbag.intel.com
More information about the sg16-avd
mailing list