FW: Submission of Internet draft
Pete Cordell
pete.cordell at BT-SYS.BT.CO.UK
Wed Dec 17 14:03:13 EST 1997
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 at 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 at 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 URLs
>
>Status 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
>1. INTRODUCTION 1
>2. THE MIME FILE 2
>3. 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
>
>
>1. 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.
>
>
>2. 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/TALKTO
>
>and the default extension is:
>
> .tlk
>
>The 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 at h323.bt.com
>*time=17:00-8:30
>h323:home at 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}.
>
>
>3. 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-param
>
>Telephone 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 at 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 format
>
>The 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 at h323.bt.com
> AliasAddress = pete, AliasAddress type = h323id,
> destCallSignalAddress = h323.bt.com.
>
>h323://pete at h323.bt.com
> Same as above
>
>h323:646436 at 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 at 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 at 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 at 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-5678
>
>or:
>
> h324:/isdn/+1-515-234-5679&+1-515-234-5680
>
>
>3.4. H.320 URL
>
>The format of the H.320 URL is:
>
> h320url = "h320" ":" phone-address
>
>The network type is always "isdn". An example is:
>
> h320:/isdn/+1-515-234-5679&+1-515-234-5680
>
>
>3.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: ???????
>
>
>4. 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 at vocaltec.com
>
>E-mail can be sent to the list at the following address:
>
> h323-url at vocaltec.com
>
>
>5. Security Considerations
>
>Umm...
>
>
>6. Acknowledgements
>
>7. 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 at bt-sys.bt.co.uk
>
>
>=================================
>Pete Cordell
>BT Labs
>E-Mail: pete.cordell at bt-sys.bt.co.uk
>Tel: +44 1473 646436
>Fax: +44 1473 645499
>=================================
>
>
More information about the sg16-avd
mailing list