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