Dear All,
I have finally got around to submitting the URL stuff as an Internet-draft. This contains no changes to what was previously put in. When it gets accepted I will forward it to the URL-REG list to see if they have any comments.
Regards,
Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
From: Pete Cordell Sent: 17 December 1997 19:00 To: 'internet-drafts@ietf.org' Subject: Submission of internet draft
Please may I submit the following Internet draft. I have called it:
draft-sg16-conv-url-00.txt
Please let me know if there is a problem with this name.
Many thanks,
Pete Cordell
============== INTERNET-DRAFT Cordell draft-sg16-conv-url-00.txt BT Editor Dec 16, 1997 Expires: 21 June 1998
Conversational Multimedia URLsStatus of this memo
This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).{Editor's comments are in braces}
Abstract
The evolving technologies for real-time conversation over the Internet require URLs to provide user contact information. As there are many protocols (including some that are not Internet based) that can be used
for inter-user conversation, this document describes a two stage transaction process for obtaining a URL that can be used to initiate conversation. The first stage involves retrieving a list of protocol specific URLs in a MIME encoded file. The MIME type enables an appropriate application to be launched which will analyse the presented
URLs and select the most appropriate one. The second stage involves interpreting the protocol specific URL and initiating the conversation. The protocol specific URLs are encoded in a URL form so that they can be embedded directly into HTML pages. This allows the first stage to be omitted. The document describes the format of the MIME encoded list of
URLs, and the format of a number of protocol specific URLs.
Contents
ABSTRACT 1 CONTENTS 1 REVISIONS SINCE LAST VERSION 1
- INTRODUCTION 1
- THE MIME FILE 2
- PROTOCOL SPECIFIC URLS 3
3.1. COMMON URL ELEMENTS 3 3.2. H.323 URL 3 3.3. H.324 URL 5 3.4. H.320 URL 5 3.5. POTS URL 5 3.6. T.120 URL 5 4. E-MAIL LIST 6 5. SECURITY CONSIDERATIONS 6 6. ACKNOWLEDGEMENTS 6 7. REFERENCES 6 APPENDIX 1 - COMPLETE ABNF 6 AUTHOR'S ADDRESS 7
Revisions Since Last Version
Removed call-id as a parameter
- Introduction
Internet technology allows for real-time conversation to take place. It also provides a convenient method of obtaining user location information in the form of URLs. (Note: As used here, the term user can refer to a person, a machine, or any other entity a person or machine may care to have a conversation with.) These can describe Internet conversational protocols, and non-Internet based conversational mechanisms such as POTS. As there are a number of conversational protocols that can be used to contact a user, this document describes a two stage process for
initiating conversation, with the first stage being optional. The first stage retrieves a list of protocol specific URLs in a MIME encoded file. This list is analysed and the most appropriate URL is selected. The second stage involves interpreting the protocol specific URL. The protocol specific URLs are in a form that can be directly embedded into
HTML pages so that the first stage can be omitted.
The scheme presented here is designed to leverage as much as possible of existing infrastructure. As other technologies become common place (such as CMA [1] and vCard [2]) the mechanisms presented here may lapse.
The remainder of this document describes the format of the MIME file, and the format of a number of protocol specific URLs.
- The MIME file
The first stage in the contact process is to obtain a list of possible contact mechanisms. To enable a single link to be placed in an HTML page, an indirection method is used wherein a link to a MIME encoded file is made. The MIME type of the file is:
APPLICATION/TALKTOand the default extension is:
.tlkThe MIME file should be retrieved using HTTP. Files that contain time dependent protocol specific URLs should ensure that the files are marked as non-cacheable.
The MIME encoded file consists of ASCII text and lists a number of protocol specific URLs that can be used to contact a remote user. The section below describes a number of protocol specific URLs, but this should not be considered an exhaustive list.
Each protocol specific URL is presented on a separate line with no leading white space. The preferred line break convention is the one used for HTTP (CRLF), but applications must be tolerant to other line break conventions so that files can be readily edited on diverse hosts.
Each protocol specific URL may be followed by some white space and a comment. The comment should be in a form that can be presented to a user as part of a manual selection process. By default the comments are ignored. For example:
<protocol_specific_url> ;My home number <protocol_specific_url> ;My bosses number
Lines which begin with white-space should be considered as comments and
ignored. The order of the URLs should be such that the most preferred URL is presented first, and the least preferred is presented last. When interpreting the file, if a URL is unsupported, or is not understood, it should be skipped. Endpoints are encouraged to take into account the preference order indicated by the file when selecting a URL, but this is not required. Parsing of the file may continue if a contact attempt fails.
Note that the file does not contain any other information such as the times when specific URLs are valid. This enables a simple file format that does not have to cope with arbitrary search sequences and the complications of time-zones. Therefore, strictly, the file is only valid at the time it is downloaded and the HTTP cache control attributes should be used to control its validity as required.
As with any file downloaded by HTTP, it can be a static file on a server or dynamically generated by an executable. The data for the latter may
be uploaded by schemes such as the VoIP's CMA protocol[1].
Validation of who is allowed to obtain various types of location information can be done using WWW-Authentication and cookies. This document provides no additions to these HTTP mechanisms.
Example URLs for downloading the MIME file are:
http://talkto.mycom.com/me.tlk http://talkto.mycom.com/cma.exe?me{For consideration: The above scheme is simple, but not extensible. It may be prudent to define a basic extension scheme to cope with any future problems. The follwing scheme is suggested for consideration. If the line starts with a "+", then this line contains a parameter that
is optional to interpret, i.e. parsing of the file can continue even if
the parameter is not understood. If the line starts with "*", then the line contains a parameter that must be understood. The rest of the file should only be interpreted if
the parameter is understood, but earlier lines can be interpreted even if the paramter is not understood. This definition allows simple parser features and complex parser features to co-exist in the same file. e.g. a file might contain:
h323:pete@h323.bt.com *time=17:00-8:30 h323:home@h323.bt.com
where time is a paramter to be defined in the future. Parsers that don't understand the time parameter could use the first URL, but not the second}.
- Protocol Specific URLs
Protocol specific URLs describe contact information for a specific protocol. This section describes a number of these URLs, but this should not be considered an exhaustive list. Other suitable URLs include the IETF's SIP, VoIP's CMA, and Microsoft's CALLTO schemes. Although the main intention of these URLs is to describe conversational
protocols, URLs such as CHAT and MAILTO may be appropriate as a last resort. Under certain circumstances RTSP URLs may also be useful. This section starts with a description of some common elements. These are then used in the protocol specific URLs.
3.1. Common URL elements
This sub-section describes common elements from which the protocol specific URLs are constructed. A number of the elements use definitions from [3].
network = packet-network | switched-network packet-network = "ip" | "tls" | "udp" | "aal5" ; ip = IP connection without TLS ; tls = IP connection made over TLS ; udp = IP connection made over UDP - ; this channel may be made reliable ; using additional means ; aal5 = ATM AAL5 call switched-network = "pots" | "isdn" | "aal1" ; pots = GSTN or ISDN speech/audio call ; isdn = ISDN data call ; aal1 = ATM AAL1 call address = ip-address | phone-address ip-address = hostport ; hostport defined in [3] phone-address = global-phone-number *[ "&" global-phone-number ] ; global-phone-number defined in [4]. ; H.323 endpoints do not support the ; wait for tone pause character param-list = param | param param-list param = ";" h323-paramTelephone numbers in phone-address should always be presented in a full
international form, including the "+" sign. It is the responsibility of endpoints and/or gatekeepers to convert these to location specific numbers.
3.2. H.323 URL
{Note: the format of this URL has been structured to have a basic form of h323:pete@h323.bt.com. This is because users are familiar with this
format, and it is intuitive what it means. However, this does present problems when e-mail ids which include an @ are included in the URL. One solution is to include the e-mail @ in its escaped form, i.e. %40.
Another option is to specify that parsers should be tolerant of duplicate @ signs. Yet another option is to use an alternative character to represent the @ in the basic URL form, i.e. h323:pete/bt.com. This appears less intuitive, and there may be many erroneous URLs generated as the number of /s at the beginning become very significant, such as in h323:/pete.bt.com which should resolve to an IP address only. }
There are two H.323 related URLs. The first form initiates a call directly based on the information in the URL. The second initiates a call based on information that is obtained by first issuing an H.323 LRQ.
For the first form, the scheme is:
h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address [h323-param-list]and the second form is:
lrqurl = "lrq" "://" ip-address [h323-param-list]where:
h323-address = user-part | address | user-part address user-part = user [ ":" type ] "@" user = 1*alphanum ; alphanum defined in [3] type = "e164" | "h323id" | "email"The 'network' part of the URL need only be present if the network is not of type IP (i.e. ip is the default network).
If an ip-address is used in the 'address' field, the 'user' and 'type' fields specify the information to be placed in the destinationInfo part
of ARQ and destinationAddress part of SETUP. The 'type' field specifies the type of AliasAddress. If the user field starts with a digit, "*" or "#" the default type is "e164", otherwise it is "h323id".
If a 'phone-number' is used in the address field any 'user' and 'type' parts are placed in the remoteExtensionAddress part of SETUP, and the phone number is placed in the destinationInfo part of ARQ and destinationAddress part of SETUP. It is the responsibility of the receiving H.323 over ISDN gateway to transfer the remoteExtensionAddress to the destinationInfo part of ARQ and destinationAddress part of SETUP
prior to making the onward call.
To place an aliasAddress containing an @ sign in the 'user' field, the escaped form of the @ sign must be used, i.e. %40.
If the 'address' field is of type ip-address this is placed in the destCallSignalAddress fields of both ARQ and SETUP.
The H.323 URL may have a number of parameters associated with it. If an endpoint does not know how to handle a parameter then it shall ignore the entire URL. At the time of writing the valid parameters are:
h323-param = cid-param | token-param | l2-param cid-param = "cid" "=" UUID ; UUID is specified in [5] token-param = "token" "=" "0x" 1* hex l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) ; Layer 2 formatThe cid parameter encodes a UUID that should be placed in the conference ID field of the ARQ and SETUP messages. This field may appear a maximum of 1 time in the URL.
If a conference Identifier is specified, then the conferenceGoal should
be "join" in the outgoing SETUP message, otherwise it should be "create".
The token field represents a hexadecimal representation of an octet sequnce. 0, 1 or more token parameters may be included in a URL.
The 'l2' parameter allows for different packetisation schemes to be used over switched network connections. If applicable, the default is PPP.
Note that an H.323 URL with a network type of ISDN indicates that H.323
is carried over the ISDN using a layer 2 protocol such as PPP (specified by the 'l2' parameter). It does not mean that the H.323 system should locate an H.320 gateway and use this to communicate over the ISDN. The
H.320 URL should be used to indicate this.
Example H.323 URLs are as follows:
h323:pete@h323.bt.com AliasAddress = pete, AliasAddress type = h323id, destCallSignalAddress = h323.bt.com.
h323://pete@h323.bt.com Same as above
h323:646436@h323.bt.com AliasAddress = 646436, AliasAddress type = e164, destCallSignalAddress = h323.bt.com.
h323:pete@ -- This form requires a gatekeeper to determine a destCallSignalAddress AliasAddress = pete, AliasAddress type = h323id, destCallSignalAddress = GK supplied.
h323:pete.bt.com destCallSignalAddress = pete.bt.com
h323:/tls/pete%40bt.com:email@bt.com;token=0x5435;token=0xcdfe;cid=f81d4 fbf-7dec-11d0-a765-00a0c91e6bf6 This call should be setup over a secure TLS channel. AliasAddress = pete@bt.com, AliasAddress type = email-ID, destCallSignalAddress = bt.com, Two tokens are supplied. A conference ID is also specified.
h323:/pots/+1-515-234-5645 H.323 over PPP over GSTN. destCallSignalAddress = an address of an H.323 over POTS gateway. This may be gatekeeper provided. +1-515-234-5645 is placed in destinationInfo part of ARQ and destinationAddress part of SETUP.
lrq:pete@h323.bt.com Causes an LRQ to be performed first.
3.3. H.324 URL
The format of the H.324 URL is:
h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address
The default switched-network type is "pots". H.324i is denoted by having a switch-network type of "isdn". An example URL is:
h324:+1-515-234-5678or:
h324:/isdn/+1-515-234-5679&+1-515-234-56803.4. H.320 URL
The format of the H.320 URL is:
h320url = "h320" ":" phone-addressThe network type is always "isdn". An example is:
h320:/isdn/+1-515-234-5679&+1-515-234-56803.5. POTS URL
The telephone number scheme for a basic voice call is defined in [4].
3.6. T.120 URL
The format of the T.120 URL is:
t120url = "t120" ":" [ "/" [ network ] "/" ] address [t120-param-list]The following parameters are valid: ???????
- E-mail list
As many groups are interested in conversational URLs including SG16, VoIP, MMUSIC, PINT, TIPHON, URL-REG etc), a separate e-mail list has been set up. You can subscribe to the list by including the word "subscribe" in the message body text of an e-mail sent to the address:
h323-url-request@vocaltec.comE-mail can be sent to the list at the following address:
h323-url@vocaltec.com
- Security Considerations
Umm...
Acknowledgements
References
[1] "Service Interoperability Implementation Agreement," IMTC VoIP Forum [2] vCard [3] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URL)," RFC1738, December 1994. {Editor's note: A new version of RFC1738 is being produced so this reference will have to be changed.} [4] A. Vaha-Sipila, "URLs for Telephony," draft-antti-telephony-url-03.txt, 21 Nov 1997 [5] "Call Signalling Protocols and media Stream Packetization for Packet Based Multimedia Communications Systems," ITU-T Recommendation H.225 Version 2, January 1998
Appendix 1 - Complete ABNF
all-urls = h323url | lrqurl | h324url | h320url | t120url
h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address [ h323-param-list ] lrqurl = "lrq" "://" ip-address [ h323-param-list ] h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address h320url = "h320" ":" phone-address t120url = "t120" ":" [ "/" [ network ] "/" ] address [ t120-param-list ]
network = packet-network | switched-network packet-network = "ip" | "tls" | "udp" | "aal5" switched-network = "pots" | "isdn" | "aal1"
h323-address = user-part | address | user-part address user-part = user [ ":" type ] "@" user = 1*alphanum ; alphanum defined in [3] type = "e164" | "h323id" | "email"
address = ip-address | phone-address
ip-address = hostport ; hostport defined in [3]
phone-address = global-phone-number *[ "&" global-phone-number ] ; global-phone-number defined in [4]. ; H.323 endpoints do not support the ; wait for tone pause character
h323-param-list = ";" h323-param | ";" h323-param h323-param-list
h323-param = cid-param | token-param | l2-param cid-param = "cid" "=" UUID ; UUID is specified in [5] token-param = "token" "=" "0x" 1* hex l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) ; Layer 2 format
t120-param-list = ";" t120-param | ";" t120-param t120-param-list t120-param = {???????}
Author's Address
Pete Cordell BT Labs MLB 4/15 Martlesham Heath Ipswich IP5 3RE UK e-mail: pete.cordell@bt-sys.bt.co.uk
================================= Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
participants (1)
-
Pete Cordell