One document matched: draft-ietf-ipp-dir-schema-00.txt
INTERNET-DRAFT
K. Carter
IBM
S. Isaacson
Novell, Inc.
March 26, 1997
Internet Printing Protocol/1.0: Directory Schema
draft-ietf-ipp-dir-schema-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 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:
Carter, Isaacson [Page 1]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
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.
Carter, Isaacson [Page 2]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
Table of Contents
1. Introduction 4
2. IPP Model 5
2.1 Naming of Printer Objects 5
2.2 Instances of Printer Objects 6
3. Directory Services 7
4. Directory Entry Schema 8
4.1 Name 8
4.2 Description 8
4.3 Location 8
4.4 Maximum Print Quality 9
4.5 Resolution 9
4.6 Color Supported 9
4.7 Fonts Supported 9
4.8 Maximum Speed 9
4.9 Device Id 9
4.10 Make and Model 10
4.11 Document Formats Supported 10
4.12 Sides Supported 10
4.13 Finishings Supported 10
4.14 Media Supported 10
5. Directory Schema Implementations 11
5.1 LDAP 11
6. Security Considerations 12
7. References 13
8. Author's Address 13
Carter, Isaacson [Page 3]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
1. 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 entries 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.
Carter, Isaacson [Page 4]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
- "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.
2. 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.
2.1 Naming of Printer Objects
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
Carter, Isaacson [Page 5]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
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.
2.2 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.
Carter, Isaacson [Page 6]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
3. 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 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.
Carter, Isaacson [Page 7]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
4. 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.
4.1 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.
4.2 Description
This directory attribute is a free form string that can
contain any site-specific descriptive information about
this printer.
4.3 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
Carter, Isaacson [Page 8]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
string values such as "SITE:USA-San
Jose,BUILDING:A1,FLOOR:2,ROOM:555" or "department5-
2ndFloor-A5-IndianHills-Chicago-IL-USA".
4.4 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.
4.5 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.
4.6 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".
4.7 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..
4.8 Maximum Speed
This directory attribute is the maximum speed of the
printer. The value of this attribute can be suffixed
with ppm, ipm, spm, lpm, or cps (for pages-per-minute,
images-per-minute, lines-per-minute, or characters-per-
second respectively). The syntax and values shall be the
same as for the maximum-printer-speed Printer attribute.
4.9 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
Carter, Isaacson [Page 9]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
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? Is this just a URL
referencing the location of a printer driver installer?
4.10 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".
4.11 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.
4.12 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.
4.13 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.
4.14 Media Supported
This directory attribute identifies the media supported
by the Printer. The syntax and values shall be the same
as the media Printer attribute, however, this directory
attribute is should only be updated with values that are
Carter, Isaacson [Page 10]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
relatively static values, not values which are constantly
being updated by the Printer.
ISSUE: Is an extension mechanism needed?
5. Directory Schema Implementations
This section covers the mapping between the generic
schema and attributes described in Section 4 to real
directory service implementation languages.
5.1 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.
Carter, Isaacson [Page 11]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
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 {<list of mandatory attributes>}
MAY CONTAIN {<list of optional attributes>}
6. Security Considerations
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.
Carter, Isaacson [Page 12]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
Before this document can become a formal RFC, any
relevant issues from that document will be rolled into
this one.
7. 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.
8. Author's Address
Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Carter, Isaacson [Page 13]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
INTERNET-DRAFT IPP/1.0: Directory Schema March 26, 1997
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-4025
EMail: scott_isaacson@novell.com
Keith Carter
IBM Corporation
11400 Burnet Road
Internal Zip 9372
Austin, Texas 78758
Phone: (512) 838-2155
Fax: (512) 838-2611
Email: kcarter@vnet.ibm.com
IPP Mailing List: ipp@pwg.org
IPP Mailing List Subscription: ipp-request@pwg.org
IPP Home Page: http://www.pwg.org/ipp/
Other Participants:
Carter, Isaacson [Page 14]
draft-ietf-ipp-dir-schema-00.txt, Expires September 26, 1997
| PAFTECH AB 2003-2026 | 2026-04-24 18:12:29 |