draft-ietf-ipp-url-scheme-02.txt   draft-ietf-ipp-url-scheme-03.txt 
Internet Printing Protocol Working Group Bob Herriot Internet Printing Protocol Working Group Bob Herriot
INTERNET DRAFT Xerox Corporation INTERNET DRAFT Xerox Corporation
Expires 13 August 2001 Ira McDonald Expires 2 October 2001 Ira McDonald
High North Inc High North Inc
[Target Category: Standards Track] 13 February 2001 [Target Category: Standards Track] 2 April 2001
Internet Printing Protocol (IPP): Internet Printing Protocol (IPP):
IPP URL Scheme IPP URL Scheme
<draft-ietf-ipp-url-scheme-02.txt> <draft-ietf-ipp-url-scheme-03.txt>
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at To view the list of Internet-Draft Shadow Directories, see
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a product of the Internet Printing Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ipp@pwg.org mailing list.
This document is intended for use in registering the "ipp" URL scheme This document is intended for use in registering the "ipp" URL scheme
with IANA and fully conforms to the requirements in [RFC-2717]. This with IANA and fully conforms to the requirements in [RFC-2717]. This
document defines the "ipp" URL (Uniform Resource Locator) scheme for document defines the "ipp" URL (Uniform Resource Locator) scheme for
specifying the location of an IPP Printer, IPP Job, or other IPP specifying the location of an IPP Printer, IPP Job, or other IPP
object (defined in some future version of IPP) which implements the object (defined in some future version of IPP) which implements the
IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
[RFC-2910] or any later version of IPP. The intended usage of the [RFC-2910] or any later version of IPP. The intended usage of the
"ipp" URL scheme is COMMON. "ipp" URL scheme is COMMON. The IPP URL scheme defined in this
document is based on the ABNF for the HTTP URL scheme defined in
The IPP URL scheme defined in this document is based on the ABNF for HTTP/1.1 [RFC-2616], which is derived from the URI Generic Syntax
the HTTP URL scheme defined in HTTP/1.1 [RFC-2616], which is derived [RFC-2396] and further updated by [RFC-2732] and [RFC-2373] (for IPv6
from the URI Generic Syntax [RFC-2396] and further updated by addresses in URLs). An IPP URL is transformed into an HTTP URL
[RFC-2732] and [RFC-2373] (for IPv6 addresses in URLs). An IPP URL according to the rules specified in section 5 of the IPP/1.1 Protocol
is transformed into an HTTP URL according to the rules specified in [RFC-2910].
section 5 of the IPP/1.1 Protocol [RFC-2910].
Table of Contents Table of Contents
1. Introduction ............................................... 3 1. Introduction ............................................... 3
2. Terminology ................................................ 4 2. Terminology ................................................ 4
2.1. Conformance Terminology ................................ 4 2.1. Conformance Terminology ................................ 4
2.2. Model Terminology ...................................... 4 2.2. Model Terminology ...................................... 4
3. IPP Model for Printers and Jobs ............................ 4 3. IPP Model for Printers and Jobs ............................ 5
4. IPP URL Scheme ............................................. 6 4. IPP URL Scheme ............................................. 6
4.1. IPP URL Scheme Applicability and Intended Usage ........ 6 4.1. IPP URL Scheme Applicability and Intended Usage ........ 6
4.2. IPP URL Scheme Associated IPP Port ..................... 6 4.2. IPP URL Scheme Associated IPP Port ..................... 6
4.3. IPP URL Scheme Associated MIME Type .................... 6 4.3. IPP URL Scheme Associated MIME Type .................... 6
4.4. IPP URL Scheme Character Encoding ...................... 6 4.4. IPP URL Scheme Character Encoding ...................... 6
4.5. IPP URL Scheme Syntax in ABNF .......................... 7 4.5. IPP URL Scheme Syntax in ABNF .......................... 7
4.5.1. IPP URL Examples ................................... 8 4.5.1. IPP URL Examples ................................... 8
4.5.2. IPP URL Comparisons ................................ 9 4.5.2. IPP URL Comparisons ................................ 9
5. Conformance Requirements ................................... 10 5. Conformance Requirements ................................... 10
5.1. Conformance Requirements for IPP Clients ............... 10 5.1. Conformance Requirements for IPP Clients ............... 10
5.2. Conformance Requirements for IPP Printers .............. 10 5.2. Conformance Requirements for IPP Printers .............. 10
6. IANA Considerations ........................................ 11 6. IANA Considerations ........................................ 11
7. Internationalization Considerations ........................ 11 7. Internationalization Considerations ........................ 11
8. Security Considerations .................................... 11 8. Security Considerations .................................... 11
9. References ................................................. 12 9. References ................................................. 12
10. Acknowledgments ........................................... 13 10. Acknowledgments ........................................... 12
11. Authors' Addresses ........................................ 14 11. Authors' Addresses ........................................ 13
12. Appendix X - Change History ............................... 14 12. Appendix X - Change History ............................... 13
13. Full Copyright Statement .................................. 15 13. Full Copyright Statement .................................. 15
1. Introduction 1. Introduction
See section 1 'Introduction' in [RFC-2911] for a full description of See section 1 'Introduction' in [RFC-2911] for a full description of
the IPP document set and overview information about IPP. the IPP document set and overview information about IPP.
The open issues in this document each begin 'ISSUE_n:'.
This document is a product of the Internet Printing Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ipp@pwg.org mailing list.
This document is intended for use in registering the "ipp" URL scheme This document is intended for use in registering the "ipp" URL scheme
with IANA and fully conforms to the requirements in [RFC-2717]. This with IANA and fully conforms to the requirements in [RFC-2717]. This
document defines the "ipp" URL (Uniform Resource Locator) scheme for document defines the "ipp" URL (Uniform Resource Locator) scheme for
specifying the location of an IPP Printer, IPP Job, or other IPP specifying the location of an IPP Printer, IPP Job, or other IPP
object (defined in some future version of IPP) which implements the object (defined in some future version of IPP) which implements the
IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP IPP/1.1 Model [RFC-2911] and the IPP/1.1 Protocol encoding over HTTP
[RFC-2910] or any later version of IPP. The intended usage of the [RFC-2910] or any later version of IPP. The intended usage of the
"ipp" URL scheme is COMMON. "ipp" URL scheme is COMMON.
This document defines: This document defines:
skipping to change at page 7, line 27 skipping to change at page 7, line 27
[RFC-2910] or any later version of IPP. The intended usage of the [RFC-2910] or any later version of IPP. The intended usage of the
"ipp" URL scheme is COMMON. "ipp" URL scheme is COMMON.
The IPP protocol places a limit of 1023 octets (NOT characters) on The IPP protocol places a limit of 1023 octets (NOT characters) on
the length of a URI (see section 4.1.5 'uri' in [RFC-2911]). An IPP the length of a URI (see section 4.1.5 'uri' in [RFC-2911]). An IPP
Printer MUST return 'client-error-request-value-too-long' (see Printer MUST return 'client-error-request-value-too-long' (see
section 13.1.4.10 in [RFC-2911]) when a URI received in a request section 13.1.4.10 in [RFC-2911]) when a URI received in a request
(e.g., in the "printer-uri" attribute) is too long. (e.g., in the "printer-uri" attribute) is too long.
Note: IPP Printers ought to be cautious about depending on URI Note: IPP Printers ought to be cautious about depending on URI
lengths above 255 bytes, because some older client or proxy lengths above 255 bytes, because some older client implementations
implementations might not properly support these lengths. might not properly support these lengths.
IPP URLs MUST be represented in absolute form. Absolute URLs always IPP URLs MUST be represented in absolute form. Absolute URLs always
begin with a scheme name followed by a colon. For definitive begin with a scheme name followed by a colon. For definitive
information on URL syntax and semantics, see "Uniform Resource information on URL syntax and semantics, see "Uniform Resource
Identifiers (URI): Generic Syntax and Semantics" [RFC-2396]. This Identifiers (URI): Generic Syntax and Semantics" [RFC-2396]. This
specification adopts the definitions of "URI-reference", specification adopts the definitions of "URI-reference",
"absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path",
and "authority" from [RFC-2396], as updated by [RFC-2732] and and "authority" from [RFC-2396], as updated by [RFC-2732] and
[RFC-2373] (for IPv6 addresses in URLs). [RFC-2373] (for IPv6 addresses in URLs).
The IPP URL scheme syntax in ABNF is as follows: The IPP URL scheme syntax in ABNF is as follows:
ipp_URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]] ipp_URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 631 is assumed. The If the port is empty or not given, port 631 is assumed. The
semantics are that the identified resource (see section 5.1.2 of semantics are that the identified resource (see section 5.1.2 of
[RFC-2616]) is located at the IPP Printer or IPP Job listening for [RFC-2616]) is located at the IPP Printer or IPP Job listening for
HTTP connections on that port of that host, and the Request-URI for HTTP connections on that port of that host, and the Request-URI for
the identified resource is 'abs_path'. the identified resource is 'abs_path'.
Note: The use of IP addresses in URLs SHOULD be avoided whenever
possible (see [RFC-1900]).
If the 'abs_path' is not present in the URL, it MUST be given as "/" If the 'abs_path' is not present in the URL, it MUST be given as "/"
when used as a Request-URI for a resource (see section 5.1.2 of when used as a Request-URI for a resource (see section 5.1.2 of
[RFC-2616]). If a proxy receives a host name which is not a fully [RFC-2616]).
qualified domain name, it MAY add its domain to the host name it
received. If a proxy receives a fully qualified domain name, the
proxy MUST NOT change the host name.
4.5.1. IPP URL Examples 4.5.1. IPP URL Examples
The following are examples of valid IPP URLs for IPP Printers: The following are examples of valid IPP URLs for IPP Printers:
ipp://abc.com ipp://abc.com
ipp://abc.com/printer ipp://abc.com/printer
ipp://abc.com/tiger ipp://abc.com/tiger
ipp://abc.com/printers/tiger ipp://abc.com/printers/tiger
ipp://abc.com/printers/fox ipp://abc.com/printers/fox
skipping to change at page 8, line 47 skipping to change at page 8, line 42
paths: paths:
ipp://abc.com ipp://abc.com
ipp://abc.com/~smith/printer ipp://abc.com/~smith/printer
ipp://abc.com:631/~smith/printer ipp://abc.com:631/~smith/printer
The first and second IPP URLs above MUST be resolved to port 631 The first and second IPP URLs above MUST be resolved to port 631
(IANA assigned well-known port for IPP). The second and third IPP (IANA assigned well-known port for IPP). The second and third IPP
URLs above are equivalent (see section 4.5.2 below). URLs above are equivalent (see section 4.5.2 below).
Note: The use of IP addresses in URLs SHOULD be avoided whenever
possible (see [RFC-1900]).
The following literal IPv4 addresses: The following literal IPv4 addresses:
192.9.5.5 ; IPv4 address in IPv4 style 192.9.5.5 ; IPv4 address in IPv4 style
186.7.8.9 ; IPv4 address in IPv4 style 186.7.8.9 ; IPv4 address in IPv4 style
are represented in the following example IPP URLs: are represented in the following example IPP URLs:
ipp://192.9.5.5/prt1 ipp://192.9.5.5/prt1
ipp://186.7.8.9/printers/tiger/bob ipp://186.7.8.9/printers/tiger/bob
skipping to change at page 9, line 28 skipping to change at page 9, line 18
are represented in the following example IPP URLs: are represented in the following example IPP URLs:
ipp://[::192.9.5.5]/prt1 ipp://[::192.9.5.5]/prt1
ipp://[::FFFF:129.144.52.38]:631/printers/tiger ipp://[::FFFF:129.144.52.38]:631/printers/tiger
ipp://[2010:836B:4179::836B:4179]/printers/tiger/bob ipp://[2010:836B:4179::836B:4179]/printers/tiger/bob
4.5.2. IPP URL Comparisons 4.5.2. IPP URL Comparisons
When comparing two IPP URLs to decide if they match or not, an IPP When comparing two IPP URLs to decide if they match or not, an IPP
Client SHOULD use a case-sensitive octet-by-octet comparison of the Client MUST use the same rules as those defined for HTTP URI
entire URLs, with these exceptions: comparisons in [RFC-2616], with the sole following exception:
- A port that is empty or not given is equivalent to the well-known
port for that IPP URL (port 631);
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty 'abs_path' is equivalent to an 'abs_path' of "/".
Characters other than those in the "reserved" and "unsafe" sets (see
[RFC-2396] and [RFC-2732]) are equivalent to their ""%" HEX HEX"
encoding.
For example, the following three URIs are equivalent: - A port that is empty or not given MUST be treated as equivalent to
the well-known port for that IPP URL (port 631);
ipp://abc.com:631/~smith/printer See: Section 3.2.3 'URI Comparison' in [RFC-2616].
ipp://ABC.com/%7Esmith/printer
ipp://ABC.com:/%7esmith/printer
5. Conformance Requirements 5. Conformance Requirements
5.1. Conformance Requirements for IPP Clients 5.1. Conformance Requirements for IPP Clients
IPP Clients that conform to this specification: IPP Clients that conform to this specification:
a) MUST send IPP URLs (e.g., in the "printer-uri" operation attribute a) MUST send IPP URLs (e.g., in the "printer-uri" operation attribute
in 'Print-Job') that conform to the ABNF specified in section 4.5 in 'Print-Job') that conform to the ABNF specified in section 4.5
of this document; of this document;
skipping to change at page 12, line 8 skipping to change at page 12, line 8
This IPP URL Scheme specification does not introduce any additional This IPP URL Scheme specification does not introduce any additional
security considerations, beyond those described in [RFC-2910] and security considerations, beyond those described in [RFC-2910] and
[RFC-2911]. [RFC-2911].
See: Section 8 'Security Considerations' in [RFC-2910]. See: Section 8 'Security Considerations' in [RFC-2910].
See: Section 8 'Security Considerations' in [RFC-2911]. See: Section 8 'Security Considerations' in [RFC-2911].
9. References 9. References
See: Section 10 'References' in [RFC-2910]. See: Section 10 'References' in [RFC-2910].
See: Section 9 'References' in [RFC-2911].
[IANA-CHARREG] IANA Charset Registry.
ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets
[IANA-MIMEREG] IANA MIME Media Types Registry. [IANA-MIMEREG] IANA MIME Media Types Registry.
ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/... ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/...
[IANA-PORTREG] IANA Port Numbers Registry. [IANA-PORTREG] IANA Port Numbers Registry.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers
[NET-SSL3] Netscape. The SSL Protocol, Version 3 (text version
3.02), November 1996.
[RFC-1759] R. Smith, F. Wright, T. Hastings, S. Zilles,
J. Gyllenskog. Printer MIB, RFC 1759, March 1995.
[RFC-1900] B. Carpenter, Y. Rekhter. Renumbering Needs Work, RFC
1900, February 1996.
[RFC-2046] N. Freed, N. Borenstein. MIME Part Two: Media Types, RFC
2046, November 1996.
[RFC-2048] N. Freed, J. Klensin, J. Postel. MIME Part
Four: Registration Procedures, RFC 2048, November 1996.
[RFC-2234] D. Crocker, P. Overell. Augmented BNF for Syntax [RFC-2234] D. Crocker, P. Overell. Augmented BNF for Syntax
Specifications: ABNF, RFC 2234, November 1997. Specifications: ABNF, RFC 2234, November 1997.
[RFC-2373] R. Hinden, S. Deering. IP Version 6 Addressing [RFC-2373] R. Hinden, S. Deering. IP Version 6 Addressing
Architecture, RFC 2373, July 1998. Architecture, RFC 2373, July 1998.
[RFC-2396] T. Berners-Lee, R. Fielding, L. Masinter. Uniform [RFC-2396] T. Berners-Lee, R. Fielding, L. Masinter. Uniform
Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998. Resource Identifiers (URI): Generic Syntax, RFC 2396, August 1998.
[RFC-2246] T. Dierks, C. Allen. The TLS Protocol Version, RFC 2246,
January 1999.
[RFC-2277] H. Alvestrand. IETF Policy on Character Sets and
Languages, RFC 2277, January 1998.
[RFC-2279] F. Yergeau. UTF-8, a Transformation Format of ISO 10646,
RFC 2279, January 1998.
[RFC-2565] R. Herriot, S. Butler, P. Moore, R. Turner. IPP/1.0
Encoding and Transport, RFC 2565, April 1999 (Experimental).
[RFC-2566] R. deBry, T. Hastings, R. Herriot, S. Isaacson, P. Powell.
IPP/1.0 Model and Semantics, RFC 2566, April 1999 (Experimental).
[RFC-2579] K. McCloghrie, D. Perkins, J. Schoenwaelder. Textual
Conventions for SMIv2, RFC 2579, April 1999.
[RFC-2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, [RFC-2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
P. Leach, T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1, P. Leach, T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1,
RFC 2616, June 1999. RFC 2616, June 1999.
[RFC-2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence,
P. Leach, A. Luotonen, L. Stewart. HTTP Authentication: Basic and
Digest Access Authentication, RFC 2617, June 1999.
[RFC-2717] R. Petke, I. King. Registration Procedures for URL Scheme [RFC-2717] R. Petke, I. King. Registration Procedures for URL Scheme
Names, RFC 2717, November 1999. Names, RFC 2717, November 1999.
[RFC-2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke.
Guidelines for new URL Scheme Names, RFC 2718, November 1999.
[RFC-2732] R. Hinden,B. Carpenter, L. Masinter. Format for Literal [RFC-2732] R. Hinden,B. Carpenter, L. Masinter. Format for Literal
IPv6 Addresses in URL's, RFC 2732, December 1999. IPv6 Addresses in URL's, RFC 2732, December 1999.
[RFC-2910] R. Herriot, S. Butler, P. Moore, R. Turner, J. Wenn. [RFC-2910] R. Herriot, S. Butler, P. Moore, R. Turner, J. Wenn.
IPP/1.1 Encoding and Transport, RFC 2910, September 2000. IPP/1.1 Encoding and Transport, RFC 2910, September 2000.
[RFC-2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. Powell. [RFC-2911] T. Hastings, R. Herriot, R. deBry, S. Isaacson, P. Powell.
IPP/1.1 Model and Semantics, RFC 2911, September 2000. IPP/1.1 Model and Semantics, RFC 2911, September 2000.
[RFC-2978] N. Freed, J. Postel. IANA Charset Registration
Procedures, RFC 2978, October 2000.
[RFC-3066] H. Alvestrand. Tags for the Identification of Languages,
RFC 3066, January 2001.
[US-ASCII] Coded Character Set -- 7-bit American Standard Code for [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
10. Acknowledgments 10. Acknowledgments
This document is a product of the Internet Printing Protocol Working This document is a product of the Internet Printing Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should Group of the Internet Engineering Task Force (IETF).
be submitted to the ipp@pwg.org mailing list.
Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM), Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM),
and Hugo Parra (Novell). Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the
IETF IPP WG.
Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport Section 5 'IPP URL Scheme' in IPP/1.1 Encoding and Transport
[RFC-2910] was the primary input to this IPP URL Scheme [RFC-2910] was the primary input to this IPP URL Scheme
specification. specification.
11. Authors' Addresses 11. Authors' Addresses
Robert Herriot Robert Herriot
Xerox Corporation Xerox Corporation
3400 Hill View Ave, Building 1 3400 Hill View Ave, Building 1
skipping to change at page 14, line 27 skipping to change at page 13, line 29
Ira McDonald Ira McDonald
High North Inc High North Inc
221 Ridge Ave 221 Ridge Ave
Grand Marais, MI 49839 Grand Marais, MI 49839
Phone: +1 906-494-2434 Phone: +1 906-494-2434
Email: imcdonald@crt.xerox.com Email: imcdonald@crt.xerox.com
Email: imcdonald@sharplabs.com Email: imcdonald@sharplabs.com
Usage questions and comments on this IPP URL Scheme should be sent to
the IETF IPP WG mailing list at 'ipp@pwg.org'.
12. Appendix X - Change History 12. Appendix X - Change History
[To be deleted before RFC publication] [To be deleted before RFC publication]
2 April 2001 - draft-ietf-ipp-url-scheme-03.txt
- final edits after IETF IPP WG 'last call' comments;
- revised 'Abstract' and section 1 'Introduction' to remove
references to ISSUE's and request for comments to the 'ipp@pwg.org'
mailing list, in preparation for publication as an RFC;
- revised section 4.5 'IPP URL Scheme Syntax in ABNF' to delete all
references to HTTP proxy behavior (which IPP does NOT specify), per
request of Don Wright;
- revised section 4.5.1 'IPP URL Examples' to remove note
discouraging the use of literal IP addresses in URLs, to remove
dependency on Informational [RFC-1900];
- revised section 4.5.2 'IPP URL Comparisons' to specify the use of
rules defined in section 3.2.3 'URI Comparison' in [RFC-2616], with
the sole exception that an empty port MUST be treated as equivalent
to the IPP well-known port 631, per request of Don Wright;
- revised section 9 'References' to delete all unused references;
- revised section 11 'Authors' Addresses' to add the address of the
IPP WG mailing list for usage questions and comments;
13 February 2001 - draft-ietf-ipp-url-scheme-02.txt 13 February 2001 - draft-ietf-ipp-url-scheme-02.txt
- revised section 3 'IPP Model for Printers and Jobs' and section 4.5 - revised section 3 'IPP Model for Printers and Jobs' and section 4.5
'IPP URL Scheme Syntax in ABNF' to add notes stating that "IPP URL" 'IPP URL Scheme Syntax in ABNF' to add notes stating that "IPP URL"
(in this document) is a synonym for "ipp-URL" in [RFC-2910], per (in this document) is a synonym for "ipp-URL" in [RFC-2910], per
request of Bob Herriot; request of Bob Herriot;
- revised section 4.5 'IPP URL Scheme Syntax in ABNF' to correct typo - revised section 4.5 'IPP URL Scheme Syntax in ABNF' to correct typo
that showed "http:" rather than "ipp:" in the one-line ABNF, per that showed "http:" rather than "ipp:" in the one-line ABNF, per
request of Tom Hastings; request of Tom Hastings;
- revised section 4.5.1 'IPP URL Examples' to add a note discouraging - revised section 4.5.1 'IPP URL Examples' to add a note discouraging
the use of literal IP addresses in URLs, per [RFC-2616] and the use of literal IP addresses in URLs, per [RFC-2616] and
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/