One document matched: draft-ietf-ipp-dhcp-option-00.txt

INTERNET-DRAFT                                                 R. Turner
Expires in six months                                 Sharp Laboratories
                                                              March 1998



               DHCP Option for Internet Printing Protocol Services
                   <draft-ietf-ipp-dhcp-option-00.txt>

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.