idnits 2.17.1 draft-ietf-ipp-collection-02.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2568], [RFC2616], [RFC2569], [IPP-PRO], [IPP-IIG], [RFC2565,RFC2566], [RFC2567]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC2606-compliant FQDNs in the document. ** 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 39: '...ent specifies an OPTIONAL attribute sy...' RFC 2119 keyword, line 67: '... IPP/1.0. A few OPTIONAL operator ope...' RFC 2119 keyword, line 162: '...member attribute MUST be unique, but M...' RFC 2119 keyword, line 163: '... another collection type and/or MAY be...' RFC 2119 keyword, line 171: '...member attribute MUST NOT exceed the l...' (71 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 683 has weird spacing: '...for the end-c...' == Line 938 has weird spacing: '...rotocol comm...' == Line 941 has weird spacing: '...ollecti value...' == Line 949 has weird spacing: '...rd type valu...' == Line 952 has weird spacing: '...l.color media...' == (30 more instances...) -- 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 (March 9, 2000) is 8807 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) == Missing Reference: 'RFC2026' is mentioned on line 25, but not defined == Missing Reference: 'IPP-PRO' is mentioned on line 57, but not defined == Missing Reference: 'IPP-IIG' is mentioned on line 58, but not defined ** Obsolete normative reference: RFC 2565 (Obsoleted by RFC 2910) ** Obsolete normative reference: RFC 2566 (Obsoleted by RFC 2911) ** Downref: Normative reference to an Experimental RFC: RFC 2567 ** Downref: Normative reference to an Experimental RFC: RFC 2568 ** Downref: Normative reference to an Experimental RFC: RFC 2569 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 14 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Roger deBry 2 Utah Valley State College 3 T. Hastings 4 Xerox Corporation 5 R. Herriot 6 Xerox Corporation 7 K. Ocke 8 Xerox Corporation 9 P. Zehler 10 Xerox Corporation 11 March 9, 2000 13 Internet Printing Protocol (IPP): 14 The 'collection' attribute syntax 16 Copyright (C) The Internet Society (2000). All Rights Reserved. 18 Status of this Memo: 20 This document is an Internet-Draft and is in full conformance with all 21 provisions of Section 10 of [RFC2026]. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, and 23 its working groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference material 29 or to cite them other than as "work in progress". 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed as 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document specifies an OPTIONAL attribute syntax called 40 'collection' for use with the Internet Printing Protocol/1.0 41 (IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and 42 subsequent versions. A 'collection' is a container holding one or 43 more named values, which are called "member" attributes. A 44 collection allows data to be grouped like a PostScript dictionary 45 or a Java Map. 47 There are 4 issues in the document. 49 [Expires: September 9, 2000] 51 The full set of IPP documents includes: 53 Design Goals for an Internet Printing Protocol [RFC2567] 54 Rationale for the Structure and Model and Protocol for the Internet 55 Printing Protocol [RFC2568] 56 Internet Printing Protocol/1.1: Model and Semantics (this document) 57 Internet Printing Protocol/1.1: Encoding and Transport [IPP-PRO] 58 Internet Printing Protocol/1.1: Implementer's Guide [IPP-IIG] 59 Mapping between LPD and IPP Protocols [RFC2569] 61 The "Design Goals for an Internet Printing Protocol" document takes a 62 broad look at distributed printing functionality, and it enumerates 63 real-life scenarios that help to clarify the features that need to be 64 included in a printing protocol for the Internet. It identifies 65 requirements for three types of users: end users, operators, and 66 administrators. It calls out a subset of end user requirements that are 67 satisfied in IPP/1.0. A few OPTIONAL operator operations have been 68 added to IPP/1.1. 70 The "Rationale for the Structure and Model and Protocol for the Internet 71 Printing Protocol" document describes IPP from a high level view, 72 defines a roadmap for the various documents that form the suite of IPP 73 specification documents, and gives background and rationale for the IETF 74 working group's major decisions. 76 The "Internet Printing Protocol/1.1: Encoding and Transport" document is 77 a formal mapping of the abstract operations and attributes defined in 78 the model document onto HTTP/1.1 [RFC2616]. It defines the encoding 79 rules for a new Internet MIME media type called "application/ipp". This 80 document also defines the rules for transporting over HTTP a message 81 body whose Content-Type is "application/ipp". This document defines a 82 new scheme named 'ipp' for identifying IPP printers and jobs. 84 The "Internet Printing Protocol/1.1: Implementer's Guide" document gives 85 insight and advice to implementers of IPP clients and IPP objects. It 86 is intended to help them understand IPP/1.1 and some of the 87 considerations that may assist them in the design of their client and/or 88 IPP object implementations. For example, a typical order of processing 89 requests is given, including error checking. Motivation for some of the 90 specification decisions is also included. 92 The "Mapping between LPD and IPP Protocols" document gives some advice 93 to implementers of gateways between IPP and LPD (Line Printer Daemon) 94 implementations. 96 [Expires: September 9, 2000] 97 Table of Contents 99 1 Problem Statement.................................................4 100 2 Solution..........................................................4 101 3 Definition of a Collection Attribute..............................5 102 3.1 Member Attribute Naming Rules..................................5 103 3.2 Remaining rules for a collection attribute definition..........6 104 3.3 Nested Collections.............................................8 105 3.4 Collection Attributes as Operation Attributes..................9 106 3.5 Collections as Job Template Attributes.........................9 107 3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes 108 operations.........................................................10 109 4 New Out-of-band value............................................11 110 4.1 'none'........................................................11 111 5 Unsupported Values...............................................12 112 6 Sample specification.............................................12 113 7 Encoding.........................................................13 114 7.1 encoding of a collection (using solution 1a)..................17 115 7.2 Sample Encoding (using solution 1a)...........................19 116 7.3 1setOf Collection encoding (using solution 1a)................20 117 7.4 Sample 1setOf Collection encoding (using solution 1a).........21 118 8 Legacy issues....................................................23 119 9 IANA Considerations..............................................24 120 10 Internationalization Considerations..............................24 121 11 Security Considerations..........................................24 122 12 References.......................................................24 123 13 Author's Addresses...............................................25 124 14 Appendix A: Full Copyright Statement.............................26 126 [Expires: September 9, 2000] 127 1 Problem Statement 129 The IPP Model and Semantics [ipp-mod] supports most of the common data 130 structures that are available in programming languages. It lacks a 131 mechanism for grouping several attributes of different types. The Java 132 language uses the Map to solve this problem and PostScript has a 133 dictionary. The new mechanism for grouping attributes together must 134 allow for optional members and subsequent extension of the collection. 136 The mechanism must be encoded in a manner consistent with existing 1.0 137 and 1.1 parsing rules (see [ipp-pro]). Current 1.0 and 1.1 parsers that 138 don't support collections should not confuse collections they receive 139 with attributes that they do support. 141 2 Solution 143 The new mechanism is a new IPP attribute syntax called a 'collection'. 144 As such each collection value is a value of an attribute whose attribute 145 syntax type is defined to be a 'collection'. Such an attribute is 146 called a collection attribute. The name of the collection attribute 147 serves to identify the collection value in an operation request or 148 response, as with any attribute value. 150 The 'collection' attribute syntax is a container holding one or more 151 named values (i.e., attributes), which are called member attributes. 152 Each collection attribute definition document lists the mandatory and 153 optional member attributes of each collection value. A collection value 154 is similar to an IPP attribute group in a request or a response, such as 155 the operation attributes group. They both consist of a set of 156 attributes. 158 As with any attribute syntax, the collection attribute definition 159 document specifies whether the attribute is single-value (collection) or 160 multi-valued (1setOf collection). 162 The name of each member attribute MUST be unique, but MAY be the same as 163 the name of a member attribute in another collection type and/or MAY be 164 the same as the name of an attribute that is not a member of a 165 collection.. The rules for naming member attributes are given in 166 section 3.1. 168 Each member attribute can have any attribute syntax type, including 169 'collection', and can be either single-valued or multi-valued. The 170 length of a collection value is not limited. However, the length of each 171 member attribute MUST NOT exceed the limit of its attribute syntax. 173 The member attributes in a collection MAY be in any order in a request 174 or response. When a client sends a collection attribute to the Printer, 176 [Expires: September 9, 2000] 177 the order that the Printer stores the member attributes of the 178 collection value and the order returned in a response MAY be different 179 from the order sent by the client. 181 A collection value MUST NOT contains two or more member attributes with 182 the same attribute name. Such a collection is mal-formed. Clients MUST 183 NOT submit such malformed requests and Printers MUST NOT return such 184 malformed responses. If such a malformed request is submitted to a 185 Printer, the Printer MUST reject the request with the 'client-error-bad- 186 request' status code (see section 13.1.4.1) 188 ISSUE 01: In attribute groups [ipp-mod] allows a Printer either (1) to 189 reject a request with duplicate named attributes OR (2) to choose 190 exactly one of the attributes as the one to be used. Should we REQUIRE 191 the Printer to reject duplicate named attributes in a collection value 192 as stated above or allow the Printer to choose one member attribute as a 193 second alternative as we do with attribute groups? 195 3 Definition of a Collection Attribute 197 This section describes the requirements for any collection attribute 198 definition. 200 3.1 Member Attribute Naming Rules 202 Each collection attribute MUST have a unique name within the scope in 203 which the collection attribute occurs. If the collection attribute 204 occurs as a member of a request or response attribute group, it MUST be 205 unique within that group, same as for any other attribute. If a 206 collection attribute occurs as a member attribute of another collection, 207 the collection attribute MUST have a unique name within that collection 208 value, same as for any other attribute. 210 Each member attribute in a collection value MUST have unique name within 211 that collection value. Member attribute names MAY be reused between 212 different collection attributes. An example is the "media" attribute 213 which MAY be used as a job template attribute (see [ipp-mod]) and in a 214 collection. All attribute names that are reused MUST have an identical 215 syntax. All attribute names that are reused MUST have a similar 216 semantics. The semantic difference MUST be limited to boundary 217 conditions and constraints placed on the reused attributes. All 218 attributes that are not reused from elsewhere in the IPP model MUST have 219 a globally unique name. 221 Assume that it is desirable to extend IPP by adding a Job Template 222 attribute that allows the client to select the media by its properties, 223 e.g., weight, color, size, etc., instead of by name as the "media (type3 224 keyword | name) Job Template attribute in IPP/1.1 (see [ipp-mod]). The 225 first rule is that the existing attribute MUST NOT be extended by adding 226 the 'collection' attribute syntax to the existing "media" attribute. 227 That would cause too many interoperability problems and complicates the 229 [Expires: September 9, 2000] 230 validation and defaulting rules as well. Instead, a new attribute will 231 be defined with a suffix of "-col" (for collection), e.g., "media-col" 232 (collection). 234 For a second example, suppose it is desirable to extend IPP by allowing 235 the client to select the media for the job start sheet. Again, this 236 would not be done by adding the 'collection' attribute syntax to the 237 existing "job-sheets" (type2 keyword | name) Job Template attribute. 238 Instead, a new "job-sheet-col" (collection) Job Template attribute MUST 239 be introduced. The member of the "job-sheet-col" collection might be: 241 "job-sheet-format" (type3 keyword | name) 242 "media" (type3 keyword | name) 244 if any of the "media-supported" (1setOf (type3 keyword | name)) Printer 245 attribute values could be specified for job sheets. The reason that the 246 "job-sheet-format" member attribute isn't named simply, "job-sheet", is 247 because its values only indicate the format, and don't imply any media, 248 while the "job-sheets" (type2 keyword | name) Job Template attribute do 249 imply a media. This example illustrates when a member attribute can be 250 the same as another attribute (in this case a Job Template attribute) 251 and when the member attribute MUST have a different name. 253 If the definers of the "job-sheet-col" (collection) attribute intended 254 that the System Administrator be allowed to have a different set of 255 media values for job sheets than documents, then the definition document 256 for the "job-sheet-col" collection attribute would have the following 257 member attributes instead: 259 "job-sheet-format" (type3 keyword | name) 260 "job-sheet-media" (type3 keyword | name) 262 Then the supported values would be include in a separate "job-sheet- 263 media-supported" (1setOf (type3 keyword | name)) Printer attribute. 265 3.2 Remaining rules for a collection attribute definition 267 When a specification document defines an "xxx" collection attribute, 268 i.e., an attribute whose attribute syntax type is 'collection' or 269 '1setOf collection'; the definition document MUST include the following 270 aspects of the attribute semantics. Suppose the "xxx" collection 271 attribute contains an "aaa" member attribute. A simplified example of a 272 collection specification is given in section 6 274 1. The name of the collection attribute MUST be specified. (e.g. 275 "xxx") 277 2. The collection attribute syntax MUST be of type 'collection' or 278 '1setOf collection'. 280 3. The context of the collection attribute MUST be specified, i.e., 281 whether the attribute is an operation attribute, a Job Template 282 attribute, a Job Description attribute, a Printer Description 284 [Expires: September 9, 2000] 285 attribute, a member attribute of a particular collection attribute, 286 etc. 288 4. The member attributes MUST be defined. For each member attribute 289 the definition document MUST provide the following: 291 a)The member attribute's name, "aaa", MUST either (1) reuse the 292 attribute name of another attribute if the member attribute 293 shares the syntax and semantics with the other attribute or (2) 294 be unique across the entire IPP attribute name space 296 b)Whether the member attribute is REQUIRED or OPTIONAL for the 297 Printer to support 299 c)Whether the member attribute is REQUIRED or OPTIONAL for the 300 client to supply in a request 302 d)The member attribute's syntax type, which can be any attribute 303 syntax, including '1setOf X', 'collection', and '1setOf 304 collection'. If this attribute name is the same as another 305 attribute (case of option a-1 above), it MUST have the same 306 attribute syntax, including cardinality (1setOf or not). 308 e)The semantics of the "aaa" member attribute. The semantic 309 definition MUST include a description of any constraint or 310 boundary conditions the member attribute places on the 311 associated attribute, especially if the attribute is the same as 312 another attribute used in a different context (case of option a- 313 1 above) 315 f)the supported values for the "aaa" member attribute, either 316 enumerated explicitly or specified by the values of a referenced 317 attribute which may be specified by either: 319 @ the attribute's definition 321 @ a Printer attribute, such as "aaa-supported", which 322 contains the explicit values supported. The "aaa-supported" 323 attribute is a Printer attribute and not in a collection. 324 For example, if a collection contains the "media" attribute 325 and its supported values are specified by the "media- 326 supported" attribute, the "media-supported" attribute is 327 the same Printer attribute that the "media" attribute uses. 329 g)the default value of "aaa" member attribute if it is OPTIONAL 330 for a client to supply the "aaa" member attribute in a request. 331 The default value is specified by either: 333 @ the attribute's definition 335 @ a Printer attribute, such as "aaa-default", which may have 336 a collection value 338 [Expires: September 9, 2000] 340 @ or an implementation defined algorithm that takes into 341 account the values of the other member attributes of the 342 collection value 344 h)Depending on the collection attributes context, it MUST follow 345 the additional rules specified below for the various contexts. 347 3.3 Nested Collections 349 A member attribute may have a syntax type of 'collection' or '1setOf 350 collection'. The following example assumes a "yyy" collection attribute 351 is a member attribute of the preceding "xxx" collection attribute. The 352 "yyy" collection attribute contains "bbb" member attribute. The 353 definition document for the nested collection MUST include: 355 1.The name of the collection attribute, e.g., "yyy" 357 2.The collection attribute syntax MUST be of type 'collection' or 358 '1setOf collection' 360 3.The member attributes MUST be defined. For each member attribute the 361 definition document MUST provide the following: 363 a) The member attribute's name, "bbb", MUST either (1) reuse the 364 attribute name of another attribute if the member attribute shares 365 the syntax and semantics with the other attribute or (2) be unique 366 across the entire IPP attribute name space 368 b) Whether the member attribute is REQUIRED or OPTIONAL for the 369 Printer to support 371 c) Whether the member attribute is REQUIRED or OPTIONAL for the client 372 to supply in a request 374 d) The member attribute's syntax type, which can be any attribute 375 syntax, including '1setOf X', 'collection', and '1setOf 376 collection'. If this attribute name is the same as another 377 attribute (case of option a-1 above), it MUST have the same 378 attribute syntax, including cardinality (1setOf or not) 380 e) The semantics of the member attribute. The semantic definition MUST 381 include a description of any constraint or boundary conditions the 382 member attribute places on the associated attribute, especially if 383 the attribute is the same as another attribute used in a different 384 context (case of option a-1 above) 386 f) 388 g) Depending on the collection attributes context, it MUST follow the 389 additional rules specified below for the various contexts. 391 [Expires: September 9, 2000] 393 3.4 Collection Attributes as Operation Attributes 395 The definition documents that define a collection attribute for use as 396 an operation attribute MUST follow these additional rules: 398 a)Define in which operation requests the collection attribute is 399 intended to be used. 401 b)Define in which operation responses the collection attribute is 402 intended to be used. 404 3.5 Collections as Job Template Attributes 406 The definition documents for collection attributes that are specified to 407 be Job Template attributes (see [ipp-mod] section 4.2) MUST have 408 associated printer attributes with suffixes of "-supported" and "- 409 default" (or indicate that there is no "-default"), just as for any Job 410 Template attribute. Certain Job Template collection attributes also 411 have an associated Printer attribute with "-ready" (for example, see the 412 "media-ready" attribute in [ipp-mod]). Furthermore member attributes of 413 job template attributes are addressed using the same suffix convention. 415 See also section 3.6 on the interaction of collections and the Get- 416 Printer-Attributes and Get-Jobs-Attributes. 418 For the following rules assume the "xxx" (collection) example from 419 section 3.2 is a job template attribute. 421 1)There MUST be two associated printer attributes. The attributes are 422 "xxx-supported" and "xxx-default" 424 2)The "xxx-default" is a collection with a syntax identical to the 425 "xxx" specification in section 3.2 . 427 @ Each member attribute has the same name as in the "xxx" 428 definition. 430 @ A Get-Printer-Attributes operation MUST return the "xxx-default" 431 (collection) Printer attribute and all the member attributes. 432 Any default values that have been set MUST be returned. Any 433 default values that have not been set MUST return an out of band 434 attribute of 'no-value'. 436 3.If the definition of the collection does not mention an "xxx-ready" 437 attribute than it is assumed that one is not defined, though 438 implementer's are free to support an "xxx-ready" as an extension. 440 4.The collection attribute definition document MUST define an "xxx- 441 supported" attribute with either a syntax of '1setOf type2 keyword' 442 or '1setOf collection': 444 [Expires: September 9, 2000] 445 @ If the definition uses the '1setOf type2 keyword' attribute 446 syntax, it MUST be the attribute keyword names of all of the 447 member attributes that the Printer implementation supports in a 448 Job Creation operation. Furthermore, the definition MUST 449 include corresponding definitions of each of the "aaa-supported" 450 attributes that correspond to each "aaa" member attribute. Then 451 a client can determine the supported values of each member 452 attribute in the Job Template collection attribute 454 @ If the definition uses the '1setOf collection' attribute syntax, 455 then the values are the supported instances of the "xxx" 456 (collection) attribute that a client can supply in a Job 457 Creation operation. It is expected that this second approach 458 will be used for small collections whether the number of 459 possible collection values is small. For example, a "media- 460 size" (collection) member attribute in which the member 461 attributes are "x-dimension" (integer) and "y-dimension" 462 (integer). The pairs of integers are just like keywords as far 463 as the client localization is concerned, except that if the 464 client doesn't recognize a size pair of numbers, it can display 465 the numbers. 467 a) The keywords returned lists all the contained member attribute 468 names. This example would return the "aaa" keyword. 470 b) The list is recursive and lists all the member attributes of the 471 contained collections. In section 3.3 the printer would return 472 "aaa" and "bbb" for collection "xxx" 474 c) The encoding convention allows the reconstruction of the collection 475 structure. The will allow the client to reconstruct the 476 collections. The client would know that "aaa" is a member of 477 collection "xxx". It can also be derived that collection "bbb" is 478 a member of collection "yyy". See section 7 for more information 479 on encoding. 481 d) To obtain the supported values for any member attribute a client 482 performs a Get-Printer-Attributes operation explicitly requesting 483 the member attribute name with the suffix "supported". If a member 484 attribute is itself a collection rule 4 above applies to member 485 attribute. 487 3.6 Collections and Get-Printer-Attributes and Get-Job-Attributes 488 operations 490 The behavior of collections for "job-description" and "printer- 491 description" is similar to any other attribute. Simple attributes 492 return the attribute and its value. For a collection, the collection 493 and its entire member attributes and their values are returned. This 494 includes any containing collections, its member attributes and their 495 values. The same logic applies for the "-default" and "-ready" printer 496 attribute associated with a job-template attributes. 498 [Expires: September 9, 2000] 499 Whether the Printer applies individual member attributes independently 500 or takes into account the member attributes supplied by the client in 501 the collection, depends on implementation. Therefore, a client SHOULD 502 query the Printer's "xxx-default" (collection) attribute, allow the user 503 to make any changes, and then submit the entire collection to the 504 Printer. Then the variability in defaulting between different 505 implementations will not cause the user to get unexpected results. 507 The semantics for "-supported" is different for a collection. Here the 508 focus is on the member attributes that the collection supports. This 509 solution allows for extension of collections and allowing the member 510 attributes of a collection to vary (i.e. mandatory and optional member 511 attributes). Once a client determines what member attributes are 512 supported in a collection a subsequent request can be constructed to 513 determine the supported values for the member attributes. 515 Another advantage of that the behavior of the "-supported" printer 516 collection attribute is limiting the amount of data that is returned on 517 general queries. A 'get-printer-attributes' that returns all the 518 attributes of a printer will not have to return what may turn out to be 519 extensive lists of "-supported" attribute values. An example might be 520 "media-col" that could be a representation for media using a collection 521 that goes beyond the information currently provided by the job-template 522 attribute "media". The "media-col" could now be used to represent a 523 job's media, insert sheets and inserted tab sheets. An IPP Printer 524 implementation would return the member attributes for each of the "- 525 supported" collections. 527 4 New Out-of-band value 529 4.1 'none' 531 'none' The specified Job Template attribute in the request MUST 532 NOT be applied to the job. Specifically, this value 533 overrides the Printer's "xxx-default" attribute value for 534 the Job Template attribute, if one exists. 536 This "out-of-band" value allows a client to specify "turn-off" a feature 537 that is specified by an attribute whose value is a collection. Because a 538 client specifies a value, the Printer uses the client-specified value 539 and not the Printer's default value. 541 If a Printer supports the use of the 'collection' attribute syntax for 542 an attribute, a Printer MUST support the use of the "out-of-band" value 543 'none'. 545 A Printer MUST support the "out-of-band" value 'none' as the value for 546 an attribute "xxx" if: 548 [Expires: September 9, 2000] 549 @ the definition of the attribute specifies 'none' MUST be 550 supported AND 552 @ the definition of the attribute specifies 'none' MAY be 553 supported and it is a value of the attribute "xxx-supported". 555 5 Unsupported Values 557 The rules for returning an unsupported collection attribute are an 558 extension to the current rules. 560 If the entire collection attribute is unsupported, then the Printer 561 returns just the collection attribute name with the 'unsupported' 562 out-of-band value (see the beginning of [ipp-mod] section 4.1) in the 563 Unsupported Attributes Group. 565 If a collection contains unrecognized, unsupported member attributes 566 and/or conflicting values, the attribute returned in the Unsupported 567 Group is a collection containing the unrecognized, unsupported member 568 attributes, and/or conflicting values. The unrecognized member 569 attributes have an out-of-band value of 'unsupported' (see the 570 beginning of [ipp-mod] section 4.1). The unsupported member 571 attributes and conflicting values have their unsupported or 572 conflicting values. 574 6 Sample specification 576 This example is for a collection called "media-col". The "media-col" 577 attribute is a job template attribute. This collection is simplified 578 and fictitious and is used for illustrative purposes only. 580 Name: media-col 582 Syntax: collection 584 Member Attributes: 586 Name: "media-color" 588 Syntax: type3 keyword | name 590 Mandatory 592 Semantics: This attribute identifies the color of the media. Valid 593 values are "red" "white" and "blue" 595 "media-color-supported" syntax: 1setOf (type2 keyword | name) 597 Name: "media-size" 599 [Expires: September 9, 2000] 600 Syntax: collection 602 Member Attributes: 604 Name: "x-dimension" 606 Syntax: integer 608 Mandatory 610 Semantics: This attribute identifies length of the media in 611 inches. Valid values are any integer though in practice 612 implementation will constrain the range. 614 x-supported syntax: rangeOfInteger 616 Name: "y-dimension" 618 Syntax: integer 620 Mandatory 622 Semantics: This attribute identifies the width of the media in 623 inches. Valid values are any integer though in practice 624 implementation will constrain the range. 626 y-supported syntax: rangeOfInteger 628 Name: name 630 Syntax: See job template attribute "media" 632 Optional 634 Semantics: See job template attribute "media". Additional 635 restrictions on "media" in this collection are that the "media" 636 value must be valid based on the size and color. When invalid 637 names are given based on the size or color, the size or color value 638 takes precedence. 640 Supported values identical to job template attribute "media- 641 supported". 643 7 Encoding 645 This section is still under construction. 647 We are now down to considering two encodings for collections. The goals 648 of the encoding are: 650 [Expires: September 9, 2000] 651 a) must be simple 653 b) a legacy receiver must correctly ignore a collection value and not 654 incorrectly decode part of a collection as a legitimate attribute. 656 c) it parses an attributes with collection values as a single unknown 657 attribute rather than as many unknown attributes. 659 The two encodings are: 661 1) encode attributes within collections in the same way as 662 attributes outside of collections, but encode each attribute name 663 in a collection so that its name cannot be the same as an attribute 664 name outside of a collection. We have considered two solutions for 665 encoding attribute names. 667 a) add a prefix to each collection member attribute name where 668 the prefix is the (outer) attribute's name following by a dot 669 ("."). Nested collections have extra levels of dotted names. 670 For example, the "media-size" attribute in "media-col" is 671 encoded as "media-col.media-size" and the "x" attribute in 672 "media-size" which is inside "media" is encoded as "media- 673 col.media-size.x". The outer attribute name is the "name" of 674 the begin-collection and end-collection value. 676 b) add a hyphen suffix to each attribute name in a collection. 677 For example, the "media-size" attribute in "media-col" is 678 encoded as "media-size-" and the "x" attribute in "media-size" 679 which is inside "media" is encoded as "x-". Note the hyphen 680 must be a suffix so that the attribute name follows the rules 681 for a legal keyword, and the hyphen is chosen because no 682 attributes currently end with a hyphen. The empty name is used 683 for the end-collection value and all but the first begin- 684 collection value. 686 2) encode attributes within a collection as a 1setOf values where 687 each attribute whose name is M and whose values are V1 ... Vn are 688 encoded as a sequence of n+1 values M, V1, ... Vn. Subsequent 689 member attributes continue the value in the 1setOf values. 691 The following are examples of encodings. In the real encoding, each 692 "attribute" consists of 694 a) a one byte tag 696 b) a two byte name length whose value is "n" 698 c) "n" bytes of a name 700 d) a two bytes value length whose value is "v" 702 e) "v" bytes of a value 704 [Expires: September 9, 2000] 706 To make it easy to read, we show only items c (the name), a (the tag) 707 and e (the value), in that order. 709 There are 3 encoding examples for each solution: 711 i) media-col with media-color and media-size as member attributes, 712 and where media-size contains "x" and "y" as collection members. 714 ii) media-size-supported with two collection values. 716 iii) job-notify with notify-recipients and notify-events which is a 717 1setOf keyword with 3 values in this example 719 Solution 1a) 721 Name syntax-type value 722 "media-col" begin-collection "" 723 "media-col.media-color" keyword white 724 "media-col.media-size" begin-collection "" 725 "media-col.media-size.x" integer 850 726 "media-col.media-size.y" integer 1100 727 "media-col.media-size" end-collection "" 728 "media-col" end-collection "" 730 Name syntax-type value 731 "media-size-supported" begin-collection "" 732 "media-size-supported.x" integer 850 733 "media-size-supported.y" integer 1100 734 "media-size-supported" end-collection "" 735 "media-size-supported" begin-collection "" 736 "media-size-supported.x" integer 850 737 "media-size-supported.y" integer 1400 738 "media-size-supported" end-collection "" 740 Name syntax-type value 741 "job-notify" begin-collection "" 742 "job-notify.notify-recipients" url "mailto://bill@foo.com" 743 "job-notify.notify-events" keyword job-completed 744 "" keyword job-created 745 "" keyword job-state-changed 746 "job-notify" end-collection "" 748 Solution 1b) 750 Name syntax-type value 751 "media-col" begin-collection "" 752 "media-color-" keyword white 753 "media-size-" begin-collection "" 754 "x-" integer 850 755 "y-" integer 1100 757 [Expires: September 9, 2000] 758 "media-size-" end-collection "" 759 "" end-collection "" 761 Name syntax-type value 762 "media-size-supported" begin-collection "" 763 "x-" integer 850 764 "y-" integer 1100 765 "" end-collection "" 766 "" begin-collection "" 767 "x-" integer 850 768 "y-" integer 1400 769 "" end-collection "" 771 Name syntax-type value 772 "job-notify" begin-collection "" 773 "notify-recipients-" url "mailto://bill@foo.com" 774 "notify-events-" keyword "job-completed" 775 "" keyword "job-created" 776 "" keyword "job-state-changed" 777 "job-notify" end-collection "" 779 Solution 2) 781 Name syntax-type value 782 "media-col" begin-collection "" 783 "" attribute-name "media-color" 784 "" keyword white 785 "" attribute-name "media-size" 786 "" begin-collection "" 787 "" attribute-name "x" 788 "" integer 850 789 "" attribute-name "y" 790 "" integer 1100 791 "" end-collection "" 792 "" end-collection "" 794 Name syntax-type value 795 "media-size-supported" begin-collection "" 796 "" attribute-name "x" 797 "" integer 850 798 "" attribute-name "y" 799 "" integer 1100 800 "" end-collection "" 801 "" begin-collection "" 802 "" attribute-name "x" 803 "" integer 850 804 "" attribute-name "y" 805 "" integer 1400 806 "" end-collection "" 808 Name syntax-type value 810 [Expires: September 9, 2000] 811 "job-notify" begin-collection "" 812 "" attribute-name "notify-recipients" 813 "" url mailto://bill@foo.com" 814 "" attribute-name "notify-events" 815 "" keyword "job-completed" 816 "" keyword "job-created" 817 "" keyword "job-state-changed" 818 "" end-collection "" 820 Observations: 822 Solution 1a have identical properties to solution 1b except that the 823 rules for encoding the name are more complicated for 1a, and the name of 824 the attribute appears before each end-collection and end-collection in 825 1a but only before the first begin-collection in 1b. 827 If a collection aware client sends a collection to a collection unaware 828 Printer: 830 For solutions 1a and 1b) the Printer sees many attributes in place of 831 the collection and it returns in the Unsupported attribute group, all of 832 the attributes: the attribute outside the collection and each attribute 833 in the collection with it altered name. Thus the unsupported attributes 834 have names that the client didn't send and they may be in an order that 835 makes it hard to reconstruct the collection. In addition, because the 836 "end-collection" has the same name as the attribute for 1a, some 837 printers will reject the job because the attribute appears twice. Also, 838 1a does not work for a 1setOf collection because the name of the 839 attributes appear in front of each begin-collection and thus cannot be 840 distinguished from two occurrences of the same attribute. 842 For solution 2) the Printer sees the collection as a 1setOf values where 843 some values have unknown syntax types and other values have known syntax 844 types. When a collection-unaware printer discovers it doesn't 845 understand an attribute that is a collection, it sees the unknown 846 attribute as a 1setOf rather than a collection. It still returns the 847 attribute-name with the out-of-band value "unsupported" making it easier 848 for the client. 850 7.1 encoding of a collection (using solution 1a) 852 NOTE: If we pick another solution to the encoding, this section will 853 change. 855 Each collection MUST have a globally unique name. Each attribute in an 856 attribute group or a collection MUST have globally unique name. 858 [Expires: September 9, 2000] 859 Uniqueness is generated by prepending the collection name to the 860 attribute using a period, '.' as a separator. 862 For encoding attributes that have a 'collection' attribute syntax, the 863 attribute's name is REQUIRED to be the first part of each of the member 864 attribute name separated by a PERIOD (.) character. For example, if a 865 "media-col" (collection) Job Template attribute is added to IPP and 866 contains a member attribute "color, it MUST be encoded as a "media- 867 col.color". In another example, if the "job-sheets" (collection) Job 868 Template attribute is added to IPP and reuses the "color" member 869 attribute, the "color" attribute MUST be encoded as "job-sheets.color". 870 The "xxx.color" attribute has an identical attribute syntax and similar 871 semantics. 873 When encoding a collection attribute "xxx" that contains an attribute 874 "aaa". A simplified example of a collection specification is given in 875 section 6 877 1.The beginning of the collection is indicated with a value tag that 878 MUST be syntax type 'begincollection' (e.g. 0x34). 880 2.The length of the collection name (e.g. 0x03) 882 3.The collection name (e.g. "xxx") 884 4.A null collection value length (e.g. 0x00) 886 5.The attributes are encoded as with any other attribute. It is valid 887 to have a collection a member of a collection. The modifications 888 necessary for encoding member attributes of a collection are as 889 follows. 891 a) The name of the member attribute MUST be prepended with the 892 collection name and a period. 894 b) The length of the member attribute name MUST be adjusted 895 appropriately. 897 6.The end of the collection is indicated with a value tag that MUST be 898 syntax type 'endCollection' (e.g. 0x37). 900 7.The length of the collection name (e.g. 0x03) 902 8.The collection name (e.g. "xxx") 904 9.A null collection value length (e.g. 0x00) 906 [Expires: September 9, 2000] 907 7.2 Sample Encoding (using solution 1a) 909 NOTE: If we pick another solution to the encoding, this section will 910 change. 912 This section defines the encoding of a collection syntax type using 913 solution 1a. The collection specified in section 6 is used. The 914 encoding is of an implementation that does not support any optional 915 attributes. A collection is encoded by using two new tags: 917 Tag name Tag Meaning 918 value 920 beginCollection 0x34 Begin the named collection. 922 endCollection 0x37 End the named collection. 924 A collection value is encoded as a sequence of attribute values 925 preceded by a beginCollection attribute and followed by an endCollection 926 attribute. The name field of a beginCollection and an endCollection both 927 contain the name of the collection type, i.e., the keyword name of the 928 collection attribute, which is a string of ASCII characters. The value 929 field contains the prefix used for all subordinate member attributes. 930 The following example is written in the style of the IPP/1.1 "Encoding 931 and Transport" document [ipp-pro]. The following example is for a media 932 collection attribute. The media collection contains 2 member 933 attributes. One member is "color" that contains a keyword for the 934 media's color. The second attribute is a collection that gives the 935 media's size. The size collection has two integer attributes "x" and 936 "y" that gives the media's size in inches 938 Octets Symbolic Protocol comments 939 Value field 941 0x34 beginCollecti value-tag Beginning of the collection 942 on 943 0x0009 name- Length of collection's name 944 length 945 media-col media-col Name Collection's name 946 0x0000 Value- 947 length 949 0x44 keyword type value-tag Member attribute type 950 0x000F name- Length of member attribute 951 length name 952 media-col.color media- Name Name of member attribute 953 col.color 954 0x0004 value- 955 length 956 blue blue Value 958 0x34 beginCollecti value-tag Beginning of the sub- 959 on collection 961 [Expires: September 9, 2000] 963 Octets Symbolic Protocol comments 964 Value field 966 0x000E name- Length of sub-collection's 967 length name 968 media-col.size media- Name Sub-collection's name 969 col.size 970 0x0000 Value- 971 length 973 0x21 integer type value-tag Member attribute type 974 0x0010 name- Length of member attribute 975 length name 976 media- media- Name Name of member attribute 977 col.size.x col.size.x 978 0x0004 value- 979 length 980 0x0006 Value 982 0x21 integer type value-tag Member attribute type 983 0x0007 name- Length of member attribute 984 length name 985 media- media- Name Name of member attribute 986 col.size.y col.size.y 987 0x0004 value- 988 length 989 0x0004 Value 991 0x37 endCollection value-tag end of the sub-collection 992 0x0007 name- Length of sub-collection's 993 length name 994 media-col.size media- Name Sub-collection's name 995 col.size 996 0x0000 Value- 997 length 999 0x37 endCollection value-tag end of the collection 1000 0x0007 name- Length of collection's name 1001 length 1002 media-col media-col Name Sub-collection's name 1003 0x0000 Value- 1004 length 1006 7.3 1setOf Collection encoding (using solution 1a) 1008 The encoding of a set of collections follows the standard method of 1009 encoding multi-valued IPP attributes. The "beginCollection" attribute 1010 is coded normally. The first instance of the collection follows. The 1011 "endCollection" MUST appear only once in a collection and MUST follow 1012 the last member of the set of collection. The member collections of a 1014 [Expires: September 9, 2000] 1015 set of collections are delineated by a specially encoded 1016 "beginCollection" attribute. The type MUST be "beginCollection" (i.e. 1017 0x34). The length of the name field MUST be 0x0000. The name field 1018 MUST be omitted. The length of the value MUST be the length of the 1019 collection's prefix. The value MUST be the prefix. 1021 7.4 Sample 1setOf Collection encoding (using solution 1a) 1023 NOTE: If we pick another solution to the encoding, this section will 1024 change. 1026 This section defines the encoding of a collection syntax type using 1027 solution 1a. The collection specified in section 7 is used. The 1028 difference is that the type of "media-col" is 1setOf collection instead 1029 of collection. The encoding is of an implementation that does not 1030 support any optional attributes. 1032 Octets Symbolic Protocol comments 1033 Value field 1035 0x34 beginCollecti value-tag Beginning of the collection 1036 on 1037 0x0009 name- Length of collection's name 1038 length 1039 media-col media-col Name Collection's name 1040 0x0000 Value- 1041 length 1043 0x44 keyword type value-tag Member attribute type 1044 0x000F name- Length of member attribute 1045 length name 1046 media-col.color media- Name Name of member attribute 1047 col.color 1048 0x0004 value- 1049 length 1050 blue blue Value 1052 0x34 beginCollecti value-tag Beginning of the sub- 1053 on collection 1054 0x000E name- Length of sub-collection's 1055 length name 1056 media-col.size media- Name Sub-collection's name 1057 col.size 1058 0x0000 Value- 1059 length 1061 0x21 integer type value-tag Member attribute type 1062 0x00010 name- Length of member attribute 1063 length name 1065 [Expires: September 9, 2000] 1067 Octets Symbolic Protocol comments 1068 Value field 1070 media- media- Name Name of member attribute 1071 col.size.y col.size.y 1072 0x0004 value- 1073 length 1074 0x0006 Value 1076 0x21 integer type value-tag Member attribute type 1077 0x00010 name- Length of member attribute 1078 length name 1079 media- media- Name Name of member attribute 1080 col.size.x col.size.x 1081 0x0004 value- 1082 length 1083 0x0004 Value 1085 0x37 endCollection value-tag end of the sub-collection 1086 0x000E name- Length of sub-collection's 1087 length name 1088 media-col.size media- Name Sub-collection's name 1089 col.size 1090 0x0000 Value- 1091 length 1093 Second collection in set 1095 0x34 beginCollecti value-tag Beginning of the collection 1096 on 1097 0x0000 name- Indicates continuation of 1098 length set 1099 0x0000 Value- 1100 length 1102 0x44 keyword type value-tag Member attribute type 1103 0x000F name- Length of member attribute 1104 length name 1105 media-col.color media- Name Name of member attribute 1106 col.color 1107 0x0003 value- 1108 length 1109 red red Value 1111 0x34 beginCollecti value-tag Beginning of the sub- 1112 on collection 1113 0x000E name- Length of sub-collection's 1114 length name 1115 media-col.size media- Name Sub-collection's name 1116 col.size 1118 [Expires: September 9, 2000] 1120 Octets Symbolic Protocol comments 1121 Value field 1123 0x0000 Value- 1124 length 1126 0x21 integer type value-tag Member attribute type 1127 0x0010 name- Length of member attribute 1128 length name 1129 media- media- Name Name of member attribute 1130 col.size.y col.size.y 1131 0x0004 value- 1132 length 1133 0x0006 Value 1135 0x21 integer type value-tag Member attribute type 1136 0x0010 name- Length of member attribute 1137 length name 1138 media- media- Name Name of member attribute 1139 col.size.x col.size.x 1140 0x0004 value- 1141 length 1142 0x0004 Value 1144 0x37 endCollection value-tag end of the sub-collection 1145 0x000E name- Length of sub-collection's 1146 length name 1147 media-col.size media- Name Sub-collection's name 1148 col.size 1149 0x0000 Value- 1150 length 1152 0x37 endCollection value-tag end of the set of 1153 collections 1154 0x0009 name- Length of collection's name 1155 length 1156 media-col media-col Name collection's name 1157 0x0000 Value- Length of collection's 1158 length prefix 1160 8 Legacy issues 1162 IPP 1.x Printers and Clients will gracefully ignore collections and its 1163 member attributes if it does not understand the collection. The 1164 begCollection and endCollection elements each look like an attribute 1165 with an attribute syntax that the recipient doesn't support and so 1166 should ignore the entire attribute. The individual member attributes 1167 will look like ordinary attributes, but since they each are encoded with 1169 [Expires: September 9, 2000] 1170 a unique name that can't be the same as a top level attribute, each of 1171 the member attributes will also look like attributes that the recipient 1172 doesn't support and so should ignore. 1174 9 IANA Considerations 1176 This attribute syntax will be registered with IANA after the WG approves 1177 its specification according to the procedures for extension of the 1178 IPP/1.1 Model and Semantics [ipp-mod]. 1180 ISSUE 04 - Since this is intended to be a standards track document, do 1181 we also register the attribute syntax with IANA? 1183 10 Internationalization Considerations 1185 This attribute syntax by itself has no impact on internationalization. 1186 However, the member attributes that are subsequently defined for use in 1187 a collection may have internationalization considerations, as may any 1188 attribute, according to [ipp-mod]. 1190 11 Security Considerations 1192 This attribute syntax causes no more security concerns than any other 1193 attribute syntax. It is only the attributes that are subsequently 1194 defined to use this or any other attribute syntax that may have security 1195 concerns, depending on the semantics of the attribute, according to 1196 [ipp-mod]. 1198 12 References 1200 [ipp-mod] 1201 Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P., 1202 "Internet Printing Protocol/1.1: Model and Semantics" draft-ietf- 1203 ipp-model-v11-06.txt, March 1, 2000. 1205 [ipp-ntfy] 1206 Isaacson, S., Martin, J., deBry, R., Hastings, T., Shepherd, M., 1207 Bergman, R. " Internet Printing Protocol/1.0 & 1.1: IPP Event 1208 Notification Specification" draft-ietf-ipp-not-spec-02.txt, work in 1209 progress, February 2, 2000. 1211 [ipp-pro] 1212 Herriot, R., Butler, S., Moore, P., Turner, R., "Internet Printing 1213 Protocol/1.1: Encoding and Transport", draft-ietf-ipp-protocol-v11- 1214 05.txt, March 1, 2000. 1216 [RFC2565] 1217 Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing 1218 Protocol/1.0: Encoding and Transport", RFC 2565, April 1999. 1220 [Expires: September 9, 2000] 1222 [RFC2566] 1223 R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell, 1224 "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, 1225 April 1999. 1227 [RFC2567] 1228 Wright, D., "Design Goals for an Internet Printing Protocol", RFC 1229 2567, April 1999. 1231 [RFC2568] 1232 Zilles, S., "Rationale for the Structure and Model and Protocol for 1233 the Internet Printing Protocol", RFC 2568, April 1999. 1235 [RFC2569] 1236 Herriot, R., Hastings, T., Jacobs, N., Martin, J., "Mapping between 1237 LPD and IPP Protocols", RFC 2569, April 1999. 1239 [RFC2616] 1240 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. 1241 Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", 1242 RFC 2616, June 1999. 1244 13 Author's Addresses 1246 Roger deBry 1247 Utah Valley State College 1248 Orem, UT 84058 1249 Phone: (801) 222-8000 1250 EMail: debryro@uvsc.edu 1252 Tom Hastings 1253 Xerox Corporation 1254 737 Hawaii St. ESAE 231 1255 El Segundo, CA 90245 1256 Phone: 310-333-6413 1257 Fax: 310-333-5514 1258 e-mail: hastings@cp10.es.xerox.com 1260 Robert Herriot 1261 Xerox Corp. 1262 3400 Hill View Ave, Building 1 1263 Palo Alto, CA 94304 1264 Phone: 650-813-7696 1265 Fax: 650-813-6860 1266 e-mail: robert.herriot@pahv.xerox.com 1268 Kirk Ocke 1269 Xerox Corp. 1270 800 Phillips Rd 1271 M/S 139-05A 1272 Webster, NY 14580 1274 [Expires: September 9, 2000] 1275 Phone: (716) 442-4832 1276 EMail: kirk.ocke@usa.xerox.com 1278 Peter Zehler 1279 Xerox Corp. 1280 800 Phillips Rd 1281 M/S 139-05A 1282 Webster, NY 14580 1283 Phone: (716) 265-8755 1284 EMail: peter.zehler@usa.xerox.com 1286 14 Appendix A: Full Copyright Statement 1288 Copyright (C) The Internet Society (1998,1999,2000). All Rights Reserved 1290 This document and translations of it may be copied and furnished to 1291 others, and derivative works that comment on or otherwise explain it or 1292 assist in its implementation may be prepared, copied, published and 1293 distributed, in whole or in part, without restriction of any kind, 1294 provided that the above copyright notice and this paragraph are included 1295 on all such copies and derivative works. However, this document itself 1296 may not be modified in any way, such as by removing the copyright notice 1297 or references to the Internet Society or other Internet organizations, 1298 except as needed for the purpose of developing Internet standards in 1299 which case the procedures for copyrights defined in the Internet 1300 Standards process must be followed, or as required to translate it into 1301 languages other than English. 1303 The limited permissions granted above are perpetual and will not be 1304 revoked by the Internet Society or its successors or assigns. 1306 This document and the information contained herein is provided on an "AS 1307 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1308 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1309 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1310 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1311 FITNESS FOR A PARTICULAR PURPOSE. 1313 [Expires: September 9, 2000]