and for the submission of such proposals.
23.7.1. Requirements for Registration of Event Notification Delivery
Methods
Registered IPP Event Notification Delivery Methods are expected to
follow a number of requirements described below.
23.7.1.1. Required Characteristics
A Delivery Method Document MUST either (1) contain all of the
semantics of the Delivery Method or (2) contain the IPP Delivery
Method registration requirements and a profile of some other protocol
that in combination is the Delivery Method (e.g., mailto). The
Delivery Method Document (and any documents it requires) MUST define
either (1) a URL for a Push Delivery Method that the meets the
requirements of [RFC2717]. or (2) a keyword for a Pull Delivery
method.
IPP Event Notification Delivery Method Documents MUST meet the
requirements of this document (see sections 9 and 10).
In addition, a Delivery Method Document MUST contain the following
information:
Type of registration: IPP Event Notification Delivery Method
Name of this delivery method:
Proposed URL scheme name of this Push Delivery Method or the
keyword name of this Pull Delivery Method:
Name of proposer:
Address of proposer:
Email address of proposer:
Is this delivery method REQUIRED or OPTIONAL for conformance to
the IPP Event Notification and Subscriptions document:
Is this delivery method defining Machine Consumable and/or Human
Consumable content:
23.7.1.2. Naming Requirements
Exactly one (URL scheme or keyword) name MUST be assigned to each
Delivery Method.
Each assigned name MUST uniquely identify a single Delivery Method.
All Push Delivery Method names MUST conform to the rules for URL
scheme names, according to [RFC2396] and [RFC2717] for schemes in the
IETF tree. All Pull Delivery Method names MUST conform to the rules
for keywords according to [RFC2911].
23.7.1.3. Functionality Requirements
Delivery Methods MUST function as a protocol that is capable of
delivering (push or pull) IPP Event Notifications to Notification
Recipients.
23.7.1.4. Usage and Implementation Requirements
Use of a large number of Delivery Methods may hamper
interoperability. However, the use of a large number of undocumented
and/or unlabeled Delivery Methods hampers interoperability even more.
A Delivery Method should therefore be registered ONLY if it adds
significant functionality that is valuable to a large community, OR
if it documents existing practice in a large community. Note that
Delivery Methods registered for the second reason should be
explicitly marked as being of limited or specialized use and should
only be used with prior bilateral agreement.
23.7.1.5. Publication Requirements
Delivery Method Documents MUST be published in a standards track,
informational, or experimental RFCs.
23.7.2. Registration Procedure
The IPP WG is developing a small number of Delivery Methods which are
intended to be published as standards track RFCs. However, some
parties may wish to register additional Delivery Methods in the
future. This section describes the procedures for these additional
Delivery Methods.
23.7.2.1. Present the proposal to the Community
First the Delivery Method Document MUST be an Internet-Draft with a
target category of standards track, informational, or experimental.
The same MUST be true for any documents that it references.
Deliver the proposed Delivery Method Document proposal to the
"ipp@pwg.org" mailing list. This mailing list has been established
by [RFC2911] for reviewing proposed registrations and discussing
other IPP matters. Proposed Delivery Method Documents are not
formally registered and MUST NOT be used until approved.
The intent of the public posting is to solicit comments and feedback
on the definition and suitability of the Delivery Method and the name
chosen for it over a four week period.
23.7.2.2. Delivery Method Reviewer
The Delivery Method Reviewer is the same person who has been
appointed by the IETF Application Area Director(s) as the IPP
Designated Expert according to [RFC2911] and [IANA-CON]. When the
four week period is over and the IPP Designated Expert is convinced
that consensus has been achieved, the IPP Designated Expert either
approves the request for registration or rejects it. Rejection may
occur because of significant objections raised on the list or
objections raised externally.
Decisions made by the Reviewer must be posted to the ipp@pwg.org
mailing list within 14 days. Decisions made by the Reviewer may be
appealed to the IESG.
23.7.2.3. IANA Registration
Provided that the Delivery Method registration proposal has either
passed review or has been successfully appealed to the IESG, the IANA
will be notified by the delivery method reviewer and asked to
register the Delivery Method and make it available to the community.
23.7.3. Delivery Method Document Registrations
Each Push Delivery Method Document defines a URI scheme. Such a URI
scheme is used in a URI value of the "notification-recipient" (uri)
Subscription Template attribute (see section 5.3.1) and the uriScheme
value of the "notify-schemes-supported" (1setOf uriScheme 5.3.1.1)
Printer attribute(see section ). Rather than creating a separate
section in the IPP Registry for Delivery Methods, Push Delivery
Methods will be registered as an additional value of the "notify-
schemes-supported" Printer attribute. These uriScheme values will be
registered according to the procedures of [RFC2911] section 7.1 for
additional attribute values. Therefore, the IPP Registry entry for a
Push Delivery Method will be of the form:
Attribute
Value Ref. Section
--------------------- -------- -------
notify-schemes-supported (1setOf uriScheme) [RFC3995] 5.3.1.1
<scheme name> RFC xxxx m.n
Each Pull Delivery Method Document defines a keyword method which is
registered as an additional value of the "notify-pull-method" and
"notify-pull-method-supported" Printer attributes. These keyword
values will be registered according to the procedures of [RFC2911]
section 7.1 for additional attribute values. Therefore, the IPP
Registry entry for a Pull Delivery Method will be of the form:
Attribute
Value Ref. Section
--------------------- -------- -------
notify-pull-method (type2 keyword) [RFC3995] 5.3.2
notify-pull-method-supported (1setOf type2 keyword)
[RFC3995] 5.3.2.1
<method keyword name> RFC xxxx m.n
23.7.4. Registration Template
To: ipp@pwg.org
Subject: Registration of a new Delivery Method
Delivery Method name:
(All Push Delivery Method names must be suitable for use as the value
of a URL scheme in the IETF tree and all Pull Delivery Method names
must be suitable IPP keywords according to [RFC2911])
Published specification(s):
(A specification for the Delivery Method must be openly available
that accurately describes what is being registered.)
Person & email address to contact for further information:
24. Internationalization Considerations
This IPP Notification specification continues support for the
internationalization of [RFC2911] of attributes containing text
strings and names. Allowing a Subscribing Client to specify a
different natural language and charset for each Subscription Object
increases the internationalization support.
The Printer MUST be able to localize the content of Human Consumable
Event Notifications and to localize the value of "notify-text"
attribute in Machine Consumable Event Notifications that it delivers
to Notification Recipients. For localization, the Printer MUST use
the value of the "notify-charset" attribute and the "notify-natural-
language" attribute in the Subscription Object supplied by the
Subscribing Client.
25. Security Considerations
Clients submitting Notification requests to the IPP Printer have the
same security issues as submitting an IPP/1.1 print job request (see
[RFC2911] section 3.2.1 and section 8). The same mechanisms used by
IPP/1.1 can therefore be used by the client Notification submission.
Operations that require authentication can use the HTTP
authentication. Operations that require privacy can use the HTTP/TLS
privacy. As with IPP/1.1 Print Job Objects, if there is no security
on Subscription Objects, sequential assignment of subscription-ids
exposes the system to a passive traffic monitoring threat.
25.1. Client access rights
The Subscription Object access control model is the same as the
access control model for Job objects. The client MUST have the
following access rights for the indicated Subscription operations:
1. Create-Job-Subscriptions (see section 11.1.1): A Per-Job
Subscription object is associated with a Job. To create Per-Job
Subscription Objects, the authenticated user (see [RFC2911]
section 8.3) performing this operation MUST (1) be the job owner,
(2) have Operator or Administrator access rights for this Printer
(see [RFC2911] sections 1 and 8.5), or (3) be otherwise authorized
by the Printer’s administrator-configured security policy to
create Per-Job Subscription Objects for the target job.
2. Create-Printer-Subscriptions (see section 11.1.2): A Per-Printer
Subscription object is associated with the Printer. To create
Per-Printer Subscription Objects, the authenticated user (see
[RFC2911] section 8.3) performing this operation MUST (1) have
Operator or Administrator access rights for this Printer (see
[RFC2911] sections 1 and 8.5) or (2) be otherwise authorized by
the Printer’s administrator-configured security policy to create
Per-Printer Subscription Objects for this Printer.
3. Get-Subscription-Attributes (see section 11.2.4): The access
control model for this operation is the same as that of the Get-
Job-Attributes operation (see [RFC2911] section 3.3.4). The
primary difference is that a Get-Subscription-Attributes operation
is directed at a Subscription Object rather than at a Job object,
and a returned attribute group contains Subscription Object
attributes rather than Job object attributes. To query the
specified Subscription Object, the authenticated user (see
[RFC2911] section 8.3) performing this operation MUST (1) be the
Subscription Object owner, (2) have Operator or Administrator
access rights for this Printer (see [RFC2911] sections 1 and 8.5),
or (3) be otherwise authorized by the Printer’s administrator-
configured security policy to query the Subscription Object for
the target job. Furthermore, the Printer’s security policy MAY
limit which attributes are returned, in a manner similar to the
Get-Job-Attributes operation (see [RFC2911] end of section
3.3.4.2).
4. Get-Subscriptions (see section 11.2.5): The access control model
for this operation is the same as that of the Get-Jobs operation
(see [RFC2911] section 3.2.6). The primary difference is that the
operation is directed at Subscription Objects rather than at Job
objects, and the returned attribute groups contain Subscription
Object attributes rather than Job object attributes. To query
Per-Job Subscription Objects of the specified job (client supplied
the "notify-job-id" operation attribute - see section 11.2.5.1.1),
the authenticated user (see [RFC2911] section 8.3) performing this
operation MUST (1) be the Subscription Object owner, (2) have
Operator or Administrator access rights for this Printer (see
[RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
the Printer’s administrator-configured security policy to query
the Subscription Object for the target job. To query Per-Printer
Subscription Objects of the Printer (client omits the "notify-
job-id" operation attribute - see section 11.2.5.1.1), the
authenticated user (see [RFC2911] section 8.3) performing this
operation MUST (1) have Operator or Administrator access rights
for this Printer (see [RFC2911] sections 1 and 8.5), or (2) be
otherwise authorized by the Printer’s administrator-configured
security policy to query Per-Printer Subscription Objects for the
target Printer. Furthermore, the Printer’s security policy MAY
limit which attributes are returned, in a manner similar to the
Get-Job-Attributes operation (see [RFC2911] end of section
3.2.6.2).
5. Renew-Subscriptions (see section 11.2.6): The authenticated user
(see [RFC2911] section 8.3) performing this operation MUST (1) be
the owner of the Per-Printer Subscription Object, (2) have
Operator or Administrator access rights for the Printer (see
[RFC2911] sections 1 and 8.5), or (3) be otherwise authorized by
the Printer’s administrator-configured security policy to renew
Per-Printer Subscription Objects for the target Printer
6. Cancel-Subscription (see section 11.2.7): The authenticated user
(see [RFC2911] section 8.3) performing this operation MUST (1) be
the owner of the Subscription Object, (2) have Operator or
Administrator access rights for the Printer (see [RFC2911]
sections 1 and 8.5), or (3) be otherwise authorized by the
Printer’s administrator-configured security policy to cancel the
target Subscription Object.
The standard security concerns (delivery to the right user, privacy
of content, tamper proof content) apply to each Delivery Method.
Some Delivery Methods are more secure than others. Each Delivery
Method Document MUST discuss its Security Considerations.
25.2. Printer security threats
Notification trap door: If a Printer supports the OPTIONAL "notify-
attributes" Subscription Template attribute (see section 5.3.4) where
the client can request that the Printer return any specified Job,
Printer, and Subscription object attributes, the Printer MUST apply
the same security policy to these requested attributes in the Get-
Notifications request as it does for the Get-Jobs, Get-Job-
Attributes, Get-Printer-Attributes, and Get-Subscription-Attributes
requests.
25.3. Notification Recipient security threats
Unwanted Events Notifications (spam): For any Push Delivery Method,
by far the biggest security concern is the abuse of notification:
delivering unwanted Event Notifications to third parties (i.e.,
spam). The problem is made worse by notification addresses that may
be redistributed to multiple parties. There exist scenarios where
third party notification is used (see Scenario #2 and #3 in
[RFC3997]). Any fully secure solution would require active agreement
of all recipients before delivering anything.
26. Description of the base IPP documents (Informative)
The base set of IPP documents includes:
Design Goals for an Internet Printing Protocol [RFC2567]
Rationale for the Structure and Model and Protocol for the Internet
Printing Protocol [RFC2568]
Internet Printing Protocol/1.1: Model and Semantics [RFC2911]
Internet Printing Protocol/1.1: Encoding and Transport [RFC2910]
Internet Printing Protocol/1.1: Implementer’s Guide [RFC3196]
Mapping between LPD and IPP Protocols [RFC2569]
The "Design Goals for an Internet Printing Protocol" document takes a
broad look at distributed printing functionality, and it enumerates
real-life scenarios that help to clarify the features that need to be
included in a printing protocol for the Internet. It identifies
requirements for three types of users: end users, operators, and
administrators. It calls out a subset of end user requirements that
are satisfied in IPP/1.0 [RFC2566, RFC2565]. A few OPTIONAL operator
operations have been added to IPP/1.1 [RFC2911, RFC2910].
The "Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol" document describes IPP from a high level
view, defines a roadmap for the various documents that form the suite
of IPP specification documents, and gives background and rationale
for the IETF IPP working group’s major decisions.
The "Internet Printing Protocol/1.1: Model and Semantics" document
describes a simplified model with abstract objects, their attributes,
and their operations. The model introduces a Printer and a Job. The
Job supports multiple documents per Job. The model document also
addresses how security, internationalization, and directory issues
are addressed.
The "Internet Printing Protocol/1.1: Encoding and Transport" document
is a formal mapping of the abstract operations and attributes defined
in the model document onto HTTP/1.1 [RFC2616]. It also defines the
encoding rules for a new Internet MIME media type called
"application/ipp". This document also defines the rules for
transporting over HTTP a message body whose Content-Type is
"application/ipp". This document defines the ’ipp’ scheme for
identifying IPP printers and jobs.
The "Internet Printing Protocol/1.1: Implementer’s Guide" document
gives insight and advice to implementers of IPP clients and IPP
objects. It is intended to help them understand IPP/1.1 and some of
the considerations that may assist them in the design of their client
and/or IPP object implementations. For example, a typical order of
processing requests is given, including error checking. Motivation
for some of the specification decisions is also included.
The "Mapping between LPD and IPP Protocols" document gives some
advice to implementers of gateways between IPP and LPD (Line Printer
Daemon) implementations.
27. Contributors
The following people made significant contributions to the design and
review of this specification:
Scott A. Isaacson
Novell, Inc.
122 E 1700 S
Provo, UT 84606
Phone: 801-861-7366
Fax: 801-861-2517
EMail: sisaacson@novell.com
Roger deBry
Utah Valley State College
Orem, UT 84058
Phone: 801-863-8848
EMail: debryro@uvsc.edu
Jay Martin
Underscore Inc.
9 Jacqueline St.
Hudson, NH 03051-5308
Phone: 603-889-7000
Fax: 775-414-0245
EMail: jkm@underscore.com
Michael Shepherd
Xerox Corporation
800 Phillips Road MS 128-51E
Webster, NY 14450
Phone: 716-422-2338
Fax: 716-265-8871
EMail: mshepherd@usa.xerox.com
Ron Bergman
Ricoh Printing Systems America
1757 Tapo Canyon Road
Simi Valley, CA 93063-3394
Phone: 805-578-4421
Fax: 805-578-4001
EMail: ron.bergman@rpsa.ricoh.com
Authors’ Addresses
Robert Herriot
Global Workflow Solutions
706 Colorado Ave.
Palo Alto, CA 94303
Phone: 650-324-4000
EMail: bob@herriot.com
Tom Hastings
Xerox Corporation
701 S Aviation Blvd, ESAE 242
El Segundo, CA 90245
Phone: 310-333-6413
Fax: 310-333-6342
EMail: hastings@cp10.es.xerox.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.