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.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
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@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.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
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
Also, conference ID and tokens can be useful for accessing conferences and special services. e.g.:
h323url = "h323:" ...other stuff... *( ";" h323-param )
h323-param = cid-param | token-param cid-param = "cid" "=" UUID ; UUID is specified in [5] token-param = "token" "=" "0x" 1* hex
Pre-declaring that parameters may exist also allows for future extensibility.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Paul E. Jones paulej@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 16 June 2000 08:11 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@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.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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Callaghan, Robert -
Paul E. Jones -
Pete Cordell