idnits 2.17.1 draft-ietf-ipp-dhcp-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 190 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 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: '2' is defined on line 112, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ipp-model-09 ** Downref: Normative reference to an Experimental draft: draft-ietf-ipp-model (ref. '1') ** Obsolete normative reference: RFC 2044 (ref. '5') (Obsoleted by RFC 2279) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Turner 3 Expires in six months Sharp Laboratories 4 March 1998 6 DHCP Option for Internet Printing Protocol Services 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Copyright Notice 31 Copyright (C) The Internet Society (1998). All Rights Reserved. 33 Abstract 35 This document defines a new DHCP option for automatic configuration 36 of Internet Printing Protocol (IPP)[1] services to potential clients. 37 Services. This new option provides an IPP client with enough 38 configuration information to initiate a session with an IPP server 39 without manual configuration of the client, and without existing 40 directory services. 42 1. Introduction 44 An IPP service provides print job submission capabilities to IPP 45 clients in a transport-independent way. IPP servers also provide 46 limited job management functions, with optional security mechanisms. 47 The IPP working group is defining a directory schema that enables 48 directory-enabled clients to perform sophisticated searches of 49 directory services to match a client's requirement for printing 50 services. 52 The IPP Service Name option is a 16-bit Unicode text encoded into 53 an octet stream using UTF-8 [5]. 7-bit ASCII text is unchanged by 54 the UTF-8 transformation. In network environments where IPP server 55 names are restricted to the range of 7-bit ASCII characters, ASCII- 56 only DHCP clients and servers can support these options by using the 57 ASCII text as the UTF-8 encoded data. 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119. [3] 63 2. IPP Server Option 65 This option specifies one or more IPP servers for the client to 66 contact for access to IPP services. Servers SHOULD be listed in 67 order of preference. An IPP server is textually encoded as a URI 68 string. 70 The code for this option is XX (Pending future assignment by IANA). 72 Each DHCP option returned from a client query is encoded as follows: 74 0 1 2 3 75 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | Code | Length | Uniform Resource ID (var.len) 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 The client will use whatever transport is indicated by the URI schema. 81 Further semantics with regards to communication with the IPP server 82 should be derived from the semantics associated with the particular 83 URI scheme. 85 Individual DHCP options cannot exceed 255 octets. Because UTF-8 86 encoded URI strings are expected to exceed 255 octets, multiple 87 occurences of this option type in a DHCP response packet should be 88 concatenated together to form the actual URI string to be used by 89 a client. 91 3. Security Considerations 93 There is currently no standard authentication or security 94 mechanisms defined for DHCP. However, numerous internet drafts 95 have been issued that propose general security mechanisms to be 96 applied to DHCP client/server interaction. 98 Section 7 of the DHCP protocol specification [4] describes any 99 fundamental security considerations for the base DHCP protocol. 100 Specific security considerations for this proposal involve the 101 possibility that client requests for this DHCP option may be 102 forged by an unauthorized DHCP server. Clients that utilize the 103 security features of IPP can detect whether or not forgery of this 104 DHCP option has occured. 106 4. References 108 [1] DeBry R., Hastings T., Herriot R., Isaacson S., Powell P., 109 Internet Printing Protocol/1.0 Model and Semantics 110 (Pending RFC XXXX) draft-ietf-ipp-model-09.txt, January 1998. 112 [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 113 Extensions", RFC-2132, March 1997. 115 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 116 Levels", RFC-2119, March 1997. 118 [4] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, 119 March 1997. 121 [5] Yergeau, F., "UTF-8, a transformation format of Unicode and 122 ISO 10646", RFC-2044, October 1996 124 5. Author's Address 126 Randy Turner 127 Sharp Laboratories of America 128 5750 NW Pacific Rim Blvd 129 Camas, WA 98607 131 Phone: +1 360 817 8456 133 EMail: rturner@sharplabs.com 135 6. Full Copyright Statement 137 Copyright (C) The Internet Society (1997). All Rights Reserved. 139 This document and translations of it may be copied and furnished to 140 others, and derivative works that comment on or otherwise explain it 141 or assist in its implementation may be prepared, copied, published 142 and distributed, in whole or in part, without restriction of any 143 kind, provided that the above copyright notice and this paragraph are 144 included on all such copies and derivative works. However, this 145 document itself may not be modified in any way, such as by removing 146 the copyright notice or references to the Internet Society or other 147 Internet organizations, except as needed for the purpose of 148 developing Internet standards in which case the procedures for 149 copyrights defined in the Internet Standards process must be 150 followed, or as required to translate it into languages other than 151 English. 153 The limited permissions granted above are perpetual and will not be 154 revoked by the Internet Society or its successors or assigns. 156 This document and the information contained herein is provided on an 157 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 158 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 159 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 160 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 161 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.