standards/rfc3510.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         R. Herriot
   8 Request for Comments: 3510                                   I. McDonald
   9 Updates: 2910                                            High North Inc.
  10 Category: Standards Track                                     April 2003
  11
  12
  13                     Internet Printing Protocol/1.1:
  14                              IPP URL Scheme
  15
  16 Status of this Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  27
  28 Abstract
  29
  30    This memo defines the "ipp" URL (Uniform Resource Locator) scheme.
  31    This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
  32    expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910.
  33    An "ipp" URL is used to specify the network location of a print
  34    service that supports the IPP Protocol (RFC 2910), or of a network
  35    resource (for example, a print job) managed by such a print service.
  36
  37 Table of Contents
  38
  39    1.  Introduction ...............................................  2
  40    2.  Terminology ................................................  3
  41        2.1.  Conformance Terminology ..............................  3
  42        2.2.  Model Terminology ....................................  3
  43    3.  IPP Model for Printers and Jobs ............................  3
  44    4.  IPP URL Scheme .............................................  4
  45        4.1.  IPP URL Scheme Applicability .........................  4
  46        4.2.  IPP URL Scheme Associated Port .......................  4
  47        4.3.  IPP URL Scheme Associated MIME Type ..................  5
  48        4.4.  IPP URL Scheme Character Encoding ....................  5
  49        4.5.  IPP URL Scheme Syntax ................................  5
  50        4.6.  IPP URL Examples .....................................  6
  51              4.6.1.  IPP Printer URL Examples .....................  6
  52              4.6.2.  IPP Job URL Examples .........................  6
  53        4.7.  IPP URL Comparisons ..................................  7
  54
  55
  56
  57
  58 Herriot & McDonald          Standards Track                     [Page 1]
  59 \f
  60 RFC 3510                     IPP URL Scheme                   April 2003
  61
  62
  63    5.  Conformance Requirements ...................................  8
  64        5.1.  IPP Client Conformance Requirements ..................  8
  65        5.2.  IPP Printer Conformance Requirements .................  8
  66    6.  IANA Considerations ........................................  9
  67    7.  Internationalization Considerations ........................  9
  68    8.  Security Considerations ....................................  9
  69    9.  Intellectual Property Rights ............................... 10
  70    10. Normative References ....................................... 11
  71    11. Informative References ..................................... 11
  72    12. Acknowledgments ............................................ 12
  73    Appendix A - Registration of "ipp" URL Scheme .................. 13
  74    Authors' Addresses ............................................. 15
  75    Full Copyright Statement ....................................... 16
  76
  77 1.  Introduction
  78
  79    This memo conforms to all of the requirements in Registration
  80    Procedures for URL Scheme Names [RFC2717].  This memo also follows
  81    all of the recommendations in Guidelines for new URL Schemes
  82    [RFC2718].
  83
  84    See section 1, "Introduction", of [RFC2911] and section 1,
  85    "Introduction", of [RFC3196] for overview information about IPP.  See
  86    section 10, "Description of the Base IPP Documents", of [RFC3196] for
  87    a full description of the IPP document set.
  88
  89    This memo updates IPP/1.1: Encoding and Transport (RFC 2910), by
  90    expanding and clarifying Section 5, "IPP URL Scheme", of RFC 2910,
  91    but does not define any new parameters or other new extensions to the
  92    syntax of IPP URLs.
  93
  94    The IPP URL scheme defined in this document is based on the ABNF for
  95    the HTTP URL scheme defined in HTTP [RFC2616], which in turn is
  96    derived from the URI Generic Syntax [RFC2396] and further updated for
  97    IPv6 by [RFC2732].  An IPP URL is transformed into an HTTP URL
  98    according to the rules specified in section 5 of IPP Protocol
  99    [RFC2910].
 100
 101    This document defines IPP URL scheme applicability, associated port
 102    (631), associated MIME type ("application/ipp"), character encoding,
 103    and syntax.
 104
 105    This document is laid out as follows:
 106
 107    -  Section 2 defines the terminology used throughout the document.
 108
 109    -  Section 3 supplies references to the IPP Printer and IPP Job
 110       object model defined in IPP Model [RFC2911].
 111
 112
 113
 114 Herriot & McDonald          Standards Track                     [Page 2]
 115 \f
 116 RFC 3510                     IPP URL Scheme                   April 2003
 117
 118
 119    -  Section 4 specifies the IPP URL scheme.
 120
 121    -  Section 5 specifies the conformance requirements for IPP Clients
 122       and IPP Printers that claim conformance to this document.
 123
 124    -  Sections 6, 7, and 8 specify IANA, internationalization, and
 125       security considerations.
 126
 127    -  Sections 9, 10, 11, 12, and 13 specify normative references,
 128       informative references, acknowledgements, authors' addresses, and
 129       full IETF copyright statement.
 130
 131    -  Section 14 (Appendix A) is a completed registration template for
 132       the IPP URL Scheme (see section 6.0 of [RFC2717]).
 133
 134 2.  Terminology
 135
 136       This specification document uses the terminology defined in this
 137       section.
 138
 139 2.1.  Conformance Terminology
 140
 141       The uppercase terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
 142       "SHALL NOT" "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
 143       "OPTIONAL" in this document are to be interpreted as described in
 144       [RFC2119].  These terms are used to specify conformance
 145       requirements for all implementations (both print clients and print
 146       services) of this specification.
 147
 148 2.2.  Model Terminology
 149
 150       See section 12.2, "Model Terminology", in IPP Model [RFC2911].
 151
 152 3.  IPP Model for Printers and Jobs
 153
 154       See section 2, "IPP Objects", section 2.1, "Printer Object", and
 155       section 2.2, "Job Object", in [RFC2911] for a full description of
 156       the IPP object model and terminology.
 157
 158       In this document, "IPP Client" means the software (on some
 159       hardware platform) that submits, monitors, and/or manages print
 160       jobs via the IPP Protocol [RFC2910] to a print spooler, print
 161       gateway, or physical printing device.
 162
 163
 164
 165
 166
 167
 168
 169
 170 Herriot & McDonald          Standards Track                     [Page 3]
 171 \f
 172 RFC 3510                     IPP URL Scheme                   April 2003
 173
 174
 175       In this document, "IPP Printer object" means the software (on some
 176       hardware platform) that receives print jobs and/or printer/job
 177       operations via the IPP Protocol [RFC2910] from an "IPP Client".
 178
 179       In this document, "IPP Printer" is a synonym for "IPP Printer
 180       object".
 181
 182       In this document, "IPP Job object" means the set of attributes and
 183       documents for one print job instantiated on an "IPP Printer".
 184
 185       In this document, "IPP Job" is a synonym for "IPP Job object".
 186
 187       In this document, "IPP URL" means a URL with the "ipp" scheme.
 188
 189       Note:  In this document, "IPP URL" is a synonym for "ipp-URL" (in
 190       section 4, "IPP URL Scheme", of this document) and "ipp-URL" (in
 191       section 5, "IPP URL Scheme", of [RFC2910]).
 192
 193 4.  IPP URL Scheme
 194
 195 4.1.  IPP URL Scheme Applicability
 196
 197       The "ipp" URL scheme MUST only be used to specify absolute URLs
 198       (relative IPP URLs are not allowed) for IPP print services and
 199       their associated network resources.  The "ipp" URL scheme MUST
 200       only be used to specify the use of the abstract protocol defined
 201       in IPP Model [RFC2911] over an HTTP [RFC2616] transport, as
 202       defined in IPP Protocol [RFC2910].  Any other transport binding
 203       for the abstract protocol defined in IPP Model [RFC2911] would
 204       require a different URL scheme.
 205
 206       The "ipp" URL scheme allows an IPP client to choose an appropriate
 207       IPP print service (for example, from a directory).  The IPP client
 208       can establish an HTTP connection to the specified IPP print
 209       service.  The IPP client can send IPP protocol requests (for
 210       example, a "Print-Job" request) and receive IPP protocol responses
 211       over that HTTP connection.
 212
 213 4.2.  IPP URL Scheme Associated Port
 214
 215       All IPP URLs which do NOT explicitly specify a port MUST be
 216       resolved to IANA-assigned well-known port 631, as registered in
 217       [IANA-PORTREG].
 218
 219       See:  IANA Port Numbers Registry [IANA-PORTREG].
 220       See:  IPP Protocol [RFC2910].
 221
 222
 223
 224
 225
 226 Herriot & McDonald          Standards Track                     [Page 4]
 227 \f
 228 RFC 3510                     IPP URL Scheme                   April 2003
 229
 230
 231 4.3.  IPP URL Scheme Associated MIME Type
 232
 233       All IPP URLs MUST be used to specify network print services which
 234       support the "application/ipp" MIME media type as registered in
 235       [IANA-MIMEREG] for IPP protocol requests and responses.
 236
 237       See:  IANA MIME Media Types Registry [IANA-MIMEREG].
 238       See:  IPP Protocol [RFC2910].
 239
 240 4.4.  IPP URL Scheme Character Encoding
 241
 242       IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
 243       URLs.  Characters other than those in the "reserved" and "unsafe"
 244       sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
 245
 246 4.5.  IPP URL Scheme Syntax
 247
 248       The abstract protocol defined in IPP Model [RFC2911] places a
 249       limit of 1023 octets (NOT characters) on the length of a URI (see
 250       section 4.1.5, "uri", in [RFC2911]).
 251
 252       Note:  IPP Printers ought to be cautious about depending on URI
 253       lengths above 255 bytes, because some older client implementations
 254       might not properly support these lengths.
 255
 256    IPP URLs MUST be represented in absolute form.  Absolute URLs MUST
 257    always begin with a scheme name followed by a colon.  For definitive
 258    information on URL syntax and semantics, see "Uniform Resource
 259    Identifiers (URI): Generic Syntax and Semantics" [RFC2396].  This
 260    specification adopts the definitions of "host", "port", "abs_path",
 261    and "query" from [RFC2396], as updated for IPv6 by [RFC2732].
 262
 263    The IPP URL scheme syntax in ABNF is as follows:
 264
 265    ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
 266
 267    If the port is empty or not given, port 631 is assumed.  The
 268    semantics are that the identified resource (see section 5.1.2 of
 269    [RFC2616]) is located at the IPP print service listening for HTTP
 270    connections on that port of that host, and the Request-URI for the
 271    identified resource is 'abs_path'.
 272
 273    If the 'abs_path' is not present in the URL, it MUST be given as "/"
 274    when used as a Request-URI for a resource (see section 5.1.2 of
 275    [RFC2616]).
 276
 277
 278
 279
 280
 281
 282 Herriot & McDonald          Standards Track                     [Page 5]
 283 \f
 284 RFC 3510                     IPP URL Scheme                   April 2003
 285
 286
 287 4.6.  IPP URL Examples
 288
 289    Note:  Literal IPv4 or IPv6 addresses SHOULD NOT be used in IPP URLs.
 290
 291 4.6.1.  IPP Printer URL Examples
 292
 293    The following are examples of well-formed IPP URLs for IPP Printers
 294    (for example, to be used as protocol elements in 'printer-uri'
 295    operation attributes of 'Print-Job' request messages):
 296
 297       ipp://example.com
 298       ipp://example.com/printer
 299       ipp://example.com/printer/tiger
 300       ipp://example.com/printer/fox
 301       ipp://example.com/printer/tiger/bob
 302       ipp://example.com/printer/tiger/ira
 303
 304    Each of the above URLs are well-formed URLs for IPP Printers and each
 305    would reference a logically different IPP Printer, even though some
 306    of those IPP Printers might share the same host system.  The 'bob' or
 307    'ira' last path components might represent two different physical
 308    printer devices, while 'tiger' might represent some grouping of IPP
 309    Printers (for example, a load-balancing spooler).  Or the 'bob' and
 310    'ira' last path components might represent separate human recipients
 311    on the same physical printer device (for example, a physical printer
 312    supporting two job queues).  In either case, both 'bob' and 'ira'
 313    would behave as different and independent IPP Printers.
 314
 315    The following are examples of well-formed IPP URLs for IPP Printers
 316    with (optional) ports and paths:
 317
 318       ipp://example.com
 319       ipp://example.com/~smith/printer
 320       ipp://example.com:631/~smith/printer
 321
 322    The first and second IPP URLs above MUST be resolved to port 631
 323    (IANA assigned well-known port for IPP).  The second and third IPP
 324    URLs above are equivalent (see section 4.7 below).
 325
 326 4.6.2.  IPP Job URL Examples
 327
 328    The following are examples of well-formed IPP URLs for IPP Jobs (for
 329    example, to be used as protocol elements in 'job-uri' attributes of
 330    'Print-Job' response messages):
 331
 332       ipp://example.com/printer/123
 333       ipp://example.com/printer/tiger/job123
 334
 335
 336
 337
 338 Herriot & McDonald          Standards Track                     [Page 6]
 339 \f
 340 RFC 3510                     IPP URL Scheme                   April 2003
 341
 342
 343    IPP Job URLs are valid and meaningful only until Job completion and
 344    possibly an implementation defined optional period of persistence
 345    after Job completion (see IPP Model [RFC2911]).
 346
 347    Ambiguously, section 4.3.1 'job-uri' of IPP Model [RFC2911] states
 348    that:
 349
 350       "the precise format of a Job URI is implementation dependent."
 351
 352    Thus, the relationship between the value of the "printer-uri"
 353    operation attribute used in a 'Print-Job' request and the value of
 354    the "job-uri" attribute returned in the corresponding 'Print-Job'
 355    response is implementation dependent.  Also, section 4.3.3 'job-
 356    printer-uri' of IPP Model [RFC2911] states that the 'job-printer-uri'
 357    attribute of a Job object:
 358
 359       "permits a client to identify the Printer object that created this
 360       Job object when only the Job object's URI is available to the
 361       client."
 362
 363    However, the above statement is false, because the transform from an
 364    IPP Job URL to the corresponding IPP Printer URL is unspecified in
 365    either IPP Model [RFC2911] or IPP Protocol [RFC2910].
 366
 367    IPP Printers that conform to this specification SHOULD only generate
 368    IPP Job URLs (for example, in the "job-uri" attribute in a 'Print-
 369    Job' response) by appending exactly one path component to the
 370    corresponding IPP Printer URL (for interoperability).
 371
 372 4.7.  IPP URL Comparisons
 373
 374    When comparing two IPP URLs to decide if they match or not, an IPP
 375    Client MUST use the same rules as those defined for HTTP URI
 376    comparisons in [RFC2616], with the sole following exception:
 377
 378    -  A port that is empty or not given MUST be treated as equivalent to
 379       the well-known port for that IPP URL (port 631);
 380
 381       See:  Section 3.2.3, "URI Comparison", in [RFC2616].
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Herriot & McDonald          Standards Track                     [Page 7]
 395 \f
 396 RFC 3510                     IPP URL Scheme                   April 2003
 397
 398
 399 5.  Conformance Requirements
 400
 401 5.1.  IPP Client Conformance Requirements
 402
 403       IPP Clients that conform to this specification:
 404
 405    a) MUST only send IPP protocol connections to the port specified in
 406       each given IPP URL (if present) or otherwise to IANA assigned
 407       well-known port 631;
 408
 409    b) MUST only send IPP URLs used as protocol elements in outgoing IPP
 410       protocol request messages (for example, in the "printer-uri"
 411       operation attribute in a 'Print-Job' request) that conform to the
 412       ABNF specified in section 4.5, "IPP URL Scheme Syntax, of this
 413       document;
 414
 415    c) MUST only convert IPP URLs to their corresponding HTTP URL forms
 416       according to the rules in section 5, "IPP URL Scheme", in
 417       [RFC2910].
 418
 419 5.2.  IPP Printer Conformance Requirements
 420
 421    IPP Printers that conform to this specification:
 422
 423    a) MUST listen for incoming IPP protocol connections on IANA-assigned
 424       well-known port 631, unless explicitly configured by system
 425       administrators or site policies;
 426
 427    b) SHOULD NOT listen for incoming IPP protocol connections on any
 428       other port, unless explicitly configured by system administrators
 429       or site policies;
 430
 431    c) SHOULD only accept IPP URLs used as protocol elements in incoming
 432       IPP protocol request messages (for example, in the "printer-uri"
 433       operation attribute in a 'Print-Job' request) that conform to the
 434       ABNF specified in section 4.5, "IPP URL Scheme Syntax", of this
 435       document;
 436
 437    d) SHOULD only send IPP URLs used as protocol elements in outgoing
 438       IPP protocol response messages (for example, in the "job-uri"
 439       attribute in a 'Print-Job' response) that conform to the ABNF
 440       specified in section 4.5, "IPP URL Scheme Syntax", of this
 441       document;
 442
 443    e) SHOULD only generate IPP Job URLs (for example, in the "job-uri"
 444       attribute in a 'Print-Job' response) by appending exactly one path
 445       component to the corresponding IPP Printer URL (for
 446       interoperability);
 447
 448
 449
 450 Herriot & McDonald          Standards Track                     [Page 8]
 451 \f
 452 RFC 3510                     IPP URL Scheme                   April 2003
 453
 454
 455    f) SHOULD NOT use literal IPv6 or IPv4 addresses in configured or
 456       locally generated IPP URLs.
 457
 458 6.  IANA Considerations
 459
 460    This IPP URL Scheme specification does not introduce any additional
 461    IANA considerations, beyond those described in [RFC2910] and
 462    [RFC2911].
 463
 464    See:  Section 6, "IANA Considerations" in [RFC2910]
 465    See:  Section 6, "IANA Considerations" in [RFC2911].
 466
 467 7.  Internationalization Considerations
 468
 469    This IPP URL Scheme specification does not introduce any additional
 470    internationalization considerations, beyond those described in
 471    [RFC2910] and [RFC2911].
 472
 473    See:  Section 7, "Internationalization Considerations", in [RFC2910].
 474    See:  Section 7, "Internationalization Considerations", in [RFC2911].
 475
 476 8.  Security Considerations
 477
 478    This IPP URL Scheme specification does not introduce any additional
 479    security considerations, beyond those described in [RFC2910] and
 480    [RFC2911], except the following:
 481
 482    a) An IPP URL might be faked to point to a rogue IPP print service,
 483       thus collecting confidential document contents from IPP clients.
 484       Server authentication mechanisms and security mechanisms specified
 485       in the IPP Protocol [RFC2910] are sufficient to address this
 486       threat.
 487
 488    b) An IPP URL might be used to access an IPP print service by an
 489       unauthorized IPP client.  Client authentication mechanisms and
 490       security mechanisms specified in the IPP Protocol [RFC2910] are
 491       sufficient to address this threat.
 492
 493    c) An IPP URL might be used to access an IPP print service at a print
 494       protocol application layer gateway (for example, an IPP to LPD
 495       gateway [RFC2569]) causing silent compromise of IPP security
 496       mechanisms.  There is no practical defense against this threat by
 497       a client system.  System administrators should avoid such
 498       compromising configurations.
 499
 500    d) An IPP URL does not have parameters to specify the required client
 501       authentication mechanism (for example, 'certificate' as defined in
 502       section 4.4.2, "uri-authentication-supported", of IPP Model
 503
 504
 505
 506 Herriot & McDonald          Standards Track                     [Page 9]
 507 \f
 508 RFC 3510                     IPP URL Scheme                   April 2003
 509
 510
 511       [RFC2911]) and required security mechanism (for example, 'tls' as
 512       defined in section 4.4.3, "uri-security-supported", of IPP Model
 513       [RFC2911]).  Service discovery or directory protocols might be
 514       used to discover the required client authentication and security
 515       mechanisms associated with given IPP URLs.
 516
 517    Historical Note:  During the development of this document,
 518    consideration was given to the addition of standard IPP URL
 519    parameters for the client authentication and security mechanisms.
 520    However, based on a strong IETF IPP Working Group consensus, no
 521    parameters were added to the "ipp" URL scheme as originally defined
 522    in IPP Protocol [RFC2910] in September 2000, for reasons of backwards
 523    compatibility with the many currently shipping implementations of
 524    IPP/1.1.
 525
 526    See:  Section 8, "Security Considerations", in [RFC2910].
 527    See:  Section 8, "Security Considerations", in [RFC2911].
 528
 529 9.  Intellectual Property Rights
 530
 531    The IETF takes no position regarding the validity or scope of any
 532    intellectual property or other rights that might be claimed to
 533    pertain to the implementation or use of the technology described in
 534    this document or the extent to which any license under such rights
 535    might or might not be available; neither does it represent that it
 536    has made any effort to identify any such rights.  Information on the
 537    IETF's procedures with respect to rights in standards-track and
 538    standards-related documentation can be found in BCP-11.  Copies of
 539    claims of rights made available for publication and any assurances of
 540    licenses to be made available, or the result of an attempt made to
 541    obtain a general license or permission for the use of such
 542    proprietary rights by implementors or users of this specification can
 543    be obtained from the IETF Secretariat.
 544
 545    The IETF invites any interested party to bring to its attention any
 546    copyrights, patents or patent applications, or other proprietary
 547    rights which may cover technology that may be required to practice
 548    this standard.  Please address the information to the IETF Executive
 549    Director.
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Herriot & McDonald          Standards Track                    [Page 10]
 563 \f
 564 RFC 3510                     IPP URL Scheme                   April 2003
 565
 566
 567 10.  Normative References
 568
 569    [RFC2234]      Crocker, D. and  P. Overell, "Augmented BNF for Syntax
 570                   Specifications: ABNF", RFC 2234, November 1997.
 571
 572    [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
 573                   "Uniform Resource Identifiers (URI): Generic Syntax",
 574                   RFC 2396, August 1998.
 575
 576    [RFC2616]      Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
 577                   Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
 578                   Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 579
 580    [RFC2732]      Hinden, R., Carpenter, B. and L. Masinter, "Format for
 581                   Literal IPv6 Addresses in URL's", RFC 2732, December
 582                   1999.
 583
 584    [RFC2910]      Herriot, R., Butler, S., Moore, P., Turner, R. and J.
 585                   Wenn, "IPP/1.1 Encoding and Transport [IPP Protocol]",
 586                   RFC 2910, September 2000.
 587
 588    [RFC2911]      Hastings, T., Herriot, R., deBry, R., Isaacson, S. and
 589                   P. Powell, "IPP/1.1 Model and Semantics [IPP Model]",
 590                   RFC 2911, September 2000.
 591
 592    [US-ASCII]     Coded Character Set -- 7-bit American Standard Code
 593                   for Information Interchange, ANSI X3.4-1986.
 594
 595 11.  Informative References
 596
 597    [IANA-MIMEREG] IANA MIME Media Types Registry.
 598                   ftp://ftp.iana.org/in-notes/iana/assignments/media-
 599                   types/...
 600
 601    [IANA-PORTREG] IANA Port Numbers Registry. ftp://ftp.iana.org/in-
 602                   notes/iana/assignments/port-numbers
 603
 604    [RFC2569]      Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
 605                   "Mapping between LPD and IPP Protocols", RFC 2569,
 606                   April 1999.
 607
 608    [RFC2717]      Petke, R. and I. King, "Registration Procedures for
 609                   URL Scheme Names", RFC 2717, November 1999.
 610
 611    [RFC2718]      Masinter, L., Alvestrand, H., Zigmond, D. and R.
 612                   Petke, "Guidelines for new URL Schemes", RFC 2718,
 613                   November 1999.
 614
 615
 616
 617
 618 Herriot & McDonald          Standards Track                    [Page 11]
 619 \f
 620 RFC 3510                     IPP URL Scheme                   April 2003
 621
 622
 623    [RFC3196]      Hastings, T., Manros, C., Zehler, P., Kugler, C. and
 624                   H. Holst, "Internet Printing Protocol/1.1:
 625                   Implementor's Guide", RFC 3196, November 2001.
 626
 627 12.  Acknowledgments
 628
 629    This document is a product of the Internet Printing Protocol Working
 630    Group of the Internet Engineering Task Force (IETF).
 631
 632    Thanks to Pat Fleming (IBM), Tom Hastings (Xerox), Harry Lewis (IBM),
 633    Hugo Parra (Novell), Don Wright (Lexmark), and all the members of the
 634    IETF IPP WG.
 635
 636    Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910] was the
 637    primary input to this IPP URL Scheme specification.
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Herriot & McDonald          Standards Track                    [Page 12]
 675 \f
 676 RFC 3510                     IPP URL Scheme                   April 2003
 677
 678
 679 Appendix A - Registration of "ipp" URL Scheme
 680
 681    Note:  The following registration obsoletes section 5, "IPP URL
 682    Scheme", of IPP Protocol [RFC2911].
 683
 684    URL Scheme Name:  ipp
 685
 686    URL Scheme Syntax:
 687
 688       ipp-URL = "ipp:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
 689
 690    Character Encoding Considerations:
 691
 692       IPP URLs MUST use [RFC2396] encoding, as do their equivalent HTTP
 693       URLs.  Characters other than those in the "reserved" and "unsafe"
 694       sets [RFC2396] are equivalent to their ""%" HEX HEX" encoding.
 695
 696    Intended Usage:
 697
 698       The intended usage of the "ipp" URL scheme is COMMON.
 699
 700       An "ipp" URL is used to specify the network location of a print
 701       service that supports the IPP Protocol [RFC2910], or of a network
 702       resource (for example, a print job) managed by such a print
 703       service.  An IPP client can choose to establish an HTTP connection
 704       to the specified print service for transmission of IPP protocol
 705       requests (for example, IPP print job submission requests).
 706
 707    Applications or Protocols which use this URL scheme:
 708
 709       See:  Section 5, "IPP URL Scheme", in IPP Protocol [RFC2910].
 710
 711    Interoperability Considerations:
 712
 713       See:  Section 9, "Interoperability with IPP/1.0 Implementations",
 714       in IPP Protocol [RFC2910].
 715
 716    Security Considerations:
 717
 718       See:  Section 8, "Security Considerations", in IPP Protocol
 719       [RFC2910].
 720
 721    Relevant Publications:
 722
 723    [RFC2910] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn,
 724              "IPP/1.1 Encoding and Transport [IPP Protocol]", RFC 2910,
 725              September 2000.
 726
 727
 728
 729
 730 Herriot & McDonald          Standards Track                    [Page 13]
 731 \f
 732 RFC 3510                     IPP URL Scheme                   April 2003
 733
 734
 735    [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
 736              L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
 737              Protocol -- HTTP/1.1", RFC 2616, June 1999.
 738
 739    [RFC3510] Herriot, R. and I. McDonald, "IPP/1.1: IPP URL Scheme", RFC
 740              3510, April 2003.
 741
 742    Person & email address to contact for further information:
 743
 744    Robert Herriot
 745    Consultant
 746    706 Colorado Ave
 747    Palo Alto, CA  94303
 748
 749    Phone: +1 650-327-4466
 750    EMail: bob@herriot.com
 751
 752    Ira McDonald
 753    High North Inc
 754    221 Ridge Ave
 755    Grand Marais, MI  49839
 756
 757    Phone: +1 906-494-2434
 758    EMail: imcdonald@sharplabs.com
 759
 760
 761
 762
 763
 764
 765
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Herriot & McDonald          Standards Track                    [Page 14]
 787 \f
 788 RFC 3510                     IPP URL Scheme                   April 2003
 789
 790
 791 Authors' Addresses
 792
 793    Robert Herriot
 794    Consultant
 795    706 Colorado Ave
 796    Palo Alto, CA  94303
 797
 798    Phone: +1 650-327-4466
 799    EMail: bob@herriot.com
 800
 801
 802    Ira McDonald
 803    High North Inc
 804    221 Ridge Ave
 805    Grand Marais, MI  49839
 806
 807    Phone: +1 906-494-2434
 808    EMail: imcdonald@sharplabs.com
 809
 810    Usage questions and comments on this IPP URL Scheme should be sent
 811    directly to the editors at their above addresses (and to the IPP
 812    mailing list, if you are a subscriber - see below).
 813
 814    IPP Web Page:      http://www.pwg.org/ipp/
 815    IPP Mailing List:  ipp@pwg.org
 816
 817    To subscribe to the IPP mailing list, send the following email:
 818
 819    1) send it to majordomo@pwg.org
 820
 821    2) leave the subject line blank
 822
 823    3) put the following two lines in the message body:  subscribe ipp
 824
 825    Implementers of this specification are encouraged to join the IPP
 826    Mailing List in order to participate in any discussions of
 827    clarification issues and comments.  In order to reduce spam the
 828    mailing list rejects mail from non-subscribers, so you must subscribe
 829    to the mailing list in order to send a question or comment to the IPP
 830    mailing list.
 831
 832
 833
 834
 835
 836
 837
 838
 839
 840
 841
 842 Herriot & McDonald          Standards Track                    [Page 15]
 843 \f
 844 RFC 3510                     IPP URL Scheme                   April 2003
 845
 846
 847 Full Copyright Statement
 848
 849    Copyright (C) The Internet Society (2003).  All Rights Reserved.
 850
 851    This document and translations of it may be copied and furnished to
 852    others, and derivative works that comment on or otherwise explain it
 853    or assist in its implementation may be prepared, copied, published
 854    and distributed, in whole or in part, without restriction of any
 855    kind, provided that the above copyright notice and this paragraph are
 856    included on all such copies and derivative works.  However, this
 857    document itself may not be modified in any way, such as by removing
 858    the copyright notice or references to the Internet Society or other
 859    Internet organizations, except as needed for the purpose of
 860    developing Internet standards in which case the procedures for
 861    copyrights defined in the Internet Standards process must be
 862    followed, or as required to translate it into languages other than
 863    English.
 864
 865    The limited permissions granted above are perpetual and will not be
 866    revoked by the Internet Society or its successors or assigns.
 867
 868    This document and the information contained herein is provided on an
 869    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 870    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 871    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 872    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 873    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 874
 875 Acknowledgement
 876
 877    Funding for the RFC Editor function is currently provided by the
 878    Internet Society.
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892
 893
 894
 895
 896
 897
 898 Herriot & McDonald          Standards Track                    [Page 16]
 899 \f