INTERNET-DRAFT R. Turner Expires in six months Sharp Laboratories March 1998 DHCP Option for Internet Printing Protocol Services Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document defines a new DHCP option for automatic configuration of Internet Printing Protocol (IPP)[1] services to potential clients. Services. This new option provides an IPP client with enough configuration information to initiate a session with an IPP server without manual configuration of the client, and without existing directory services. 1. Introduction An IPP service provides print job submission capabilities to IPP clients in a transport-independent way. IPP servers also provide limited job management functions, with optional security mechanisms. The IPP working group is defining a directory schema that enables directory-enabled clients to perform sophisticated searches of directory services to match a client's requirement for printing services. The IPP Service Name option is a 16-bit Unicode text encoded into an octet stream using UTF-8 [5]. 7-bit ASCII text is unchanged by the UTF-8 transformation. In network environments where IPP server names are restricted to the range of 7-bit ASCII characters, ASCII- only DHCP clients and servers can support these options by using the ASCII text as the UTF-8 encoded data. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. [3] 2. IPP Server Option This option specifies one or more IPP servers for the client to contact for access to IPP services. Servers SHOULD be listed in order of preference. An IPP server is textually encoded as a URI string. The code for this option is XX (Pending future assignment by IANA). Each DHCP option returned from a client query is encoded as follows: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Length | Uniform Resource ID (var.len) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The client will use whatever transport is indicated by the URI schema. Further semantics with regards to communication with the IPP server should be derived from the semantics associated with the particular URI scheme. Individual DHCP options cannot exceed 255 octets. Because UTF-8 encoded URI strings are expected to exceed 255 octets, multiple occurences of this option type in a DHCP response packet should be concatenated together to form the actual URI string to be used by a client. 3. Security Considerations There is currently no standard authentication or security mechanisms defined for DHCP. However, numerous internet drafts have been issued that propose general security mechanisms to be applied to DHCP client/server interaction. Section 7 of the DHCP protocol specification [4] describes any fundamental security considerations for the base DHCP protocol. Specific security considerations for this proposal involve the possibility that client requests for this DHCP option may be forged by an unauthorized DHCP server. Clients that utilize the security features of IPP can detect whether or not forgery of this DHCP option has occured. 4. References [1] DeBry R., Hastings T., Herriot R., Isaacson S., Powell P., Internet Printing Protocol/1.0 Model and Semantics (Pending RFC XXXX) draft-ietf-ipp-model-09.txt, January 1998. [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC-2132, March 1997. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC-2119, March 1997. [4] Droms, R., "Dynamic Host Configuration Protocol", RFC-2131, March 1997. [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC-2044, October 1996 5. Author's Address Randy Turner Sharp Laboratories of America 5750 NW Pacific Rim Blvd Camas, WA 98607 Phone: +1 360 817 8456 EMail: rturner@sharplabs.com 6. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.