H.323 URL
Chip Sharp
chsharp at CISCO.COM
Thu Jun 22 08:44:30 EDT 2000
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 at ICN.SIEMENS.COM>Callaghan, Robert
>>To: <mailto:ITU-SG16 at mailbag.cps.intel.com>ITU-SG16 at 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 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