idnits 2.17.1 draft-ietf-crisp-iris-lwz-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 524. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 530. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 546), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 6 has weird spacing: '...for the the I...' -- 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 (January 25, 2005) is 7030 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-03 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Newton 3 Internet-Draft VeriSign, Inc. 4 Expires: July 26, 2005 January 25, 2005 6 A Lightweight UDP Transport for the the Internet Registry 7 Information Service 8 draft-ietf-crisp-iris-lwz-01 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on July 26, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). All Rights Reserved. 39 Abstract 41 This document describes a lightweight UDP transport for the Internet 42 Registry Information Service (IRIS). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 4 48 3. UDP Transport . . . . . . . . . . . . . . . . . . . . . . . . 5 49 3.1 Use of IRIS-LWZ . . . . . . . . . . . . . . . . . . . . . 5 50 3.1.1 IRIS-LWZ Packet Formats . . . . . . . . . . . . . . . 5 51 3.2 Formal XML Syntax . . . . . . . . . . . . . . . . . . . . 9 52 3.3 IRIS Transport Mapping Definitions . . . . . . . . . . . . 10 53 3.3.1 URI Scheme . . . . . . . . . . . . . . . . . . . . . . 10 54 3.3.2 Application Protocol Label . . . . . . . . . . . . . . 11 55 3.4 Registrations . . . . . . . . . . . . . . . . . . . . . . 11 56 3.4.1 URI Scheme Registration . . . . . . . . . . . . . . . 11 57 3.4.2 Well-known UDP Port Registration . . . . . . . . . . . 11 58 3.4.3 S-NAPTR Registration . . . . . . . . . . . . . . . . . 12 59 4. Internationalization Considerations . . . . . . . . . . . . . 13 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 61 5.1 XML Namespace URN Registration . . . . . . . . . . . . . . 14 62 5.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 14 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 64 7. Normative References . . . . . . . . . . . . . . . . . . . . . 15 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 66 Intellectual Property and Copyright Statements . . . . . . . . 17 68 1. Introduction 70 Using S-NAPTR, IRIS has the ability to define the use of multiple 71 transports for different types of registry services, all at the 72 descretion of the server operator. The UDP transport defined in this 73 document is completely modular and may be used by any registry types. 75 2. Document Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC2119 [8]. 81 3. UDP Transport 83 The binding of this UDP transport to IRIS is called IRIS-LWZ (for 84 IRIS Lightweight using Compression). 86 IRIS-LWZ is composed of two parts, a binary payload descriptor and an 87 request/response transaction payload. The request/response 88 transaction payload may be compressed using the DEFLATE algorithm. 90 3.1 Use of IRIS-LWZ 92 3.1.1 IRIS-LWZ Packet Formats 94 The UDP packet format for IRIS-LWZ is as follows: 96 +--------+--------------+----------+--------+------------+---------+ 97 field | source | destination | checksum | UDP | payload | payload | 98 | port | port | | length | descriptor | | 99 +--------+--------------+----------+--------+------------+---------+ 100 octets 2 2 2 2 1..261 0..n 102 Each IRIS-LWZ query and response is contained in a single UDP packet. 104 3.1.1.1 Payload Descriptor 106 The payload descriptor has two different formats, one for a request 107 and one for a response. However, each format shares a common 1 octet 108 payload header described in Section 3.1.1.1.3. 110 3.1.1.1.1 Payload Request Descriptor 112 The payload descriptor for request packets has the following format: 114 +--------+-------------+-------------------+-----------+-----------+ 115 field | header | transaction | maximum response | authority | authority | 116 | | ID | length | length | | 117 +--------+-------------+-------------------+-----------+-----------+ 118 octets 1 2 2 1 0..255 120 These fields have the following meanings: 121 header - as described in Section 3.1.1.1.3. 122 transaction ID - a 16 bit value identifying the transaction. This 123 value will be returned in the payload response descriptor (Section 124 3.1.1.1.2) and can be used by clients to match requests with 125 responses. Clients SHOULD pick the value randomly and SHOULD NOT 126 use sequences of 16 bit values. Clients MUST NOT set all the bits 127 in this value to 1 (i.e. use a value of 0xFFFF). 129 maximum response length - the total length of the UDP packet (i.e. 130 UDP header length + payload descriptor length + XML payload 131 length) that should not be exceeded when responding to this 132 request. If the server cannot provide a response that is equal to 133 or less than this value, then it MUST respond with a size error 134 (Section 3.1.1.1.3.1.2). 135 authority length - the length of the authority field in this 136 payload descriptor. 137 authority - a string of no more and no less octets describing the 138 authority against wich this request is to be executed. See [5] 139 for the definition and description of an authority. 141 3.1.1.1.2 Payload Response Descriptor 143 The payload descriptor for response packets consists of a payload 144 header (Section 3.1.1.1.3) and a transaction ID. 146 +--------+-------------+ 147 field | header | transaction | 148 | | ID | 149 +--------+-------------+ 150 octets 1 2 152 The transaction ID MUST be the value of the transaction ID of the 153 corresponding request. If the corresponding request did not contain 154 a transaction ID, servers MUST use a transaction ID will all bits set 155 to 1 (i.e. use a value of 0xFFFF) and send a descriptor error (see 156 Section 3.1.1.1.3.1.3). 158 3.1.1.1.3 Payload Header 160 Each bit in the 1 byte payload header has the following meaning: 161 bit 7 - version - If 0, the protocol is the version defined in 162 this document. If 1, the rest of the bits in the header and the 163 payload may be interpreted as another version. 164 bit 6 - request/response flag - If 0, this packet is a request 165 (Section 3.1.1.1.1) packet. If 1, this packet is a response 166 (Section 3.1.1.1.2) packet. 167 bits 5 - payload deflated - If 1, the payload is compressed using 168 the DEFLATE algorithm. 169 bit 4 - deflate supported - If 1, the sender of this packet 170 supports compression using the DEFLATE algorithm. When this bit 171 is 0 in a request, the payload of the response MUST NOT be 172 compressed with DEFLATE. 173 bit 3 - reserved - This MUST be 0. 174 bit 2 - reserved - This MUST be 0. 175 bits 1 and 0 - The value of these bits indicate errors (Section 176 3.1.1.1.3.1). 178 3.1.1.1.3.1 Errors 180 Though the payload descriptor header is the same for both request and 181 response packets, errors only have context in responses. When an 182 error is indicated, the payload is not empty but contains information 183 relating to the error. This is described below. 185 The error values in binary are as follows: 186 00 - no error - the payload is a response to the request. 187 01 - version error (see Section 3.1.1.1.3.1.1). 188 10 - size error (see Section 3.1.1.1.3.1.2). 189 11 - other error (see Section 3.1.1.1.3.1.3). 191 3.1.1.1.3.1.1 Version Error 193 This error indicates that either version of the header descriptor or 194 of the payload of the corresponding request is not understood by the 195 receiver. This response MUST have a payload consisting of an XML 196 instance conforming to the formal definition in Section 3.2 with a 197 root element. 199 The element has child elements that describe the 200 relationship between transport bindings, protocol versions, and data 201 models. Each of these child elements has a 'protocolId' attribute 202 identifying the protocol they represent. In the context of IRIS, the 203 protocol identifiers for these elements are as follows: 204 - the value "iris.lwz1" to indicate the 205 protocol specified in this document. 206 - the XML namespace identifier for IRIS. 207 - the XML namespace identifier for IRIS registries. 209 The following is an example of an XML instance describing the version 210 error. 212 213 214 215 216 217 218 219 221 The protocols identified by the element MUST only 222 indicate protocols running on the same port and IP transport as the 223 sender of the error. In other words, while a server operator may 224 also be running IRIS over BEEP, this XML instance is only intended to 225 instrument version negotiation for LWZ. 227 3.1.1.1.3.1.2 Size Error 229 This error indicates that the size of the response exceeded the value 230 of the maximum response length specified in the corresponding 231 request. This response MUST have a payload consisting of an XML 232 instance conforming to the formal definition in Section 3.2 with a 233 root element. A server may indicate one of two 234 response size conditions by specifying the following child elements: 235 - this child element simply indicates that the 236 response size exceeded the maximum response size specified in the 237 corresponding request. 238 - this child element indicates that the response size 239 exceeded the maximum response size specified in the corresponding 240 request and provided the number of octets needed to provide a 241 response. 243 The following is an example of an XML instance describing the size 244 error. 246 247 1211 248 250 3.1.1.1.3.1.3 Other Error 252 This error indicates conditions where descriptive text is to be 253 provided to properly diagnose the error. This response MUST have a 254 payload consisting of an XML instance conforming to the formal 255 definition in Section 3.2 with a root element. This root 256 element may have child elements describing the error, 257 each with a 'language' attribute indicated the language in which the 258 error is described. The element has a 'type' attribute 259 indicating the type of error. The values for this attribute are as 260 follows: 261 'descriptor' - indicates there was an error decoding the 262 descriptor. 263 'payload' - indicates there was an error interpretting the 264 payload. 265 'system' - indicates that the receiver cannot process the request 266 due to a condition not related to this protocol. 267 'authority' - indicates that the intended authority specified in 268 the corresponding request is not served by the receiver. 269 'noDeflationSupport' - indicates that the receiver does not 270 support payloads that have been compressed with DEFLATE. 272 The following is an example of an XML instance describing this type 273 of error. 275 277 unavailable, come back later 278 280 3.2 Formal XML Syntax 282 The following is the XML Schema used to define IRIS-LWZ operations. 283 See the following specifications: [1], [2], [3], [4]. 285 286 291 292 293 A schema for describing errors 294 for use by multiple transports. 295 296 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 323 324 325 326 327 329 330 331 332 333 334 335 336 337 338 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 357 359 3.3 IRIS Transport Mapping Definitions 361 This section lists the definitions required by IRIS [5] for transport 362 mappings. 364 3.3.1 URI Scheme 366 The URI scheme name specific to this transport MUST be "iris.lwz". 368 3.3.2 Application Protocol Label 370 The application protocol label MUST be "iris.lwz". 372 3.4 Registrations 374 3.4.1 URI Scheme Registration 376 URL scheme name: iris.lwz 378 URL scheme syntax: defined in Section 3.3.1 and [5]. 380 Character encoding considerations: as defined in RFC2396 [6]. 382 Intended usage: identifies an IRIS entity made available using 383 compressed XML over UDP 385 Applications using this scheme: defined in IRIS [5]. 387 Interoperability considerations: n/a 389 Security Considerations: defined in Section 6. 391 Relevant Publications: IRIS [5]. 393 Contact Information: Andrew Newton 395 Author/Change controller: the IESG 397 3.4.2 Well-known UDP Port Registration 399 Protocol Number: UDP 401 Message Formats, Types, Opcodes, and Sequences: defined in Section 402 3.1.1 and Section 3.1.1.1. 404 Functions: defined in IRIS [5]. 406 Use of Broadcast/Multicast: none 408 Proposed Name: IRIS over LWZ 410 Short name: iris.lwz 412 Contact Information: Andrew Newton 414 3.4.3 S-NAPTR Registration 416 Application Protocol Label: iris.lwz 418 Intended usage: identifies an IRIS server using compressed XML over 419 UDP 421 Interoperability considerations: n/a 423 Security Considerations: defined in Section 6. 425 Relevant Publications: IRIS [5]. 427 Contact Information: Andrew Newton 429 Author/Change controller: the IESG 431 4. Internationalization Considerations 433 Implementers should be aware of considerations for 434 internationalization in IRIS [5]. 436 5. IANA Considerations 438 5.1 XML Namespace URN Registration 440 This document makes use of a proposed XML namespace and schema 441 registry specified in XML_URN [9]. Accordingly, the following 442 registration information is provided for the IANA: 443 o URN/URI: 444 * urn:ietf:params:xml:ns:iris-trans 445 o Contact: 446 * Andrew Newton 447 o XML: 448 * The XML Schema specified in Section 3.2 450 5.2 S-NAPTR Registration 452 Registrations with the IANA are described in Section 3.4. 454 6. Security Considerations 456 IRIS-LWZ is intended for serving public data; it provides no in-band 457 mechanisms for authentication or encryption. Any application with 458 this need must provide out of band mechanisms to provide it (e.g., 459 IPSec), or use the IRIS protocol with an application transport that 460 provides such capabilities (e.g. BEEP [7]). 462 7 Normative References 464 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 465 1.0", W3C XML, February 1998, 466 . 468 [2] World Wide Web Consortium, "Namespaces in XML", W3C XML 469 Namespaces, January 1999, 470 . 472 [3] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C 473 XML Schema, October 2000, 474 . 476 [4] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C 477 XML Schema, October 2000, 478 . 480 [5] Newton, A. and M. Sanz, "Internet Registry Information Service", 481 RFC 3891, January 2004. 483 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 484 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 486 [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 487 3080, March 2001. 489 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 490 Levels", RFC 2119, BCP 14, March 1997. 492 [9] Mealling, M., "The IETF XML Registry", 493 draft-mealling-iana-xmlns-registry-03 (work in progress), 494 November 2001. 496 Author's Address 498 Andrew L. Newton 499 VeriSign, Inc. 500 21345 Ridgetop Circle 501 Sterling, VA 20166 502 USA 504 Phone: +1 703 948 3382 505 EMail: anewton@verisignlabs.com; andy@hxr.us 506 URI: http://www.verisignlabs.com/ 508 Intellectual Property Statement 510 The IETF takes no position regarding the validity or scope of any 511 Intellectual Property Rights or other rights that might be claimed to 512 pertain to the implementation or use of the technology described in 513 this document or the extent to which any license under such rights 514 might or might not be available; nor does it represent that it has 515 made any independent effort to identify any such rights. Information 516 on the procedures with respect to rights in RFC documents can be 517 found in BCP 78 and BCP 79. 519 Copies of IPR disclosures made to the IETF Secretariat and any 520 assurances of licenses to be made available, or the result of an 521 attempt made to obtain a general license or permission for the use of 522 such proprietary rights by implementers or users of this 523 specification can be obtained from the IETF on-line IPR repository at 524 http://www.ietf.org/ipr. 526 The IETF invites any interested party to bring to its attention any 527 copyrights, patents or patent applications, or other proprietary 528 rights that may cover technology that may be required to implement 529 this standard. Please address the information to the IETF at 530 ietf-ipr@ietf.org. 532 Disclaimer of Validity 534 This document and the information contained herein are provided on an 535 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 536 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 537 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 538 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 539 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 540 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 542 Copyright Statement 544 Copyright (C) The Internet Society (2005). This document is subject 545 to the rights, licenses and restrictions contained in BCP 78, and 546 except as set forth therein, the authors retain all their rights. 548 Acknowledgment 550 Funding for the RFC Editor function is currently provided by the 551 Internet Society.