INTERNET-DRAFT
K. Carter
IBM
S. Isaacson
Novell, Inc.
Version 1.1, March 14, 1997
Internet Printing Protocol/1.0: Directory Schema
Status of this Memo
This document is a working document of the Internet Printing Protocol (IPP) project in the Printer Working Group (PWG). It is subject to change at any time. The current version of this document can be found at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DIR/ipp-directory.pdf
This document is not yet an IETF Internet-Draft. When it becomes one the following paragraphs will replace this one.
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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document is one of a set of documents which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard, which describes a distributed printing service. The full set of IPP documents includes:
Internet Printing Protocol/1.0: Requirements
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema
This document is the directory schema document.
Table of Contents
Introduction
The Internet Printing Protocol (IPP) is an application level protocol that can be used for distributed printing on the Internet. The protocol is heavily influenced by the printing model introduced in the Document Printing Application (ISO/IEC 10175 DPA) standard. Although DPA identifies the both end user and administrative features, the first version of IPP is focused only on the end user Internet printing functionality.
Section 2 is a brief review of the IPP model. The notion of an IPP Printer object is introduced. A description of how Printer objects are named and instantiated is presented.
Section 3 shows the relationship between IPP and the purpose and role(s) of a directory service.
Section 4 introduces the generic schema for entires in a directory which represent IPP Printer objects.
Section 5 begins the process of mapping the generic schema introduced in Section 4 onto real instances of directory service languages, interfaces, and protocols. The first such mapping is done using LDAP.
Sections 6-8 cover security, technical references, and author contact information.
This specification uses the verbs: "shall", "should", "may", and "need not" to specify conformance requirements as follows:
"shall": indicates an action that the subject of the sentence must implement in order to claim conformance to this specification
"may": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification, in other words that action is an implementation option
"need not": indicates an action that the subject of the sentence does not have to implement in order to claim conformance to this specification. The verb "need not" is used instead of "may not", since "may not" sounds like a prohibition.
"should": indicates an action that is recommended for the subject of the sentence to implement, but is not required, in order to claim conformance to this specification.
IPP Model
The IPP model defines several new objects. These are:
Printer
Job
Document
A Printer is an abstraction of a back end printing service with can eventually print a job at some output device. An instance of a Printer object can represent a network attached output device with printing software and hardware embedded directly within the device or print server software sitting in front of a single output device or even a set of output devices. In either case, the IPP Printer object is a simplified abstraction of often more complex back end services and components. The IPP Printer object represents to the end user specific, identifiable, named location for "printing". The output device abstracted by the IPP printer object could be any device (logical or physical) capable of producing a document: a printer, a fax machine, an imager, etc. Print jobs are submitted to Printers where Job objects are created to represent the requirements and status of the submitted print job. Each Job can contain one or more Document objects. Each Document in a Job is either the real content of the document (a file or a stream of print data) or a reference to the real content. Query operations may be performed on Printer and Job objects to get current status, capabilities, and characteristics.
Each instance of a Printer object is uniquely identified with an URL. The proposal from the Protocol team is to use an HTTP scheme URL. For example, a URL for a Printer object named "printer-1" whose network node's domain name is "some.domain.com", might look like:
http://some.domain.com/printer-1
In this case, the URL identifies the use of the HTTP protocol. The Printer is located at the node identified by the DNS name "some.domain.com" and "printer-1" is the name of the Printer.
Another example is the following URL:
http://1.2.3.4:nnn/printer-2
In this case, the URL identifies the use of the HTTP protocol. The Printer is located at the node identified by the IP address of "1.2.3.4" using port nnn for the HTTP server, and "printer-2" is the name of the Printer.
Instances of Printer Objects
Each instance of Printer object has a set of attributes which describe the status and characteristics for that Printer. These attribute values include information about the default value to use for Jobs which do not explicitly define certain attribute values. This means that when a Printer receives a Print Request, if the Print Request does not supply all attribute values which are needed to create the corresponding Job objet, the Printer then uses the default attribute values associated with the Printer. This means that an Administrator could define two or more Printer object instances for the same output device. Also, each instance of a Printer object could have different default values set for certain attributes. If a job is submitted to one of those Printer objects, then the Job that is created would have the corresponding set of default values applied. However, if a job were sent to another of those Printer objects, a different set of default values (the set corresponding with this other Printer object) would be applied when the Job object is created.
For example, an Administrator might define two Printer object instances and give each one of these two URLS:
1) http://some.domain.com/two-sided-printer, and
2) http://some.domain.com/draft-printer
These are two different Printers, and they might even appear to then end user to be two different output devices, however they are not.
Directory Services
What is the relationship between Internet Printing Protocol (IPP) and a Directory Service?
A Directory Service is a means by which service users can find and locate service providers. The directory contains entries for each type of object within the system: entries for users, file systems, servers, applications, printers, other devices, etc. User use the locate objects based on naming and organizational contexts. For example, find all servers in the "Local Department" context. Authentication and authorization are also often part of a directory service. Users are only allowed to find object to which they have certain access rights. Each service providers registers with the directory (either automatically or with the help of an administrator) as an entry of a certain type. For example, the networked printer is registered in the directory as a Printer object with certain registration attributes (name, address, mode, static characteristics, etc.). Given this type of interaction for both service providers and service users provided by the directory service, it is possible for end users to find an locate the exact instance of a printer that they wish to use.
IPP is the protocol used to interact with the object once the object has been found and located using the directory. It is end user access access protocol for print service provider abstracted out as an IPP object.
The IPP does not require any specific directory service instance. However, this specification does define a generic schema that can be used while mapping to a specific instance of a directory service. This generic schema is defined as a set of attributes that are derived from the set of attributes defined for the Printer object in the Internet Printing Protocol/1.0: Model and Semantics document.
In the next section, this document calls out some of the attributes from the Printer object that are then part of the schema for the Directory entry representing an IPP printer. This allows directory users to find and locate IPP Printers by either a simple name look up or by some filtered attribute search.
Directory Entry Schema
The following attributes define the generic directory entry schema. All directories entries for IPP Printers in all types of directories should support at least these attributes.
Issue: The use of "objective" attributes vs. "subjective" attributes still needs to be resolved. For example, for Maximum Print Quality is it better to have values like "high", "medium", "low" or to have explicit, quantified, measurable values? Some of the issues are: end users don't often know what explicit objective values are or what they really mean and they want to depend on an administrator to define what is "high" quality printing and what is "low" quality, especially since today's objective values that equate to "high" are tomorrow's objective values that equate to "medium". On the other hand, some end users demand the control and power explicit values can give them when they do filtered searching. For example, they know and appreciate the difference between 20 ppm printers and 23 ppm printers.
Issue: We must specify which attributes are "mandatory" and which are "optional". LDAP uses the terms "must" and "may" to identify attributes that "must" appear and attributes that "may" appear in a given entry in the directory.
Name
This directory attribute is the printers name. It is a URL so it contains sufficient information to not only name, but to address the printer using IPP as well.
Description
This directory attribute is a free form string that can contain any site-specific descriptive information about this printer.
Location
This directory attribute is a free form string that can contain any site specific location information.
In order for filtered searches to be more effective, a given site may use some regular structuring within the string values such as "SITE:USA-San Jose,BUILDING:A1,FLOOR:2,ROOM:555" or "department5-2ndFloor-A5-IndianHills-Chicago-IL-USA".
Maximum Print Quality
This directory attribute indicates a somewhat subjective evaluation of the overall printing quality. The syntax and values shall be the same as for the print-quality Job attribute.
Cost
This directory attribute indicates a somewhat subjective evaluation of the overall cost of printing at this printer: "high", "medium", or "low".
Resolution
This directory attribute is the maximum resolution of the Printer in dpi.
The syntax and semantics shall be the same as for the printer-resolution-select job attribute.
Color Supported
This directory attribute specifies whether the Printer supports color and, if so, what type. The values are a type2Enum (see section 6). Standard values are: "none", "highlight", "three color (CMY)", "four color (CMYK)", "monochromatic".
Fonts Supported
This directory attribute takes on a list of fonts that are supported by the printer. The syntax and values shall be the same as for the fonts-used job attribute..
Maximum Speed
This directory attribute is the maximum speed of the printer ppm, ipm, spm, lpm, or cps. The syntax and values shall be the same as for the maximum-printer-speed Printer attribute.
Device Id
This directory attribute can be used for automatic driver download, database access, or other automatic configuration tasks. It might be used to generate a platform specific id such as the Windows Plug-and-Play id.
Issue: Is this the IEEE 1284-1994 device id, the Object Identifier as used in the Host Resource MIB hrDeviceId object, or some other identifier?
Make and Model
This directory attribute is a simple text string defined by the manufacturer that contains some reference to the make and model of the entity being represented to the end-user by this Printer object. The syntax shall be:
vendor-name "/" model-name
where the vendor-name is the same as that registered with IANA for use in domain names.
For example: "vendor-x/super-duper-printer".
Marker Type
This directory attribute is the printing mechanism of the print device: electrophotographic-laser, inkjet-aqueous, thermal-transfer, etc. The syntax and values shall be the same as for the printer-types Printer attribute, except the value of the Marker Type directory attribute shall be single-valued
Document Formats Supported
This directory attribute is a list of all of the document formats that the printer and/or its interpreter(s) support. The syntax and values shall be the same as for the document-format Job attribute.
Sides Supported
This directory attribute specifies the capabilities of the Printer for marking on sides of the medium. The syntax and values shall be the same as the sides Job attribute.
Finishings Supported
This directory attribute identifies the finishing operations supported by the Printer. The syntax and values shall be the same as the finishing job attribute.
Directory Schema Implementations
This section covers the mapping between the generic schema and attributes described in Section 4 to real directory service implementation languages.
LDAP
This section describes how take the generic schema as described in section 4 and map it to a real implementation of an LDAP Server using the Lightweight Directory Access Protocol (LDAP).
The LDAP directory entry includes the name of the entry and the attributes as defined above in section 2. The following is an example of how to define a directory entry for a Printer object using LDAP. It is given to assist the reader's understanding of this specification.
To create a Printer object directory entry using LDAP:
1. An administrator uses a program to create an entry for the Printer object on a directory server that supports LDAP. The administrator defines the Distinguished Name (dn) and the default subjective attributes for the Printer object directory entry.
Issue: Should the administrator also define default objective attributes or wait for the Printer object itself to initialize these attributes?
2. The Printer object invokes the ldap_open API to open a connection to the directory server:
Example: ld=ldap_open ("dir.host.name", LDAP_PORT)
where ld is the connection handle for subsequent LDAP APIs.
3. The Printer object invokes an ldap "bind" API to authenticate with the directory server.
Example: ldap_simple_bind_s (ld, dn, NULL) (which does a simple authentication without a password).
4. The Printer object invokes the ldap_modify or ldap_modify_s API to define the objective attributes for the Printer object entry as identified by its Distinguished Name (dn).
Example: ldap_modify_s (ld, dn, mods) (where mods is a NULL-terminated array of objective attributes and values to add or modify in the directory entry)
5. The Printer object invokes the ldap_unbind API to close the connection to the directory server.
Example: ldap_unbind (ld)
When one or more objective attributes are modified for a Printer object, the Printer object repeats steps 2-5 to update the modified objective attributes in its directory entry.
To locate a Printer object entry using LDAP, a program can use the ldap_search or ldap_search APIs or a user can specify an LDAP URL.
For example, to locate all Printer objects that support duplex, a user can specify URL:
ldap:///dir.host.name???(&(objectClass=printer)
(sides-supported=2-sided-long-edge))
Issue: Is it allowed to filter the search based on the object class itself, in this case the object class of Printer? We need to define this new object class. How do we do this? One proposal is to subclass the device class defined in X.500:
printer OBJECT-CLASS ::= {
SUBCLASS OF {device}
MUST CONTAIN {}
MAY CONTAIN {}
NOTE: There is another Internet-Draft called "Internet Printing Protocol/1.0: Security." That document is being drafted and reviewed in parallel with this document. Before this document can become a formal RFC, any relevant issues from that document will be rolled into this one.
References
[1] Smith, R., Wright, F., Hastings, T., Zilles, S., and Gyllenskog, J., "Printer MIB", RFC 1759, March 1995.
[2] Berners-Lee, T, Fielding, R., and Nielsen, H., "Hypertext Transfer Protocol - HTTP/1.0", RFC 1945, August 1995.
[3] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[4] Postel, J., "Instructions to RFC Authors", RFC 1543, October 1993.
[5] ISO/IEC 10175 Document Printing Application (DPA), Final, June 1996.
[6] Herriot, R. (editor), X/Open A Printing System Interoperability Specification (PSIS), August 1995.
[7] Kirk, M. (editor), POSIX System Administration - Part 4: Printing Interfaces, POSIX 1387.4 D8, 1994.
[8] Borenstein, N., and Freed, N., "MIME (Multi-purpose Internet Mail Extensions) Part One: Mechanism for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September, 1993.
[9] Braden, S., "Requirements for Internet Hosts - Application and Support", RFC 1123, October, 1989,
[10] McLaughlin, L. III, (editor), "Line Printer Daemon Protocol" RFC 1179, August 1990.
[11] Berners-Lee, T., Masinter, L., McCahill, M. , "Uniform Resource Locators (URL)", RFC 1738, December, 1994.
Author's Address
Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-4025
EMail: scott_isaacson@novell.com
Keith Carter
IBM Corporation
???
???
Phone: ???
Fax: ???
Email: debry@vnet.ibm.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription Information: ipp-request@pwg.org
Other Participants:
Carter, Isaacson [Page ]
March 14, 1997, Version 1.1, Expires none
|
