H.245 Draft White paper uploaded to server

Mike Nilsson mike.nilsson at BT.COM
Mon Jun 19 12:36:18 EDT 2000


A few observations on the current proposal for an H.323 URL:

URL Registration:
If you want to define a new URL (i.e., H323:), please consider if you want
a new registration tree for ITU or if you want to use the IETF registration
tree.  You might want to start an ITU registration tree, or even a ITU-SG16
registration subtree with IANA.  See
ftp://ftp.isi.edu/in-notes/bcp/bcp35.txt (BCP35) for more info on what I mean.

Principle of "least surprise":
If you click on the URL above for BCP35 you will probably expect your mail
application to open an ftp application and download the file to your
computer.  If I click on a URL "telnet://foo.bar.com" I'd expect a telnet
application to open that would telnet me to "foo.bar.com".  I would expect
an H.323 URL to do the same thing.  For example if I click on the URL
"h323:paulej at packetizer.com" given below, I would expect my H.323
application to open and attempt to call Paul using the address given
(paulej at packetizer.com).  My H.323 app would have to be configured with
certain default parameters for operation (e.g., voice call, G.711 codec,
etc.) as well as default operation for resolving the name to an IP address
(e.g., use DNS to find the gatekeeper based on "packetizer.com" and use the
identified gatekeeper to find Paul's IP address based on "paulej").  These
may be defined in the H.323 URL definition. If you want H.323 URL to be
used ubiquitously by end-users I'd recommend making its operation as simple
as possible and as close as possible to other URLs.  See Section 2 of
ftp://ftp.isi.edu/in-notes/rfc2543.txt  for how the SIP URL is defined as
an example.

email-id:
I'm assuming when saying something should be in format defined in RFC822
that you mean the "addr-spec" production as defined in Appendix D of RFC822
since RFC822 also defines all the mail headers used in SMTP.  I believe an
H.323 URL could be encoded to be consistent with RFC822, but you have to
take into account the escaping of special characters (e.g., ":" and "/") as
well as semantics.

I noticed the ABNF in one of the emails below substantially copies from
RFC822 the definition of "addr-spec".  If you do this, you might want to
check the procedures for copying text from IETF RFCs as defined in A.5.

What field to use:
IMHO the only field a URL should be put into is the URL-id field.  A URL is
self-identifying in terms of application (e.g., "mailto:" -> email,
"ftp:" -> FTP, "http:" -> HTTP, etc.).  Putting a URL into one of the other
fields would require careful definition of the interaction of the semantics
of the field name and the URL type.  Of course, there may be advantages of
putting URLs into other fields that I'm not aware of.

ABNF reference:
To be consistent with other recommendations (e.g., H.248), reference
ftp://ftp.isi.edu/in-notes/bcp/rfc2234.txt (RFC2234) for the definition of
ABNF instead of RFC822.  This is the IETF Standards Track RFC defining
ABNF. Also, a nit about the ABNF in TD40 is that RFC2234 (and RFC822) use a
"/" instead of "|" to denote a choice.  This is a common mistake.

KISS principle:
Related to principle of least surprise, I'll echo Bob's concern buried in
this thread that making the URL too complex (especially at the front end)
will minimize its usefulness.  A user should have the same level of
expectation of what will happen if they click on an H.323 URL as they do
for a HTTP URL.

Chip

At 03:15 AM 6/19/00 -0400, Paul E. Jones wrote:
>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