RFC 3997

Internet Printing Protocol (IPP): Requirements for IPP Notifications

📅 published March 2005, from ietf

RFC 3997: Internet Printing Protocol (IPP): Requirements for IPP Notifications 🖨️✨

Okay bestie, let's get into this 💅 RFC 3997 is an Informational doc from March 2005. T. Hastings (editor) from Xerox Corporation wrote it with R. K. deBry from Utah Valley State College and H. Lewis from IBM Corporation 🫶 It's a big team effort. Since it's Informational, it's not a standard. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🎀

Status of This Memo

Okay so this memo is giving info for the Internet community 📚 It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌸

Copyright (C) The Internet Society (2005). 💜

Abstract

This doc is one of a whole family of docs that together describe every part of the Internet Printing Protocol (IPP) 🖨️✨ IPP is an application-level protocol you can use for distributed printing on the Internet, and it has a bunch of moving parts. The main architectural pieces are the Model, the Protocol, and an interface to Directory Services 👑 This particular doc sets out the requirements for notifications, which are an optional part of an IPP Service 🦋

Table of Contents

1.   Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  2
2.   Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  2
3.   Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . .  6
4.   Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 10
5.   Security Considerations for IPP Notifications Requirements. . 12
6.   Internationalization Considerations . . . . . . . . . . . . . 13
7.   IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.   References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References. . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References. . . . . . . . . . . . . . . . . 14
9.   Appendix A: Description of the Base IPP Documents . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 17

1. Introduction

Okay so this doc is one of the family that covers every corner of the Internet Printing Protocol (IPP) 🌈 IPP is an application-level protocol for distributed printing on the Internet. It has multiple parts, but the main architectural components are the Model, the Protocol, and an interface to Directory Services ✨ This doc lays out the requirements for notifications as an optional part of an IPP Service. Check section 10 for a description of the base IPP documents 🧚

The scope of this requirements doc covers functionality used by three kinds of IPP Users: End Users, Print Administrators, and Operators 💅 For the extensions to the Internet Printing Protocol/1.0 (IPP) [RFC2565], [RFC2566], IPP/1.1 [RFC2911], [RFC2910], and future versions, see [RFC3995] 🎀

2. Terminology

We need a set of terms so we can clearly talk about the notification requirements in an IPP System. No confusion allowed 🙈

2.1. Job-Submitting End User

This is a human end user who submits a print job to an IPP Printer 🫶 They may or may not be in the same security domain as the Printer, and they may or may not be geographically near the printer. Not everyone's in the same zip code, bestie 🗺️

2.2. Administrator

A human user who sets policy for the print system and configures it 👑

2.3. Operator

A human user who carries out the policy the Administrator set up, and who handles the day-to-day running of the print system 💼

2.4. Job-Submitting Application

An application (a batch application, for example) acting on behalf of a Job-Submitting End User, which submits a print job to an IPP Printer 🤖 It may or may not be in the same security domain as the Printer, and it may or may not be geographically near the printer 🌸

2.5. Security Domain

For this discussion, a Security Domain is the set of network components that can talk to each other without going through a proxy or firewall 🔥 It can be geographically huge. Think anywhere within example.com 🌍

2.6. IPP Client

This is the software component that sends IPP requests to an IPP Printer object and accepts IPP responses from an IPP Printer 💌

2.7. Job Recipient

A human who is the ultimate consumer of the print job 🎁 Most of the time this is the same person as the Job-Submitting End User, but it doesn't have to be. Say I use IPP to print a document on a printer in a business partner's office. I'm the Job-Submitting End User, and the person I want the document for in my partner's office is the Job Recipient 💖 One of the goals of IPP is to let you print near the Job Recipient, so we'd normally expect that person to be in the same security domain as, and geographically near, the Printer. But that isn't always the case. Say I submit a print job across the Internet to XYZ's print shop. I'm both the Submitting End User and the Job Recipient, but I'm neither near the Printer nor in its security domain 🦋

2.8. Job Recipient Proxy

This is a person acting on behalf of the Job Recipient 🧳 The Job Recipient Proxy physically picks up the printed document from the Printer when the Job Recipient can't. By definition, the Proxy is geographically near the printer and in the same security domain as it 👀 Picture this: I submit a print job from home to be printed on a printer at work. I want my secretary to grab it and put it on my desk. So I'm acting as both a Job-Submitting End User and a Job Recipient, and my secretary is the Job Recipient Proxy 💅✨

2.9. Notification Subscriber

This is a client that asks the IPP Printer to send Event Notifications to one or more Notification Recipients 📬 A Notification Subscriber can be a Job-Submitting End User, or an End User, an Operator, or an Administrator who isn't submitting a job 🌷

2.10. Notification Source

This is the entity that sends Event Notifications 📣

2.11. Notification Recipient

This is the entity that receives IPP Notifications about Job and/or Printer events 💜 A Notification Recipient can be a Job-Submitting End User, a Job-Submitting Application, a Job Recipient, a Job Recipient Proxy, an Operator, an Administrator, and so on, plus their representative, a log file, a usage statistics-gathering application, or other active or passive entities 🍓

2.12. Notification Recipient Agent

This is a program that receives Event Notifications on behalf of the Notification Recipient 🧚 The agent might take some action for the recipient, forward the notification to them by an alternative means (paging them, for example), or queue the notification so the recipient can retrieve it later 📦

2.13. Event

An Event is an occurrence within the printing system, either expected or unexpected, that is a change of state, condition, or configuration of a Job or Printer object ⭐

2.14. Event Notification

When an event happens, an Event Notification is generated that fully describes it: what the event was, where it happened, when it happened, and so on 📝 Event Notifications go to all the Notification Recipients subscribed to that Event, if there are any. The Event Notification is delivered to the Notification Recipient's address using the notification delivery method defined in the subscription 💌 Here's the key bit, though: an Event Notification is sent ONLY if there is a corresponding subscription 🙅‍♀️

2.15. Notification Subscription

A Notification Subscription is a request, made by a Notification Subscriber to the IPP Printer, to send Event Notifications to specified Notification Recipient(s) when an event occurs 🎀

2.16. Notification Attributes

IPP Objects (a print job, for example) that send notifications may have associated attributes 💅 A user may want one or more of these returned along with a particular notification. In general, these can include any attribute associated with the object emitting the notification. Examples include the following:

number-of-intervening jobs
job-k-octets
job-k-octets processed
job impressions
job-impressions-interpreted
job-impressions-completed
impressionsCompletedCurrentCopy (job MIB)
sheetCompletedCopyNumber (job MIB)
sheetsCompletedDocumentNumber (job MIB)
Copies-requested
Copy-type
Output-destination
Job-state-reasons
Job ID
Printer URI
Subscription ID (for job independent subscription)

2.17. Notification Delivery Method (or Delivery Method for Short)

Event Notifications get delivered using a Delivery Method 📮 Email is an example of one 💌

2.18. Immediate Notification

These are notifications sent to the Notification Recipient or their agent in a way that makes them arrive immediately, within the limits of common addressing, routing, network congestion, and quality of service ⚡

2.19. Store-and-Forward Notification

These are notifications that aren't necessarily delivered to Notification Recipients right away. Instead, an intermediate network application queues them for delivery, so the recipient can retrieve them later 📥 Email is an example of a store-and-forward notification delivery method 💜

2.20. Reliable Delivery of Notifications

These are notifications delivered using reliable delivery of packets or character streams, with acknowledgement and retry, so delivery is guaranteed within determinate time limits 🔁 For example, if the Notification Recipient has logged off and gone home for the day, an immediate notification can't be guaranteed, even over a reliable transport, because there's nothing there to catch it 🛌 Guaranteed delivery needs both store-and-forward notification and a reliable transport 🫶

2.21. Notification over Unreliable Transport

Notifications are delivered through the fundamental transport address and routing framework, but no acknowledgement or retry is required 🦋 Any process-to-process communication involved is unconstrained 🌈

2.22. Human-Consumable Notification

These are notifications meant to be consumed by human end users only 🧑‍💻 Email is an example of a Human-Consumable Notification, though it could also contain Machine-Consumable Notification 💅

2.23. Machine-Consumable Notification

These are notifications intended for consumption by a program only, such as an IPP Client 🤖 Machine-Consumable Notifications may not contain human-readable information. Do we need both human and machine? Machine readable is intended for application-to-application only. The Notification Recipient could process the machine-readable Event Notification into a human-readable format 🙈

2.24. Mixed Notification

A mixed notification contains both Human-Consumable and Machine-Consumable information 🌸

3. Scenarios ✨

okay so this section is literally just a bunch of real-life "I need a printer to do a thing" stories, and they're honestly so relatable 💅 each one shows a different way someone might want to be notified about a print job, so let's go through them 🖨️

  1. Sitting in my office, I submit a print job to the printer down the hall. I'm in the same security domain as the printer and, obviously, geographically close. I need to know right away when my print job is done (or if something goes wrong) because the doc I'm working on is urgent 😭 I submit the print job with these attributes:
    • Notification Recipient: Me
    • Notification Events: All
    • Notification Attributes: Job-state-reason
    • Notification Type: Immediate
  2. Working from home, I submit a print job to that same printer. I'm not at work though, so I can't physically grab the file or do anything with it 🏠 it can wait until I get in this afternoon. BUT I want my secretary to grab the output and put it on my desk so it doesn't get lost or misfiled 🫶 I also want a store-and-forward notification sent to my email so when I get to work I can tell if something went wrong with the job. I submit a print job with these attributes:
    • Notification Recipient: My secretary
    • Notification Events: Print complete
    • Notification Type: Immediate
    • Notification Recipient: Me
    • Notification Events: Print complete
    • Notification Attributes: Impressions completed
    • Notification Type: Store and forward
  3. Sitting in my office, I submit a print job for a client at an engineering firm my company works with every day. The firm is in Belgium 🇧🇪 I want my client to know when the job is done so she can pick it up from the printer in her building. It's important that she review it right away and send her comments back to me. I submit the print job with these attributes:
    • Notification Recipient: Client at engineering firm
    • Notification Events: Print complete
    • Notification Type: Immediate
    • Notification Language: French
  4. I'm in a hotel room and I send a print job to a Kinko's store in the town I'm working in, so I can grab a printed report for the meeting I have in the morning 🌸 I'm heading out to dinner right after I submit it, so an immediate notification won't do me much good. I'd rather check in the morning before I drive over to Kinko's to see whether the file got printed. An email notification is totally enough for this. I submit the print job with these attributes:
    • Notification Recipient: Me
    • Notification Events: Print complete
    • Notification Type: Store and forward
  5. I'm printing a big, complicated file and I want some immediate feedback on how the job is going as it prints 🔥 I submit the print job with these attributes:
    • Notification Recipient: Me
    • Notification Type: Immediate
    • Notification Events: All state transitions
    • Notification Attributes: Impression completed
  6. I'm an operator, and keeping the printer running is literally my whole job 👑 I subscribe separately from any job submission so my subscription outlasts any particular job, which is giving stability ✨ I subscribe with these attributes:
    • Notification Recipient: Me
    • Notification Type: Immediate
    • Notification Events: All Printer state transitions
    • Notification Attributes: Printer state, printer state reasons, device powering up, device powering down
  7. I'm a usage statistics gathering application 📊 I subscribe separately from any job submission so my subscription outlasts any particular job. My subscription may persist across power cycles, which is so dependable 🫶 I subscribe with these attributes:
    • Notification Recipient: Me
    • Notification Type: Immediate
    • Notification Events: Job completion
    • Notification Attributes: Impression completed, sheets completed, time submitted, time started, time completed, job owner, job size in octets, etc.
  8. I'm a client application that shows a list of jobs currently queued on a printer 💖 I display job-name, job-state, job-state-reasons, page-count, and intervening-jobs, either for the user's own jobs or for all jobs. The job list window can stay open for a long time, and it needs to reflect the current state of the queue, no cap 🙈 the app only needs a slow poll to recover from any missed notifications. So the event delivery mechanism is what updates the screen with every change, including looking up any attributes that might not be delivered in the Notification itself.
  9. I'm a client application that shows a list of printers 🖨️🌈 For each Printer, I display its current state and configuration. The printer list window can stay open for ages too, so it needs to show the current state of every printer. Again, I only need a slow poll to catch any missed notifications, because the event delivery mechanism updates the screen for all the changes, including querying for attributes that might not be delivered in the Notification.
  10. I'm an IPP Server that controls one or more devices, and for each device I implement an IPP Printer object 🧚 I want to support IPP Notification for every IPP Printer object I implement. Lots of these devices don't support notification (or IPP) at all, so I have to handle the IPP Notification semantics for each IPP Printer object myself, on behalf of the devices each one represents 😭 When I accept an IPP job creation request, I convert it into something the device will accept. In some cases I have to poll the devices so I know their job and device state and any changes, and then I can send IPP Notifications to the subscribed Notification Recipients.
  11. I'm also an IPP Server that controls one or more devices and implements an IPP Printer object for each one 🦋 I want IPP Notification support for every IPP Printer object I implement. These devices all support IPP, including IPP Notification. I'm weighing two design options for supporting IPP Notification on these objects: either (1) forward the notification to the IPP Printers that I alone control and let them send notifications to the intended Notification Recipients without my involvement, or (2) replace the notification submitted with the Job so that I'm the Notification Recipient, and then forward Notifications to the Notification Recipients my clients asked for. Most of the rest of the IPP Job I send to the IPP Printers I control will match what I get from my IPP clients.
  12. I'm an IPP Server that controls one or more devices and implements an IPP Printer object for each one 🎀 I want IPP Notification support for every IPP Printer object I implement. These devices all support IPP, including IPP Notification. These IPP Printers MAY also be controlled by other servers (using IPP or other protocols), so I only want Job events for the jobs I send 💅 I do want Printer events all the time, though, so I can show the proper Printer state to my clients. So I subscribe to these IPP Printers for Printer events with a long-standing subscription, with myself as the Notification Recipient. When I get a Job Creation request, I decide which IPP Printer to send the job to. When I do that, I also add a Job event subscription, with me as the Notification Recipient, to the job's job subscriptions supplied by my clients. This is called "piggybacking" 🍓 These IPP Printers automatically remove their job subscriptions when the job finishes, as they do for all job subscriptions, so I stop getting Job events once my jobs are completed.

4. Requirements ✨

okay so this section is basically the wishlist for the IPP Notification spec 🎀 (the spec itself, not the implementation). These are the things the finished Notification Specification document has to be true about:

  1. It must indicate which of these requirements are REQUIRED and which are OPTIONAL for a conforming implementation to support. See [RFC2911], section 12.1, for the definition of these important conformance terms. 📚
  2. It must be designed so that an IPP Printer can transparently support the IPP Notification semantics by using third-party notification services that exist today or that may be standardized in the future. 🦋
  3. It must define a means for a Job-Submitting End User to specify zero or more Notification Recipients when submitting a print job. A Submitter will not be able to prevent out-of-band subscriptions from authorized persons, such as Operators. 🫶
  4. It must define a means, when specifying a Notification Recipient, for a Notification Subscriber to specify one or more notification events for that Notification Recipient, subject to administrative and security policy restrictions. Any of the following constitute Job or Printer Events for which a Job Submitting End User can specify that notifications be sent: 💌
    • Any standard Printer MIB alert
    • Job Received (transition from Unknown to Pending)
    • Job Started (transition from Pending to Processing)
    • Page Complete (page is stacked)
    • Collated Copy Complete (last sheet of collated copy is stacked)
    • Job Complete (transition from Processing or Processing-stopped to Completed)
    • Job Aborted (transition from Pending, Pending-held, Processing, or Processing-stopped to Aborted)
    • Job Canceled (transition from Pending, Pending-held, Processing, or Processing-held to Canceled)
    • Other job state changes, such as paused, purged
    • Device problems for which the job is destined
    • Job (interpreter) issues
  5. It must define how an End User or Operator subscribes for:
    • any set of Job Events for a specific job, or
    • any set of Printer Events while a specific job is not complete.
  6. It must define how an End User or Operator subscribes for the following without having to submit a Job:
    • Any set of Printer Events for a defined period.
    • Any set of Job Events for all jobs, with no control over which jobs.
  7. It must define how the Notification Subscriber is able to specify either immediate or store-and-forward notification independently for each Notification Recipient. The means may be explicit, or implied by the method of delivery chosen by the Job Submitting End User. 🔥
  8. It must define common delivery methods: e.g., email. 📧
  9. It must define how an IPP Printer validates its ability to deliver an Event by using the specified delivery scheme. If it does not support the specified scheme, or if the specified scheme is invalid for some reason, then the IPP Printer accepts and performs the request anyway and indicates the unsupported attribute values. There is no requirement for the IPP Printer receiving the print request to validate the identity of a Notification Recipient, or the ability of the system to deliver an event to that recipient as requested (for example, if the Notification Recipient is not at work today). 🙈
  10. It must define a class of IPP event notification delivery methods that can flow through corporate firewalls. However, an IPP printer need not test to guarantee delivery of the notification through a firewall before accepting a print job. 🧱
  11. It may define a means to deliver a notification to the submitting client when the delivery of an event notification to a specified Notification Recipient fails. A fallback means of subscribers to determine whether notifications have failed (i.e., polling) may be provided. 🔁
  12. It must define a mechanism for localizing Human-Consumable Notifications by the Notification Source. 🌍
  13. It may define a way to specify whether event delivery requires acknowledgement back to the Notification Source. ✅
  14. There must be a mechanism defined so that job-independent subscriptions do not become stale and do not require human intervention to be removed. However, a subscription must not be deemed stale only if it is unable to deliver an Event Notification, as temporary Notification delivery problems must be tolerated. 🌷
  15. A mechanism must be defined so that an Event Subscriber is able to add an Event Subscription to a Job after the Job has been submitted. 🧚
  16. A mechanism must be defined so that a client is able to cancel an Event Subscription on a job or printer after the job has been submitted. 🗑️
  17. A mechanism must be defined so that a client can obtain the set of current Subscriptions. 👀

5. Security Considerations for IPP Notifications Requirements 🔐

okay this part is SERIOUS bestie 😭 the biggest security worry by far is notification abuse, aka sending unwanted notifications to third parties (basically spam 🗑️). It gets worse when notification addresses can be passed around to lots of people (hello, mailing lists). Some scenarios actually need third-party notification (see scenarios 2 and 3). The fully secure fix would be getting active agreement from every single recipient before anything gets sent out. BUT requirement 9 ("There is no requirement for an IPP Printer receiving the print request to validate the identity of an event recipient") pushes against that. Some systems may choose to just disallow third-party notifications, kind of like the old fax model 📠.

The same security issues show up when Clients send notification requests to the IPP Printer as when they send an IPP/1.1 print job request. So the same mechanisms IPP/1.1 uses can be used for client notification submission too. Operations that need authentication can use HTTP authentication 🔑, and operations that need privacy can use HTTP/TLS privacy 🛡️.

The notification access control model should look a lot like the IPP access control model 💅. Creating a notification subscription is tied to a user. Only the creator or an operator can cancel the subscription. The system may limit listings so they only show items owned by the user. Some subscriptions (for example, ones that last longer than a job) can only be created by privileged users (operators and/or administrators), if that's the authorization policy 👑.

The standard security concerns (delivery to the right user, privacy of content, tamper-proof content) all apply to notification delivery 🎯. IPP should use the security mechanism of whichever delivery method is being used. Some delivery mechanisms are more secure than others, so sensitive notifications should use the delivery method with the strongest security. ⚠️

6. Internationalization Considerations 🌏

The Human-Consumable Notification must be localized to the natural language and charset that the Notification Subscriber specifies, within the choice of natural languages and charsets that the IPP Printer supports. 🗣️

The Machine-Consumable Notification data uses the application/ipp MIME media type. It contains attributes whose text values are required to be in the natural language and charset that the Notification Subscriber specifies, within the choice of natural languages and charsets that the IPP Printer supports. See [RFC2566]. 💜

7. IANA Considerations 🧾

Some notification delivery methods have been registered with IANA for use in URLs. Those will be defined in other documents. 🦋

8. References 📚

8.1. Normative References

  • [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R., and J. Wenn, "Internet Printing Protocol/1.1: Encoding and Transport", RFC 2910, September 2000.
  • [RFC2911] Hastings, T., Herriot, R., deBry, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.1: Model and Semantics", RFC 2911, September 2000.
  • [RFC3995] Herriot, R. and T. Hastings, "Internet Printing Protocol (IPP): Event Notifications and Subscriptions", RFC 3995, March 2005.

8.2. Informative References

  • [RFC2565] Herriot, R., Butler, S., Moore, P., and R. Turner, "Internet Printing Protocol/1.0: Encoding and Transport", RFC 2565, April 1999.
  • [RFC2566] deBry, R., Hastings, T., Herriot, R., Isaacson, S., and P. Powell, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
  • [RFC2567] Wright, F., "Design Goals for an Internet Printing Protocol", RFC 2567, April 1999.
  • [RFC2568] Zilles, S., "Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol", RFC 2568, April 1999.
  • [RFC2569] Herriot, R., Hastings, T., Jacobs, N., and J. Martin, "Mapping between LPD and IPP Protocols", RFC 2569, April 1999.
  • [RFC2639] Hastings, T., Manros, C., Zehler, P., Kugler, C., and H. Holst, "Internet Printing Protocol/1.1: Implementor's Guide", RFC 3196, November 2001.

9. Appendix A: Description of the Base IPP Documents ✨

okay so the base set of IPP documents is this whole lineup 💅

  • 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]

"Design Goals for an Internet Printing Protocol" 🎀 takes a broad look at distributed printing, and it lists real-life scenarios that make it clear which features a printing protocol for the Internet needs. It sets out requirements for three kinds of users: end users, operators, and administrators. It calls out a subset of the end-user requirements that IPP/1.0 [RFC2566], [RFC2565] already satisfies. A few OPTIONAL operator operations were added in IPP/1.1 [RFC2911], [RFC2910], and that's the glow-up ✨

"Rationale for the Structure and Model and Protocol for the Internet Printing Protocol" 🦋 describes IPP from a high-level view. It maps out a roadmap for the many documents that make up the IPP specification suite, and it gives the background and reasoning behind the IETF IPP working group's biggest decisions. Main character energy for the planning doc 👑

"Internet Printing Protocol/1.1: Model and Semantics" 🌸 gives a simplified model with abstract objects, their attributes, and their operations. It introduces a Printer and a Job, and the Job supports multiple documents per Job. This document also covers security, internationalization, and directory issues 🔥

"Internet Printing Protocol/1.1: Encoding and Transport" 💜 is the formal mapping of the abstract operations and attributes from the model document onto HTTP/1.1 [RFC2616]. It also defines the encoding rules for a brand-new Internet MIME media type called "application/ipp". On top of that, it sets the rules for transporting, over HTTP, a message body whose Content-Type is "application/ipp". And it defines the "ipp" scheme for identifying IPP printers and jobs 🧚

"Internet Printing Protocol/1.1: Implementer's Guide" 🫶 is the insider scoop for implementers of IPP clients and IPP objects. It helps them understand IPP/1.1 and the things that can shape how they design their client and/or IPP object implementations. For example, it gives a typical order for processing requests, including error checking. It also shares the motivation behind some of the specification decisions, so you get the why, not just the what 🍓

"Mapping between LPD and IPP Protocols" 🌈 gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon ) implementations. Bridging two protocols? Iconic behavior 💅

Authors' Addresses 📇

Tom Hastings (editor)
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


Roger deBry
Utah Valley State College

Phone: (801) 863-8848
EMail: debryro@uvsc.edu


Harry Lewis
IBM Corporation
6300 Diagonal Hwy
Boulder, CO 80301

Phone: (303) 924-5337
EMail: harryl@us.ibm.com

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. It also doesn't 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. 💖

📦 where this page comes from