idnits 2.17.1 draft-cordell-sg16-conv-url-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 495 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 100 instances of lines with control characters in the document. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 222 has weird spacing: '...| param param...' == Line 237 has weird spacing: '...specify that ...' == Line 456 has weird spacing: '...3-param h323-...' == Line 464 has weird spacing: '...0-param t120-...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Dec 16, 1997) is 9629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1738 (ref. '3') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-11) exists of draft-antti-telephony-url-03 -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Cordell 2 draft-cordell-sg16-conv-url-00.txt BT 3 Editor 4 Dec 16, 1997 5 Expires: 21 June 1998 7 Conversational Multimedia URLs 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 {Editor's comments are in braces} 30 Abstract 32 The evolving technologies for real-time conversation over the Internet 33 require URLs to provide user contact information. As there are many 34 protocols (including some that are not Internet based) that can be used 35 for inter-user conversation, this document describes a two stage 36 transaction process for obtaining a URL that can be used to initiate 37 conversation. The first stage involves retrieving a list of protocol 38 specific URLs in a MIME encoded file. The MIME type enables an 39 appropriate application to be launched which will analyse the presented 40 URLs and select the most appropriate one. The second stage involves 41 interpreting the protocol specific URL and initiating the conversation. 42 The protocol specific URLs are encoded in a URL form so that they can be 43 embedded directly into HTML pages. This allows the first stage to be 44 omitted. The document describes the format of the MIME encoded list of 45 URLs, and the format of a number of protocol specific URLs. 47 Contents 49 ABSTRACT 1 50 CONTENTS 1 51 REVISIONS SINCE LAST VERSION 1 52 1. INTRODUCTION 1 53 2. THE MIME FILE 2 54 3. PROTOCOL SPECIFIC URLS 3 55 3.1. COMMON URL ELEMENTS 3 56 3.2. H.323 URL 3 57 3.3. H.324 URL 5 58 3.4. H.320 URL 5 59 3.5. POTS URL 5 60 3.6. T.120 URL 5 61 4. E-MAIL LIST 6 62 5. SECURITY CONSIDERATIONS 6 63 6. ACKNOWLEDGEMENTS 6 64 7. REFERENCES 6 65 APPENDIX 1 - COMPLETE ABNF 6 66 AUTHOR'S ADDRESS 7 68 Revisions Since Last Version 70 * Removed call-id as a parameter 72 1. Introduction 74 Internet technology allows for real-time conversation to take place. It 75 also provides a convenient method of obtaining user location information 76 in the form of URLs. (Note: As used here, the term user can refer to a 77 person, a machine, or any other entity a person or machine may care to 78 have a conversation with.) These can describe Internet conversational 79 protocols, and non-Internet based conversational mechanisms such as 80 POTS. As there are a number of conversational protocols that can be 81 used to contact a user, this document describes a two stage process for 82 initiating conversation, with the first stage being optional. The first 83 stage retrieves a list of protocol specific URLs in a MIME encoded file. 84 This list is analysed and the most appropriate URL is selected. The 85 second stage involves interpreting the protocol specific URL. The 86 protocol specific URLs are in a form that can be directly embedded into 87 HTML pages so that the first stage can be omitted. 89 The scheme presented here is designed to leverage as much as possible of 90 existing infrastructure. As other technologies become common place 91 (such as CMA [1] and vCard [2]) the mechanisms presented here may lapse. 93 The remainder of this document describes the format of the MIME file, 94 and the format of a number of protocol specific URLs. 96 2. The MIME file 98 The first stage in the contact process is to obtain a list of possible 99 contact mechanisms. To enable a single link to be placed in an HTML 100 page, an indirection method is used wherein a link to a MIME encoded 101 file is made. The MIME type of the file is: 103 APPLICATION/TALKTO 105 and the default extension is: 107 .tlk 109 The MIME file should be retrieved using HTTP. Files that contain time 110 dependent protocol specific URLs should ensure that the files are marked 111 as non-cacheable. 113 The MIME encoded file consists of ASCII text and lists a number of 114 protocol specific URLs that can be used to contact a remote user. The 115 section below describes a number of protocol specific URLs, but this 116 should not be considered an exhaustive list. 118 Each protocol specific URL is presented on a separate line with no 119 leading white space. The preferred line break convention is the one 120 used for HTTP (CRLF), but applications must be tolerant to other line 121 break conventions so that files can be readily edited on diverse hosts. 123 Each protocol specific URL may be followed by some white space and a 124 comment. The comment should be in a form that can be presented to a 125 user as part of a manual selection process. By default the comments are 126 ignored. For example: 128 ;My home number 129 ;My bosses number 131 Lines which begin with white-space should be considered as comments and 132 ignored. 133 The order of the URLs should be such that the most preferred URL is 134 presented first, and the least preferred is presented last. When 135 interpreting the file, if a URL is unsupported, or is not understood, it 136 should be skipped. Endpoints are encouraged to take into account the 137 preference order indicated by the file when selecting a URL, but this is 138 not required. Parsing of the file may continue if a contact attempt 139 fails. 141 Note that the file does not contain any other information such as the 142 times when specific URLs are valid. This enables a simple file format 143 that does not have to cope with arbitrary search sequences and the 144 complications of time-zones. Therefore, strictly, the file is only 145 valid at the time it is downloaded and the HTTP cache control attributes 146 should be used to control its validity as required. 148 As with any file downloaded by HTTP, it can be a static file on a server 149 or dynamically generated by an executable. The data for the latter may 150 be uploaded by schemes such as the VoIP's CMA protocol[1]. 152 Validation of who is allowed to obtain various types of location 153 information can be done using WWW-Authentication and cookies. This 154 document provides no additions to these HTTP mechanisms. 156 Example URLs for downloading the MIME file are: 158 http://talkto.mycom.com/me.tlk 159 http://talkto.mycom.com/cma.exe?me 161 {For consideration: 162 The above scheme is simple, but not extensible. It may be prudent to 163 define a basic extension scheme to cope with any future problems. The 164 follwing scheme is suggested for consideration. 165 If the line starts with a "+", then this line contains a parameter that 166 is optional to interpret, i.e. parsing of the file can continue even if 167 the parameter is not understood. 168 If the line starts with "*", then the line contains a parameter that 169 must be understood. The rest of the file should only be interpreted if 170 the parameter is understood, but earlier lines can be interpreted even 171 if the paramter is not understood. This definition allows simple parser 172 features and complex parser features to co-exist in the same file. e.g. 173 a file might contain: 175 h323:pete@h323.bt.com 176 *time=17:00-8:30 177 h323:home@h323.bt.com 179 where time is a paramter to be defined in the future. Parsers that 180 don't understand the time parameter could use the first URL, but not the 181 second}. 183 3. Protocol Specific URLs 185 Protocol specific URLs describe contact information for a specific 186 protocol. This section describes a number of these URLs, but this 187 should not be considered an exhaustive list. Other suitable URLs 188 include the IETF's SIP, VoIP's CMA, and Microsoft's CALLTO schemes. 189 Although the main intention of these URLs is to describe conversational 190 protocols, URLs such as CHAT and MAILTO may be appropriate as a last 191 resort. Under certain circumstances RTSP URLs may also be useful. 192 This section starts with a description of some common elements. These 193 are then used in the protocol specific URLs. 195 3.1. Common URL elements 197 This sub-section describes common elements from which the protocol 198 specific URLs are constructed. A number of the elements use definitions 199 from [3]. 201 network = packet-network | switched-network 202 packet-network = "ip" | "tls" | "udp" | "aal5" 203 ; ip = IP connection without TLS 204 ; tls = IP connection made over TLS 205 ; udp = IP connection made over UDP - 206 ; this channel may be made reliable 207 ; using additional means 208 ; aal5 = ATM AAL5 call 209 switched-network = "pots" | "isdn" | "aal1" 210 ; pots = GSTN or ISDN speech/audio call 211 ; isdn = ISDN data call 212 ; aal1 = ATM AAL1 call 213 address = ip-address | phone-address 215 ip-address = hostport ; hostport defined in [3] 217 phone-address = global-phone-number *[ "&" global-phone-number ] 218 ; global-phone-number defined in [4]. 219 ; H.323 endpoints do not support the 220 ; wait for tone pause character 222 param-list = param | param param-list 223 param = ";" h323-param 225 Telephone numbers in phone-address should always be presented in a full 226 international form, including the "+" sign. It is the responsibility of 227 endpoints and/or gatekeepers to convert these to location specific 228 numbers. 230 3.2. H.323 URL 232 {Note: the format of this URL has been structured to have a basic form 233 of h323:pete@h323.bt.com. This is because users are familiar with this 234 format, and it is intuitive what it means. However, this does present 235 problems when e-mail ids which include an @ are included in the URL. 236 One solution is to include the e-mail @ in its escaped form, i.e. %40. 237 Another option is to specify that parsers should be tolerant of 238 duplicate @ signs. Yet another option is to use an alternative 239 character to represent the @ in the basic URL form, i.e. 240 h323:pete/bt.com. This appears less intuitive, and there may be many 241 erroneous URLs generated as the number of /s at the beginning become 242 very significant, such as in h323:/pete.bt.com which should resolve to 243 an IP address only. } 245 There are two H.323 related URLs. The first form initiates a call 246 directly based on the information in the URL. The second initiates a 247 call based on information that is obtained by first issuing an H.323 248 LRQ. 250 For the first form, the scheme is: 252 h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address 253 [h323-param-list] 255 and the second form is: 257 lrqurl = "lrq" "://" ip-address [h323-param-list] 259 where: 261 h323-address = user-part | address | user-part address 262 user-part = user [ ":" type ] "@" 263 user = 1*alphanum ; alphanum defined in [3] 264 type = "e164" | "h323id" | "email" 266 The 'network' part of the URL need only be present if the network is not 267 of type IP (i.e. ip is the default network). 269 If an ip-address is used in the 'address' field, the 'user' and 'type' 270 fields specify the information to be placed in the destinationInfo part 271 of ARQ and destinationAddress part of SETUP. The 'type' field specifies 272 the type of AliasAddress. If the user field starts with a digit, "*" or 273 "#" the default type is "e164", otherwise it is "h323id". 275 If a 'phone-number' is used in the address field any 'user' and 'type' 276 parts are placed in the remoteExtensionAddress part of SETUP, and the 277 phone number is placed in the destinationInfo part of ARQ and 278 destinationAddress part of SETUP. It is the responsibility of the 279 receiving H.323 over ISDN gateway to transfer the remoteExtensionAddress 280 to the destinationInfo part of ARQ and destinationAddress part of SETUP 281 prior to making the onward call. 283 To place an aliasAddress containing an @ sign in the 'user' field, the 284 escaped form of the @ sign must be used, i.e. %40. 286 If the 'address' field is of type ip-address this is placed in the 287 destCallSignalAddress fields of both ARQ and SETUP. 289 The H.323 URL may have a number of parameters associated with it. If an 290 endpoint does not know how to handle a parameter then it shall ignore 291 the entire URL. At the time of writing the valid parameters are: 293 h323-param = cid-param | token-param | l2-param 294 cid-param = "cid" "=" UUID ; UUID is specified in [5] 295 token-param = "token" "=" "0x" 1* hex 296 l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) 297 ; Layer 2 format 299 The cid parameter encodes a UUID that should be placed in the conference 300 ID field of the ARQ and SETUP messages. This field may appear a maximum 301 of 1 time in the URL. 303 If a conference Identifier is specified, then the conferenceGoal should 304 be "join" in the outgoing SETUP message, otherwise it should be 305 "create". 307 The token field represents a hexadecimal representation of an octet 308 sequnce. 0, 1 or more token parameters may be included in a URL. 310 The 'l2' parameter allows for different packetisation schemes to be used 311 over switched network connections. If applicable, the default is PPP. 313 Note that an H.323 URL with a network type of ISDN indicates that H.323 314 is carried over the ISDN using a layer 2 protocol such as PPP (specified 315 by the 'l2' parameter). It does not mean that the H.323 system should 316 locate an H.320 gateway and use this to communicate over the ISDN. The 317 H.320 URL should be used to indicate this. 319 Example H.323 URLs are as follows: 321 h323:pete@h323.bt.com 322 AliasAddress = pete, AliasAddress type = h323id, 323 destCallSignalAddress = h323.bt.com. 325 h323://pete@h323.bt.com 326 Same as above 328 h323:646436@h323.bt.com 329 AliasAddress = 646436, AliasAddress type = e164, 330 destCallSignalAddress = h323.bt.com. 332 h323:pete@ -- This form requires a gatekeeper to determine a 333 destCallSignalAddress 334 AliasAddress = pete, AliasAddress type = h323id, 335 destCallSignalAddress = GK supplied. 337 h323:pete.bt.com 338 destCallSignalAddress = pete.bt.com 340 h323:/tls/pete%40bt.com:email@bt.com;token=0x5435;token=0xcdfe;cid=f81d4f 341 bf-7dec-11d0-a765-00a0c91e6bf6 342 This call should be setup over a secure TLS channel. 343 AliasAddress = pete@bt.com, AliasAddress type = email-ID, 344 destCallSignalAddress = bt.com, Two tokens are supplied. 345 A conference ID is also specified. 347 h323:/pots/+1-515-234-5645 348 H.323 over PPP over GSTN. destCallSignalAddress = an address of an 349 H.323 over POTS gateway. This may be gatekeeper provided. 350 +1-515-234-5645 is placed in destinationInfo part of ARQ and 351 destinationAddress part of SETUP. 353 lrq:pete@h323.bt.com 354 Causes an LRQ to be performed first. 356 3.3. H.324 URL 358 The format of the H.324 URL is: 360 h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address 362 The default switched-network type is "pots". H.324i is denoted by 363 having a switch-network type of "isdn". 364 An example URL is: 366 h324:+1-515-234-5678 368 or: 370 h324:/isdn/+1-515-234-5679&+1-515-234-5680 372 3.4. H.320 URL 374 The format of the H.320 URL is: 376 h320url = "h320" ":" phone-address 378 The network type is always "isdn". An example is: 380 h320:/isdn/+1-515-234-5679&+1-515-234-5680 382 3.5. POTS URL 384 The telephone number scheme for a basic voice call is defined in [4]. 386 3.6. T.120 URL 388 The format of the T.120 URL is: 390 t120url = "t120" ":" [ "/" [ network ] "/" ] address [t120-param-list] 392 The following parameters are valid: ??????? 394 4. E-mail list 396 As many groups are interested in conversational URLs including SG16, 397 VoIP, MMUSIC, PINT, TIPHON, URL-REG etc), a separate e-mail list has 398 been set up. You can subscribe to the list by including the word 399 "subscribe" in the message body text of an e-mail sent to the address: 401 h323-url-request@vocaltec.com 403 E-mail can be sent to the list at the following address: 405 h323-url@vocaltec.com 407 5. Security Considerations 409 Umm... 411 6. Acknowledgements 413 7. References 415 [1] "Service Interoperability Implementation Agreement," IMTC VoIP Forum 416 [2] vCard 417 [3] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 418 Locators (URL)," RFC1738, December 1994. {Editor's note: A new 419 version of RFC1738 is being produced so this reference will have 420 to be changed.} 421 [4] A. Vaha-Sipila, "URLs for Telephony," 422 draft-antti-telephony-url-03.txt, 21 Nov 1997 423 [5] "Call Signalling Protocols and media Stream Packetization for 424 Packet Based Multimedia Communications Systems," 425 ITU-T Recommendation H.225 Version 2, January 1998 427 Appendix 1 - Complete ABNF 429 all-urls = h323url | lrqurl | h324url | h320url | t120url 431 h323url = "h323" ":" [ "/" [ network ] "/" ] h323-address [ 432 h323-param-list ] 433 lrqurl = "lrq" "://" ip-address [ h323-param-list ] 434 h324url = "h324" ":" [ "/" [ switched-network ] "/" ] phone-address 435 h320url = "h320" ":" phone-address 436 t120url = "t120" ":" [ "/" [ network ] "/" ] address [ t120-param-list ] 438 network = packet-network | switched-network 439 packet-network = "ip" | "tls" | "udp" | "aal5" 440 switched-network = "pots" | "isdn" | "aal1" 442 h323-address = user-part | address | user-part address 443 user-part = user [ ":" type ] "@" 444 user = 1*alphanum ; alphanum defined in [3] 445 type = "e164" | "h323id" | "email" 447 address = ip-address | phone-address 449 ip-address = hostport ; hostport defined in [3] 451 phone-address = global-phone-number *[ "&" global-phone-number ] 452 ; global-phone-number defined in [4]. 453 ; H.323 endpoints do not support the 454 ; wait for tone pause character 456 h323-param-list = ";" h323-param | ";" h323-param h323-param-list 458 h323-param = cid-param | token-param | l2-param 459 cid-param = "cid" "=" UUID ; UUID is specified in [5] 460 token-param = "token" "=" "0x" 1* hex 461 l2-param = "l2" "=" ( "PPP" | "MPPP" | "SLIP" ) 462 ; Layer 2 format 464 t120-param-list = ";" t120-param | ";" t120-param t120-param-list 465 t120-param = {???????} 467 Author's Address 469 Pete Cordell 470 BT Labs 471 MLB 4/15 472 Martlesham Heath 473 Ipswich 474 IP5 3RE 475 UK 476 e-mail: pete.cordell@bt-sys.bt.co.uk