idnits 2.17.1 draft-brandner-enum-categorical-enumservices-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 95 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 123: '...s the registrant SHOULD include such a...' RFC 2119 keyword, line 329: '...ommunication; it SHOULD be displayed t...' RFC 2119 keyword, line 361: '... querying client SHOULD be informed th...' RFC 2119 keyword, line 364: '...end user SHOULD be able to choose....' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 536 looks like a reference -- Missing reference section? '1' on line 532 looks like a reference -- Missing reference section? '4' on line 545 looks like a reference -- Missing reference section? '6' on line 552 looks like a reference -- Missing reference section? '3' on line 541 looks like a reference -- Missing reference section? '7' on line 556 looks like a reference -- Missing reference section? '5' on line 549 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ENUM Working Group R.Brandner 2 Internet-Draft Siemens 3 L. Conroy 4 Siemens 5 R. Stastny 6 OeFEG 7 Expires: December, 2002 June 21st, 2002 9 "Categorical enumservices" 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 37 This document defines the set of enumservices describing "high level" 38 communications categories. These are used as elements within the services 39 field of NAPTR resource records within ENUM domain space. Each category 40 identifies a kind of communications service in which an end user might 41 want to engage using the associated resource. It includes the expected 42 "low level" service that comes under each category, together with a list 43 of the URI schemes that are appropriate for use with each categorical 44 enumservice. 46 1. Introduction 47 Enumservices can be classified in a number of different ways. For a 48 summary of the discussion on options available, see [2]. In addition to 49 the scheme of the URI associated with a NAPTR and the DDDS application 50 identifier ("E2U", in the case of ENUM [1]), there are two main ways of 51 indicating the services supported by the identified resource. 52 These are "low level" or specific services, of which there could be a 53 large number, or higher level categories. This document focusses on the 54 latter, and shows how the existing low level services may be mapped to 55 the higher level categorical enumservices. 57 Low level enumservices define the specific service offered via the 58 associated resource. These are much "closer" to the URI scheme, and 59 indicate the way in which a communication is to be carried out. 61 High level (or categorical) enumservices are intended to reflect the kind 62 of communication in which an end user wants to engage. The goal is to 63 provide a small list of the kinds of communication appropriate rather than 64 the protocol (or implementation) used to execute that communication; they 65 are intended to reflect the "end user's view" of what they want to 66 do, rather than the protocol used to effect that service. 68 1.1. About this document 69 The following sections each describes a category of communication in which 70 an end user may want to engage, and might be passed from the end user 71 interface to the DDDS Application, where it could be used to sieve a 72 NAPTR resource set returned for a particular zone within the ENUM domain 73 space. The goal here is to use this passed list as a filter, rejecting 74 NAPTRs that do not have matching indications in their service field. 76 In each of the sections, the categorical service is described, along with 77 any expected client behaviour, the "low level" services that fall into 78 this category (and so should be matched against the "interesting 79 categorical enumservices"), the URI-schemes that can be associated with 80 the category and any features that they have when used in this way. 82 2. 'talk' categorical enumservice 83 This enumservice indicates that the associated resource can be used for 84 interactive (media stream exchange) calls; it can be used to "talk" to the 85 owner. 87 2.1. 'talk' Expected client behaviour 88 The end user, having selected the talk category as being of interest, will 89 expect their client agent to filter the NAPTRs to those that include 90 either this categorical service or the specific services that it implies. 91 Given that this category is concerned with interactive calls, the querying 92 clients agent should present the options available and supported locally 93 to the end user. This is particularly important for calls that are 94 delivered via a local PSTN connection, as there may well be a cost 95 involved. 97 2.2. 'talk' Implied "low level" services 98 This sub-section describes the low level services that can be classified 99 under this category. Proposals so far have been similar to those included 100 in the 'tel-svc' draft [4], and, for the 'talk' related services, include: 101 - voice 102 - video 104 2.3. 'talk' Associated URI schemes 105 This sub-section describes the URI-schemes for which this category would 106 be appropriate, together with a description of any special issues with 107 each URI scheme used with this category. Note that, although it is 108 possible that VPIM voice messages or video clips could be sent, this is 109 NOT the meaning of the 'talk' category. Thus the URI schemes appropriate 110 for this enumservice category include only those usable to exchange 111 interactive media. 113 2.3.1. talk with "sip:" URI 114 This combination implies that the associated URI may be used to initiate 115 interactive telephony calls to the destination using SIP [6]. Note that 116 SIP has its own negotiation method within the protocol, so that the client 117 MAY be offered another kind of communication session after negotiation. 119 However, this combination gives more information to the querying user than 120 would be the case for the 'srs' enumservice (see section 6.3.1). 121 The implication of the NAPTR with the 'talk' and 'sip' combination is 122 that, if selected, the querying user can engage in an interactive call; 123 thus the registrant SHOULD include such an entry only for those cases 124 where this is possible. 126 2.3.2. talk with "tel:" URI 127 The talk category is one of the two main uses for the "tel:" URI [3]. In 128 this case, the querying client might use this to trigger a voice call via 129 local "dialer" software that controls a PSTN interface (such as a software 130 controlled telephone). If the client has no support for local PSTN 131 connection, then it may submit the "tel:" URI to a local SIP user agent, 132 if the user has a relationship with an external gateway provider that can 133 support "tel:" URIs as destination end points. However, a "tel:" URI is 134 intended for use where the destination party is connected via the PSTN or 135 a network that uses E.164 numbers natively, and by preference the client 136 should attempt to make a PSTN connection if possible. 138 Note that the "tel:" URI may include a svc parameter, specifying the low 139 level services this resource supports. This category implies voice or 140 video services may be used; if one is specified then this may define which 141 service can be used. If there is no such parameter or it includes both 142 video and voice as supported, then the client is able to choose. 144 However, it is recommended that voice be considered the default service 145 and the one to be attempted first, in lack of further information 146 2.3.3. talk with "h323:" URI 147 In principle, interactive calls could be made using the H.323 set of 148 protocols. Within the ENUM system, this requires a URI-scheme to be 149 defined for this protocol set, but once this is done, the talk category 150 may be used with such an "h323:" URI. 152 2.3.4. talk with "enum:" URI 153 The "enum:" URI scheme [7] is intended to indicate the E.164 number that 154 should be used in a re-submission to the ENUM system. In this combination, 155 the interpretation should be that this URI may be used to find further 156 information from the ENUM system by re-submission for clients that are 157 interested in the 'talk' enumservice category only. 159 3. 'msg' categorical enumservice 160 The msg enumservice is intended to indicate that the associated resource 161 is capable of receiving a discrete (non-session related) message or 162 document. This category may be selected by a querying client if they want 163 to deliver a message (such as a Fax) to a correspondent. 165 3.1. 'msg' Expected Client Behaviour 166 Where a querying end user is interested in the 'msg' communication 167 category, it is expected that they will select a NAPTR that is so 168 identified and will generate the URI from this. Once this URI is 169 available, the client would be expected to send a message using the 170 protocol indicated by the URI-scheme. 172 3.2. 'msg' Implied "low level" services 173 The msg category includes a number of specific services. These are: 174 - Fax 175 The Fax service will be associated with a "tel:" URI. As negotiation 176 of particular fax classes (G2, G3, G4) is done within the Fax 177 protocol itself, there is no specification for this needed within the 178 ENUM system. This is considered the default service within this 179 category when used with a "tel:" URI, so if the URI does not include 180 a 'svc' parameter then this may be assumed from the category and URI 181 scheme. 182 - SMS or MMS 183 These services will be associated with a "tel:" URI, and the 184 particular service may be identified within the URI using a 'svc' 185 parameter. If there is no such indication, then an attempt should not 186 be made to use these services (i.e. an SMS or MMS message should not 187 be sent). 188 - email 189 This category, when used with a "mailto:" URI, indicates the email 190 service is supported at this resource. An email may be sent using the 191 associated "mailto:" URI. See [5] for more details on this scheme. 192 - IM 193 Where this is used to send a message rather than initiate a session 194 during which Instant Messages can be exchanged (for that, see section 195 5 of this document). 197 3.3. 'msg' Associated URI schemes 199 3.3.1. msg with "sip:" URI 200 Whilst in the general case one would expect a "sip:" URI to be associated 201 with the 'srs' category (see section 6 for details), it is possible for a 202 registrant to decide to have a separate "sip:" URI specifically as a 203 destination for Instant Messages (or for email). Thus, this categorical 204 enumservice may be associated with a "sip:" URI - if so, then this "sip:" 205 URI should not be used for categories not listed within the services 206 field. For example, if a NAPTR includes the 'msg' category and no others, 207 then this NAPTR should be used only for communications that involve 208 sending a message to that resource; not for other sessions such as those 209 associated with 'chat' or 'talk' categories. 211 Although Instant Messages or emails might be sent without using a "sip:" 212 URI, there is a benefit to doing this; the sender may be authenticated 213 using the standard SIP techniques prior to returning the actual 214 destination contact address, so "hiding" that contact address to 215 non-authenticated would-be correspondents. This should be considered, as 216 the ENUM domain space may be a good source of "junk mail" targets. 218 3.3.2. msg with "tel:" URI 219 There are two main ways in which a telephone number can be used to send a 220 message to a destination. These are to send a telefax to a device 221 contactable via this telephone number, and to send a short message to an 222 appropriate device. 224 Although Short Message Service was designed for use with mobile 225 telephones, there is a move to provide SMS service to landline telephones 226 as well, either via a dial-out service node (for generating an SMS message 227 from a landline telephone), or via a Universal Message service (for 228 reception and storage of SMS messages, and transcoding to voice on 229 demand). For this reason, it may be possible for two end users, both of 230 whom have landline telephones, to send and receive SMS messages; it should 231 NOT be assumed that this is only possible from mobile telephones. 233 Note that the "tel:" URI may contain a 'svc' parameter. This is used to 234 indicate the specific services supported via this resource. If there is no 235 such parameter, but this NAPTR indicates the 'msg' category, then the 236 "tel:" URI may be assumed to support Fax service. 237 Only if the SMS or MMS service is indicated explicitly within the "tel:" 238 URI should such a message be sent to that destination. 240 3.3.3. msg with "mailto:" URI 241 This category is appropriate to indicate that email messages may be 242 sent to the resource identified in the associated URI. In this case the 243 "mailto:" URI is likely to be used (but a "sip:" URI may be chosen 244 instead, particularly if the registrant wants to authenticate the sender 245 using the SIP infrastructure). 247 Existence of a "mailto:" URI within the globally-accessible ENUM 248 infrastructure may well lead to reception of unwanted "junk email", as the 249 ENUM infrastructure is trawled for potential target email addresses. 250 Whilst this is not an issue with the 'msg' category itself, it should be 251 considered by registrants when populating their domains. 253 3.3.4. msg with "enum:" URI 254 The "enum:" URI scheme is intended to indicate the E.164 number that 255 should be used in a re-submission to the ENUM system. The client should 256 interpret this combination and process the URI only if it matches a 257 "client interest" in sending a message. 259 4. 'info' categorical enumservice 260 The info enumservice indicates that the associated resource can act as a 261 source for information. It acts as the "opposite" of the msg enumservice, 262 in that this indicates a source for data whilst that indicates a sink for 263 data. 265 4.1. 'info' Expected Client Behaviour 266 The 'info' enumservice is used by the registrant to indicate to potential 267 correspondents a source of information. The implication for a client is 268 that the registrant will allow any data indicated by the URI to be passed 269 to the client. 271 Note that, particularly in the case of use with the "tel:" URI, it is 272 important to display the destination URL to the querying end user before 273 acting on it. Telephone information services are often charged at a 274 higher rate from other calls, and so the end user should have the chance 275 to confirm the action. 277 Also, an entry of this kind states that information is available from this 278 URI. It does not guarantee access to everyone. The client may be called on 279 to authenticate itself before access is granted. 281 4.2. 'info' Implied "low level" services 282 The info enumservice is used for sources of information. The current list 283 of low level services does not seem to fit with this category, so that the 284 URI scheme is the only other identifier that can be used to help select 285 between a set of NAPTRs. 287 4.3. 'info' Associated URI schemes 288 The info enumservice can be used with several URI schemes. The most common 289 is likely to be that with the "http:" URI-scheme. 291 4.3.1. info with "tel:" URI 292 This combination may seem strange at first, but might be used where a 293 recorded announcement or "information line" can be reached by dialling a 294 particular telephone number. This is not an interactive call in that the 295 recording is being played to the client rather than the client talking 296 with a correspondent. 298 >From the perspective of client software, it seems likely that this 299 combination will be treated very similarly to a normal 'talk' enumservice; 300 the difference lies in the user and registrant's intent for this contact 301 and the communication that will result. 303 4.3.2. info with "http:" URI 304 This combination is used where the registrant wants to store a URI to a 305 web site within their domain space. 307 4.3.3. info with "https:" URI 308 This combination indicates that TLS or Secure Socket Layer connections are 309 required to retrieve the information indicated. 311 4.3.4. info with "ftp:" URI 312 This combination indicates that the information is retrieved using FTP. 314 4.3.5. info with "enum:" URI 315 This combination implies that the URI value can be processed in an ENUM 316 re-submission to find more information on communications contacts that fit 317 with the 'info' category. 319 5. 'chat' categorical enumservice 320 This category is used where the registrant is capable of engaging in a 321 text chat session during which Instant Messages can be sent. It differs 322 from the 'msg' category in that this category implies a session-oriented 323 message exchange, whilst 'msg' implies a discrete message can be sent to 324 the resource at this contact address. 326 5.1. 'chat' Expected Client Behaviour 327 This category indicates that session oriented chat exchanges can be made 328 via the associated URI. Presence of a chat/tel combination may suggest 329 that the registrant prefers text communication; it SHOULD be displayed to 330 the querying end user so they can choose how to proceed. 332 5.2. 'chat' Implied "low-level" services 333 At present, the 'chat' category is associated only with one low-level 334 service -IM. It is unclear whether or not text telephony would be expected 335 with the IM service, whilst it is one option for the chat category. 337 5.3. 'chat' Associated URI schemes 338 Initially, this category is likely to be used with two URI schemes; "sip:" 339 and "tel:". There may well be other session oriented text 'chat' protocols 340 developed, and these should be included in future updates of this 341 document. 343 5.3.1. chat with "sip:" URI 344 This combination indicates that, by using this address of record, the 345 client can initiate a session during which Instant Messages can be 346 exchanged. It may be appropriate to include a NAPTR with this combination 347 if the registrant has more than one address of record with different 348 (competing) providers for voice and instant messaging services. 349 SIP has its own mechanisms for negotiating the kind of communications 350 session to be initiated, so one would expect the 'srs' category to be used 351 in many cases; where there are other reasons that the two addresses of 352 record cannot be combined within one SIP service, discrete (category- 353 specific) entries can be used. 355 5.3.2. chat with "tel:" URI 356 This combination indicates that text chat sessions can be initiated over 357 the telephone network to the destination. It is used, for example, to 358 indicate a telephone number to which a text phone (such as a 'Minicom' or 359 Telecommunications Device for the Deaf - TDD) unit is attached. 361 The querying client SHOULD be informed that textphones are available if 362 this combination is available within a NAPTR. It is difficult to determine 363 whether or not text communication should be preferred over voice, and the 364 end user SHOULD be able to choose. 366 Note that there may be a privacy issue; including this data might be an 367 indication that the registrant is hard of hearing, information that may be 368 considered sensitive. 370 6. 'srs' categorical enumservice 371 This category is used for entries that exit the ENUM system and continue 372 communication service selection using external protocols. These external 373 schemes are called "Service Resolution Services" (or SRS). Information on 374 the kind of communication available is not stored within one of these 375 ENUM entries; instead this may be delivered using the inbuilt procedures 376 of the protocol specified by the associated URI scheme. 378 6.1. 'srs' Expected Client Behaviour 379 This category indicates that the associated URI can be used for further 380 negotiation on the available communications options available. Thus the 381 protocol-specific mechanisms are used. It is assumed that, if the querying 382 client can support these protocols, then the standard protocol handler 383 techniques will be used. 385 6.2. 'srs' Implied "low-level" services 386 By definition, a Service Resolution Service does not have a specific or 387 "low level" service; the srs is used to negotiate outside of the ENUM 388 system. This category does not fit with the concept of "low level" 389 services indicated within ENUM. 391 6.3. 'srs' Associated URI schemes 392 Initially, the two main protocols used with this category are SIP and 393 LDAP. For details of the SIP negotiation mechanisms, see [6]. 395 6.3.1. srs with "sip:" URI 396 This combination is likely to be commonly used. It avoids some potential 397 privacy issues with publishing data within the (global) DNS. Full 398 negotiation of session or contact is available within the SIP protocol, 399 including authentication of the querying user. 401 As mentioned in the sections on the 'msg' and 'talk' categories, it may be 402 difficult to use a single entry within an ENUM domain. A registrant may 403 have, for example, two discrete addresses of record for two categories and 404 may choose to not combine these. However, where this is possible, an entry 405 with 'srs' and "sip:" can be used to "off load" the negotiation to the SIP 406 protocol rather than relying on the DDDS application. 408 6.3.2. srs with "ldap:" URI 409 This combination indicates that further information can be gleaned by 410 queries to the LDAP resource indicated by the URI. 412 7. 'all' categorical enumservice 413 This is a special case of enumservice category. It may be used to indicate 414 that the querying user is interested in any kind of communication, and so 415 all NAPTRs should be considered (i.e. no filtering of NAPTRs based on 416 enumservices should be applied by the DDDS application). 418 This special category may also be used by a registrant who whishes to 419 include a NAPTR or NAPTRs but does not want to specify (within the 420 services field) the services for which each of the NAPTRs is valid. In 421 this case, all NAPTRs are valid regardless of any querying client 422 specified list of categories of interest. 424 7.1. 'all' expected client behaviour 425 If a client receives a NAPTR that indicates that it is to be considered 426 for all enumservices, then it is forced to act in a set of default 427 behaviours. These behaviours are defined by the scheme of the associated 428 URI, and are covered in section 7.3. 430 There are two choices in the filtering behaviour of the client. In the 431 first, a 'NAPTR' with an 'all' enumservice is treated first, before NAPTRs 432 with a defined category or specific service set. This may be convenient 433 for use with an "enum:" URI, so that the NAPTR is similar to a registrant 434 using a CNAME to redirect requests to some other domain within ENUM space. 436 The other choice is to attempt to match against the enumservices of 437 interest, and only to treat a NAPTR with an 'all' enumservice if the 438 others are not appropriate. This may be convenient if the querying user is 439 attempting to initiate a communication; they are interested in a 440 particular kind of communication, and might consider the 'any' enumservice 441 as a "less good" match. 443 It seems that both choices are convenient for different URI schemes (the 444 first where an "enum:" URI is used, the second for all others). Thus, it 445 is proposed that the "order of processing" is that a NAPTR with an 'all' 446 enumservice be treated first if and only if the associated URI scheme is 447 "enum:", whilst it is treated last for all other URI-schemes. 449 7.2. 'all' Implied "low level" services 450 By definition, the 'all' category implies that any "low-level" service 451 might work. Which ones are not specified, and the client has to use the 452 URI-scheme to select the appropriate action. 454 7.3. all with Associated URI schemes 455 The 'all' category does not specify a particular enumservice, so the 456 client behaviour will reflect default rules that must, perforce, be based 457 on the associated URI scheme. 459 7.3.1. all with "sip:" URI 460 This indicates that the associated SIP address of record can be used as 461 a contact for all kinds of communications. This combination should be 462 treated as a "fallback" case. NAPTRs with 'sip' and 'talk' or 'msg' or 463 'srs' should be compared to the category in which the querying user is 464 interested, and only if there is no "more appropriate" NAPTR should 465 this be chosen. 467 7.3.2. all with "tel:" URI 468 The default behaviour for a "tel:" URI is to use it to initiate an 469 interactive telephony call to a destination specified with the enclosed 470 phone number. Note that the "tel:" URI may have a svc parameter, and this 471 may indicate the specific services supported at this resource. If so, then 472 the services indicated will specify the services (and kinds of 473 communication) that can be used, and these should be displayed to the end 474 user for their selection (or offered to some caller preference scheme 475 within the client end point). 477 7.3.3. all with "mailto:" URI 478 When used with the all category, this URI has the default meaning that the 479 resource address can be used to send an email. In this case, this NAPTR 480 acts as if it held the 'msg' categorical enumservice. 482 7.3.4. all with "http:"/"https:" URI 483 In this case, the http or https URI has its default meaning, and the 484 client can use this to extract a document (or other information) available 485 at the resource location indicated. This behaviour is the same as if this 486 NAPTR held the 'info' category. 488 7.3.5. all with "ftp:" URI 489 In this case, the "ftp:" URI has the default meaning that a document can 490 be extracted from the resource indicated. In this case, the NAPTR can be 491 treated as if the category were 'info'. 493 7.3.6. all with "ldap:" URI 494 The "ldap:" URI indicates that a query can be made using the associated 495 URI. This can be treated in a similar way to the 'srs' category, in which 496 detailed communications contact information is available using an LDAP 497 query. 499 7.3.7. all with "enum:" URI 500 One use of this category is to "re-direct" requests to another domain 501 within the ENUM space. If the associated URI-scheme is "enum:" then this 502 means that searches for all classes of communication contact information 503 should be re-submitted using the "enum:" URI value. 505 Note that the enum URI may have its own set of enumservice filters (held 506 in the 'es' parameter). This should be combined with the set of 507 'enumservices of interest' passed by the querying client, and the set 508 intersection of these two should be used for subsequent ENUM queries. 510 8. Security issues 511 There are not thought to be any more security issues over and above those 512 described in RFC2916bis. 514 Note that there is a privacy issue in the use of enumservice identifiers. 515 Including category information within the NAPTR makes it accessible to any 516 querying user without authentication, and so exposes data that the 517 registrant may consider sensitive. 519 9. IANA Considerations 520 The categorical enumservices described in this document are enumservices 521 within the meaning of RFC2916bis, and so this document forms a request for 522 registration of these enumservice labels under the ENUM tree, as specified 523 in sections 2.4.2.1 and 3 of RFC2916bis. 525 10. Acknowledgments 526 Many thanks to the correspondents on the ENUM WG mailing list for their 527 assistance and cajoling to refine these categories. Clive Feather pointed 528 out that TDD phones are used for a session oriented text "chat" system. 530 11. Bibliography 532 [1] P. Faltstrom, M. Mealling, "ENUM", 533 draft-ietf-enum-rfc2916bis-0.txt, 534 Work In Progress, February 2002 536 [2] R. Stastny, R. Brandner, L.Conroy, "Analysis of the Usage of ENUM and 537 ENUM Services", 538 draft-stastny-enum-services-analysis-00.txt, 539 Work In Progress, June 2002 541 [3] H. Schulzrinne, A. Vaha-Sipila, "URIs for Telephone Calls", 542 draft-antti-RFC2806bis-04.txt, 543 Work in progress, May 2002 545 [4] R. Brandner, L.Conroy, R. Stastny, "The 'tel:' URI 'svc' parameter", 546 draft-brandner-tel-svc-00.txt, 547 Work in Progress, June 2002 549 [5] P.Hoffmann, L. Masinter, J. Zawinski, "The mailto URL scheme", 550 RFC2368, Internet Engineering Task Force, July 1998 552 [6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, 553 R. Sparks,M. Handley,E. Schooler, "SIP: session initiation 554 protocol", RFC3261, Internet Engineering task Force, June 2002 556 [7] R. Brandner, L.Conroy, R. Stastny, 'The "enum:" URI scheme', 557 draft-brandner-enum-uri-00.txt, June 2002 559 12. Authors' Addresses 561 Rudolf Brandner 562 Siemens ICN 563 Hofmannstrasse 51 564 Munich 565 Germany 567 Msg - 568 Talk - 569 Info - 571 Lawrence Conroy 572 Siemens Roke Manor Research 573 Roke Manor 574 Romsey 575 U.K. 577 Msg - 578 - 579 Talk - 581 Richard Stastny 582 OeFEG 583 Postbox 147 584 1103 Vienna 585 Austria 587 Msg - 588 Talk - 590 Full Copyright Statement 592 Copyright (C) The Internet Society (2000). All Rights Reserved. 594 This document and translations of it may be copied and furnished to 595 others, and derivative works that comment on or otherwise explain it 596 or assist in its implementation may be prepared, copied, published 597 and distributed, in whole or in part, without restriction of any 598 kind, provided that the above copyright notice and this paragraph are 599 included on all such copies and derivative works. However, this 600 document itself may not be modified in any way, such as by removing 601 the copyright notice or references to the Internet Society or other 602 Internet organizations, except as needed for the purpose of 603 developing Internet standards in which case the procedures for 604 copyrights defined in the Internet Standards process must be 605 followed, or as required to translate it into languages other than 606 English. 608 The limited permissions granted above are perpetual and will not be 609 revoked by the Internet Society or its successors or assigns. 611 This document and the information contained herein is provided on an 612 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 613 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 614 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 615 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 616 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.