upload of white draft for Annex K
Espen Skjæran (ETO)
Espen.Skjaeran at ETO.ERICSSON.SE
Fri Jun 23 12:00:27 EDT 2000
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 at radvision.com
-----Original Message-----
From: Chip Sharp <chsharp at CISCO.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 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:co
nf-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.SIEMEN
S.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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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