idnits 2.17.1 draft-wilde-sms-service-04.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 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 14, 2003) is 7653 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) == Unused Reference: 'RFC2156' is defined on line 494, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMS-CHAR' -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft Swiss Federal Institute of 4 Expires: November 12, 2003 Technology 5 May 14, 2003 7 Registration of GSTN SMS Service Qualifier 8 draft-wilde-sms-service-04 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 12, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This memo describes the registration of the Short Message Service 39 (SMS) as a registered IANA service selector for Global Switched 40 Telephone Network (GSTN) numbers. SMS is not available for all GSTN 41 subscribers, but it has proven very popular with users of the Global 42 System for Mobile Communications (GSM), and has also been adapted to 43 other telephone network technologies such as the Integrated Services 44 Digital Network (ISDN). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 What is GSM? . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2 What is SMS? . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.2.1 SMS content . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2.2 SMS infrastructure . . . . . . . . . . . . . . . . . . . . . 4 53 1.2.3 SMS Telematic Interworking . . . . . . . . . . . . . . . . . 5 54 2. IANA registrations . . . . . . . . . . . . . . . . . . . . . 6 55 2.1 IANA registration form for GSTN address service-selector 56 "SMS" . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.2 IANA registration form for GSTN address qualit-type1 58 keyword "SMSC" and value . . . . . . . . . . . . . . . . . . 7 59 2.3 IANA registration form for GSTN address qualit-type1 60 keyword "PID" and value . . . . . . . . . . . . . . . . . . 9 61 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 62 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 4.1 From -00 to -01 . . . . . . . . . . . . . . . . . . . . . . 11 64 4.2 From -01 to -02 . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3 From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 11 66 4.4 From -03 to -04 . . . . . . . . . . . . . . . . . . . . . . 11 67 Normative References . . . . . . . . . . . . . . . . . . . . 12 68 Non-Normative References . . . . . . . . . . . . . . . . . . 12 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . 13 70 A. Where to send Comments . . . . . . . . . . . . . . . . . . . 13 71 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 72 Intellectual Property and Copyright Statements . . . . . . . 14 74 1. Introduction 76 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 77 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 78 "OPTIONAL" in this document are to be interpreted as described in RFC 79 2119 [RFC2119]. 81 1.1 What is GSM? 83 GSM (Global System for Mobile Communications) is a digital mobile 84 phone standard which is used extensively in many parts of the world. 85 First named after its frequency band around 900 MHz, GSM-900 has 86 provided the basis for several other networks utilizing GSM 87 technology, in particular GSM networks operating in the frequency 88 bands around 1800 MHz and 1900 MHz. When referring to "GSM" in this 89 document, we mean any of these GSM-based networks that operate a 90 short message service. 92 1.2 What is SMS? 94 The Short Message Service [SMS] is an integral part of the GSM 95 network technology. It has been very successful and currently is a 96 major source of revenue for many GSM operators. SMS as a service is 97 so successful that other Global Switched Telephone Network (GSTN) 98 technologies have adapted it as well, in particular the Integrated 99 Services Digital Network (ISDN). Because of this development, this 100 memo uses the term "SMS client" to refer to user agents who are able 101 to send and/or receive SMS messages. 103 1.2.1 SMS content 105 GSM SMS messages are alphanumeric paging messages that can be sent to 106 and SMS clients. SMS messages have a maximum length of 160 characters 107 (7-bit characters from the GSM character set [SMS-CHAR]), or 140 108 octets. Other character sets (such as UCS-2 16-bit characters, 109 resulting in 70 character messages) MAY also be supported [SMS-CHAR], 110 but are defined as being OPTIONAL by the SMS specification. 111 Consequently, applications handling SMS messages as part of a chain 112 of character processing applications MUST make sure that character 113 sets are correctly mapped to and from the character set used for SMS 114 messages. 116 While the 160 character variety for SMS messages is by far the most 117 widely used one, there are numerous other content types for SMS 118 messages, such as small bitmaps ("operator logos") and simple formats 119 for musical notes ("ring tones"). However, these formats are 120 proprietary and are not considered in this memo. 122 SMS messages are very limited in length (140 octets), and the first 123 versions of the SMS specification did not specify any standardized 124 methods for concatenating SMS messages. As a consequence, several 125 proprietary methods were invented, but the current SMS specification 126 does specify message concatenation. In order to deal with this 127 situation, SMS clients composing messages SHOULD use the standard 128 concatenation method based on the header in the TP-User Data field as 129 specified in [SMS]. When sending a message to an SMS recipient whose 130 support for concatenated messages is unknown, the SMS client MAY opt 131 to use the backwards-compatible (text-based) concatenation method 132 defined in [SMS]. Proprietary concatenation methods SHOULD NOT be 133 used except in closed systems, where the capabilities of the 134 recipient(s) are always known. 136 1.2.2 SMS infrastructure 138 SMS messages can be transmitted over an SMS client's network 139 interface using the signalling channels of the underlying GSTN 140 infrastructure, so there is no delay for call setup. Alternatively, 141 SMS messages MAY be submitted through other front-ends (for example 142 such as Web services), which makes it possible for SMS clients to run 143 on computers which are not directly connected to a GSTN network 144 supporting SMS. 146 SMS messages sent as with the GSTN SMS service MUST be sent as class 147 1 SMS messages, if the client is able to specify the message class. 149 1.2.2.1 SMS Centers 151 SMS messages are stored by an entity called Short Message Service 152 Center (SMSC), and sent to the recipient when the subscriber connects 153 to the network. The number of a cooperative SMSC must be known to the 154 SMS sender (ie, the entity submitting the SMS message to a GSTN 155 infrastructure) when sending the message (usually, the SMSC's number 156 is configured in the SMS client and specific for the network operator 157 to which the sender has subscribed). In most situations, the SMSC 158 number is part of the sending SMS client's configuration. However, in 159 some special cases (such as when the SMS recipient only accepts 160 messages from a certain SMSC), it may be necessary to send the SMS 161 message over a specific SMSC. 163 Short messages can be mobile terminated (MT) or mobile originated 164 (MO). MT messages are the ones that arrive at SMS clients; MO 165 messages are sent by SMS clients. Networks may support either, both, 166 or none of these. For the purpose of this memo, it is important that 167 the sending SMS client is allowed to submit MO messages, and that the 168 receiver is allowed to receive MT messages. 170 The exact setup of message submission and delivery is not subject of 171 this memo, it may incorporate additional hops in addition to the pure 172 SMS transport. For example, the sending SMS client may use a Web 173 service to submit the SMS message, and the receiving SMS client may 174 be set up to forward the SMS to an email account. For the purpose of 175 this memo, it is important that the receiver can be addressed by a 176 GSTN number, and that the sender can submit an SMS message using this 177 number. 179 1.2.3 SMS Telematic Interworking 181 While in most cases SMS messages are exchanged between SMS clients, 182 the SMS specification also includes provisions for so-called 183 "Telematic Interworking". In this scenario, the SMS message specifies 184 a Protocol Identifier, which identifies the service to which the SMS 185 message has to be submitted. In effect, this implements a gateway 186 functionality in the SMSC. 188 Telematic Interworking supports a number of services from Fax through 189 Telex and Internet Email up to voice telephone, where the gateway is 190 expected to make a text-to-speech transformation. The set of possible 191 services is defined by the SMS specification [SMS], but network 192 operators are not required to support any of these services. SMS 193 clients SHOULD implement support for Telematic Interworking, which 194 among other things means that users must be able to set the Protocol 195 Identifier field of generated SMS messages. If clients support 196 Telematic Interworking, they MUST indicate to the user the changed 197 semantics of the receiver number (eg, if Fax is selected, the 198 receiver will be contacted via Fax rather than SMS). 200 In the following list the telematic devices (ie, the services that 201 can be addressed using the Telematic Interworking mechanism) defined 202 by the SMS specification are described. The abbreviations are not 203 taken from the SMS specification, but are introduced by this memo for 204 identifying the device type using an SMS service qualifier keyword. 206 "IMPL": In this case the device type is implicitly defined, either 207 because the SMS Center knows it, or because it can be concluded on 208 the basis of the address. 210 "TELEX": Telex device 212 "G3FAX": Group 3 telefax device 214 "G4FAX": Group 4 telefax device 215 "VOICE": Voice telephone (this requires conversion to speech, but 216 there is no mechanism to specify a language) 218 "ERMES": ERMES (European Radio Messaging System) 220 "NATPAG": National paging system (this does not specify a specific 221 paging systems but implies that the SMS center knows about a 222 particular national paging system) 224 "VIDEOTEX": Videotex 226 teletex: Teletex, either with an unspecified carrier or using PSPDN, 227 CSPDN, PSTN, or ISDN as carrier 229 "UCI": UCI (Universal Computer Interface) 231 reserved: 7 combinations are reserved which do not have a specified 232 meaning 234 "MH": Some message handling facility known to the SMS center (not 235 further specified) 237 x400: X.400-based message handling system 239 The SMS specification fails to specify how X.400 OR addresses are 240 actually embedded into SMS messages, so even though there is a 241 Protocol Identifier for X.400, it is impossible to encode the 242 recipient(s) of a message. 244 email: Internet electronic mail 246 The recipient(s) of SMS messages gatewayed to Internet electronic 247 mail are specified in the message's user data in a way defined by 248 the SMS specification. 250 specific: 7 combinations are defined to have a meaning specific to 251 each SMS center, their usage is based on mutual agreement between 252 SMS clients and the SMS center. 254 It is important to notice that some of the above devices require 255 additional information to be specified (in particular, the "Internet 256 electronic mail" format). The SMS specification defines the methods 257 how this has to be done (effectively by embedding the email 258 information into the SMS message's text). 260 2. IANA registrations 262 Based on the requirements defined in RFC 3191 [RFC3191], the IANA 263 registration forms for the "SMS" service-selector, and "SMSC" and 264 "PID" qualif-type1 elements are defined here. Syntax definitions are 265 given using the Augmented BNF for Syntax Specifications [RFC2234]. 267 2.1 IANA registration form for GSTN address service-selector "SMS" 269 To: IANA@iana.org 270 Subject: Registration of new values for the GSTN address 271 service-selector specifier "SMS" 273 service-selector name: SMS 275 Description of Use: SMS - specify that the GSTN address refers to a 276 GSTN subscriber who is capable of receiving messages using the GSM 277 Short Message Service (SMS). However, if a "PID" qualif-type1 278 element is present for this service selector, then the GSTN 279 address must be interpreted according to the rules for the "PID" 280 qualif-type1 element's value (this may also mean that the GSTN 281 address has to be ignored). 283 For a complete description refer to RFC 3191 and 284 draft-wilde-sms-service-04. 286 Security Considerations: See the Security Consideration section of 287 draft-wilde-sms-service-04. 289 Person & email address to contact for further information: 291 Erik Wilde 292 Swiss Federal Institute of Technology 293 ETH-Zentrum 294 8092 Zurich 295 Switzerland 296 tel:+41-1-6325132 297 fax:+41-1-6321035 298 mailto:ietf@dret.net 300 2.2 IANA registration form for GSTN address qualit-type1 keyword "SMSC" 301 and value 303 To: IANA@iana.org 304 Subject: Registration of new values for the GSTN address 305 qualif-type1 element "SMSC" 307 qualif-type1 "keyword" name: SMSC 309 qualif-type1 "value" ABNF definition: The ABNF definition for the 310 value of the SMSC keyword is taken from draft-allocchio-gstn-05 312 sub-addr = gstn-phone 313 gstn-phone = ( global-phone / local-phone ) 314 global-phone = "+" 1*( DIGIT / written-sep ) 315 local-phone = [ exit-code ] dial-number / exit-code [ dial-number ] 316 exit-code = phone-string 317 dial-number = phone-string 318 phone-string = 1*( DTMF / pause / tonewait / written-sep ) 319 DTMF = ( DIGIT / "#" / "*" / "A" / "B" / "C" / "D" ) 320 pause = "p" 321 tonewait = "w" 322 written-sep = ( "-" / "." ) 324 Description of Use: SMSC - In some situations, it may be necessary to 325 guide the sender of an SMS message to send the message via a 326 certain Short Message Service Center (SMSC). If the SMSC 327 qualif-type1 element is present, an SMS client SHOULD try to send 328 the message first using the specified SMSC. If that fails, the SMS 329 client MAY try another SMSC (such as the default SMSC for that 330 client). 332 Further description is available in draft-wilde-sms-service-04 334 Use Restriction: The use of the "SMSC" qualif-type1 element is 335 restricted to the "SMS" service-selector, it has no meaning 336 outside the SMS service defined by the "SMS" service-selector. 338 Security Considerations: See the Security Consideration section of 339 draft-wilde-sms-service-04. 341 Person & email address to contact for further information: 343 Erik Wilde 344 Swiss Federal Institute of Technology 345 ETH-Zentrum 346 8092 Zurich 347 Switzerland 348 tel:+41-1-6325132 349 fax:+41-1-6321035 350 mailto:ietf@dret.net 352 2.3 IANA registration form for GSTN address qualit-type1 keyword "PID" 353 and value 355 To: IANA@iana.org 356 Subject: Registration of new values for the GSTN address 357 qualif-type1 element "PID" 359 qualif-type1 "keyword" name: PID 361 qualif-type1 "value" ABNF definition: The ABNF syntax definition of 362 the PID qualifier is as follows: 364 sub-addr = "IMPL" / "TELEX" / "G3FAX" / "G4FAX" / "VOICE" 365 / "ERMES" / "NATPAG" / "VIDEOTEX" / teletex / "UCI" 366 / reserved / "MH" / "X400" / email / specific 367 teletex = "TELETEX-" 368 ( "UNSPEC" / "PSPDN" / "CSPDN" / "PSTN" / "ISDN" ) 369 email = "SMTP:" address 370 reserved = "RES" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 371 specific = "SPEC" ( "1" / "2" / "3" / "4" / "5" / "6" / "7" ) 373 The "x400" definition is functionally incomplete (because there is 374 no way how the actual OR address can be specified), but provided 375 here for completeness. 377 The "address" definition is taken from RFC 2822 [RFC2822] and 378 specifies an address that may either be an individual mailbox, or 379 a group of mailboxes. 381 Description of Use: PID - The protocol identifier is used to specify 382 SMS Telematic Interworking by selecting a specific protocol to use 383 for delivery to the recipient. 385 Further description is available in draft-wilde-sms-service-04 387 Use Restriction: The use of the "PID" qualif-type1 element is 388 restricted to the "SMS" service-selector, it has no meaning 389 outside the SMS service defined by the "SMS" service-selector. 391 Security Considerations: See the Security Consideration section of 392 draft-wilde-sms-service-04. 394 Person & email address to contact for further information: 396 Erik Wilde 397 Swiss Federal Institute of Technology 398 ETH-Zentrum 399 8092 Zurich 400 Switzerland 401 tel:+41-1-6325132 402 fax:+41-1-6321035 403 mailto:ietf@dret.net 405 3. Security Considerations 407 SMS messages are transported without any provisions for privacy or 408 integrity, so SMS users should be aware of these inherent security 409 problems of SMS messages. Unlike electronic mail, where additional 410 mechanisms exist to layer security features on top of the 411 infrastructure, there currently is no such framework for SMS 412 messages. 414 SMS messages very often are delivered almost instantaneously (if the 415 receiving SMS client is on line), but there is no guarantee for when 416 SMS messages will be delivered. In particular, SMS messages between 417 different network operators sometimes take a long time to be 418 delivered (hours or even days) or are not delivered at all, so 419 applications SHOULD NOT make any assumptions about the reliability 420 and performance of SMS message transmission. 422 In most networks, sending SMS messages is not a free service. 423 Therefore, SMS clients MUST make sure that any action that incurs 424 costs is acknowledged by the end user, unless explicitly instructed 425 otherwise by the end user. If an SMS client has different ways of 426 submitting an SMS message (such as a Web service and a phone line), 427 then the end user MUST have a way to control which way is chosen. 429 SMS clients often are limited devices (typically mobile phones), and 430 the sending SMS client SHOULD NOT make any assumptions about the 431 receiving SMS client supporting any non-standard services, such as 432 proprietary message concatenation or proprietary content types. 433 However, if the sending SMS client has prior knowledge about the 434 receiving SMS client, then he MAY use this knowledge to compose 435 non-standard SMS messages. 437 There are certain special SMS messages defined in [SMS] that can be 438 used, for example, to turn on indicators on the phone display, or to 439 send data to certain communication ports (comparable to UDP ports) on 440 the device. Certain proprietary systems (for example, the Wireless 441 Application Protocol [WAP])define configuration messages that may be 442 used to reconfigure the devices remotely. Any SMS client SHOULD make 443 sure that malicious use of such messages is not possible, for example 444 by filtering out certain SMS User Data headers. Gateways that accept 445 SMS messages e.g. in e-mail messages or web forms and pass them on to 446 an SMSC SHOULD implement this kind of 'firewalling' approach as well. 448 Because the narrow bandwidth of the SMS communications channel, there 449 should also be checks in place for excessively long concatenated 450 messages. As an example, it may take two minutes to transfer thirty 451 concatenated text messages. 453 Unchecked input from a user MUST NOT be used to populate any other 454 fields in a Short Message other than the User Data field (not 455 including the User Data Header field). All other parts, including the 456 User Data Header, of the Short Message should be generated by trusted 457 means. 459 4. Change Log 461 4.1 From -00 to -01 463 o Added a number of new security considerations. 465 o Added the "PID" qualif-type1 keyword and the section about "SMS 466 Telematic Interworking" Section 1.2.3. 468 4.2 From -01 to -02 470 o Removed address specification for X.400 SMS from ABNF 471 (surprisingly not part of the SMS spec). 473 o Added some explanatory text about character set mapping for SMS 474 messages. 476 o Added text requiring the use of message class 1 for sending SMS 477 messages. 479 4.3 From -02 to -03 481 o Changed ordering of "change Log" section (descending to 482 ascending). 484 o Fixed some spelling erros. 486 4.4 From -03 to -04 487 o Updated reference to draft-allocchio-gstn (to revision -05) 489 Normative References 491 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 492 Requirement Levels", RFC 2119, March 1997. 494 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 495 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 496 1998. 498 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 499 Specifications: ABNF", RFC 2234, November 1997. 501 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 502 2001. 504 [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet 505 Mail", RFC 3191, October 2001. 507 [SMS] European Telecommunications Standards Institute, "ETSI TS 508 100 901 (GSM 03.40 version 7.3.0 Release 1998): Digital 509 Cellular Telecommunications System (Phase 2+); Technical 510 realization of the Short Message Service (SMS); 511 Point-to-Point (PP)", November 1999, . 514 [SMS-CHAR] 515 European Telecommunications Standards Institute, "ETSI TS 516 100 901 (GSM 03.38 version 7.2.0 Release 1998): Digital 517 Cellular Telecommunications System (Phase 2+); Alphabets 518 and language-specific information", July 1999, . 521 [draft-allocchio-gstn-05] 522 Allocchio, C., "Text string notation for Dial Sequences 523 and GSTN / E.164 addresses", draft-allocchio-gstn-05 (work 524 in progress), April 2003. 526 [draft-wilde-sms-service-04] 527 Wilde, E., "Registration of GSTN SMS Service Qualifier", 528 draft-wilde-sms-service-04 (work in progress), May 2003. 530 Non-Normative References 532 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 533 June 1999. 535 [WAP] WAP Forum, "Wireless Application Protocol - Architecture 536 Specification (WAP-210-WAPArch-20010712)", July 2001. 538 Author's Address 540 Erik Wilde 541 Swiss Federal Institute of Technology 542 ETH-Zentrum 543 8092 Zurich 544 Switzerland 546 Phone: +41-1-6325132 547 EMail: ietf@dret.net 548 URI: http://dret.net/netdret/ 550 Appendix A. Where to send Comments 552 Please send all comments and questions concerning this document to 553 Erik Wilde. 555 Appendix B. Acknowledgements 557 This document has been prepared using the IETF document DTD described 558 in RFC 2629 [RFC2629]. 560 Thanks to Claudio Allocchio and Antti Vaha-Sipila for their comments. 562 Intellectual Property Statement 564 The IETF takes no position regarding the validity or scope of any 565 intellectual property or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; neither does it represent that it 569 has made any effort to identify any such rights. Information on the 570 IETF's procedures with respect to rights in standards-track and 571 standards-related documentation can be found in BCP-11. Copies of 572 claims of rights made available for publication and any assurances of 573 licenses to be made available, or the result of an attempt made to 574 obtain a general license or permission for the use of such 575 proprietary rights by implementors or users of this specification can 576 be obtained from the IETF Secretariat. 578 The IETF invites any interested party to bring to its attention any 579 copyrights, patents or patent applications, or other proprietary 580 rights which may cover technology that may be required to practice 581 this standard. Please address the information to the IETF Executive 582 Director. 584 Full Copyright Statement 586 Copyright (C) The Internet Society (2003). All Rights Reserved. 588 This document and translations of it may be copied and furnished to 589 others, and derivative works that comment on or otherwise explain it 590 or assist in its implementation may be prepared, copied, published 591 and distributed, in whole or in part, without restriction of any 592 kind, provided that the above copyright notice and this paragraph are 593 included on all such copies and derivative works. However, this 594 document itself may not be modified in any way, such as by removing 595 the copyright notice or references to the Internet Society or other 596 Internet organizations, except as needed for the purpose of 597 developing Internet standards in which case the procedures for 598 copyrights defined in the Internet Standards process must be 599 followed, or as required to translate it into languages other than 600 English. 602 The limited permissions granted above are perpetual and will not be 603 revoked by the Internet Society or its successors or assignees. 605 This document and the information contained herein is provided on an 606 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 607 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 608 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 609 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 610 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 612 Acknowledgement 614 Funding for the RFC Editor function is currently provided by the 615 Internet Society.