Here is the text from RFC 2910 on backward compatibility. It was
deliberately written so as NOT to REQUIRE something that is NOT in a
standard track document, namely IPP/1.0.
Please read this and see if it is good enough. If it is not, please point
out what would need to be added to a future version of the Implementer's
Guide (since we have to update it for the Interoperability Testing Event 3
(nee BO3) for a couple of issues and last call it again anyway.
9. Interoperability with IPP/1.0 Implementations
It is beyond the scope of this specification to mandate conformance with
previous versions. IPP/1.1 was deliberately designed, however, to make
supporting previous versions easy. It is worth noting that, at the time of
composing this specification (1999), we would expect IPP/1.1 Printer
implementations to:
understand any valid request in the format of IPP/1.0, or 1.1;
respond appropriately with a response containing the same
"version-number" parameter value used by the client in the request.
And we would expect IPP/1.1 clients to:
understand any valid response in the format of IPP/1.0, or 1.1.
9.1 The "version-number" Parameter
The following are rules regarding the "version-number" parameter (see
section 3.3):
1. Clients MUST send requests containing a "version-number" parameter
with a '1.1' value and SHOULD try supplying alternate version numbers if
they receive a 'server-error-version-not-supported' error return in a
response.
2. IPP objects MUST accept requests containing a "version-number"
parameter with a '1.1' value (or reject the request for reasons other than
'server-error-version-not-supported').
3. It is recommended that IPP objects accept any request with the major
version '1' (or reject the request for reasons other than
'server-error-version-not-supported'). See [ipp-mod] "versions"
sub-section.
4. In any case, security MUST NOT be compromised when a client supplies
a lower "version-number" parameter in a request. For example, if an IPP/1.1
conforming Printer object accepts version '1.0' requests and is configured
to enforce Digest Authentication, it MUST do the same for a version '1.0'
request.
9.2 Security and URL Schemes
The following are rules regarding security, the "version-number" parameter,
and the URL scheme supplied in target attributes and responses:
1. When a client supplies a request, the "printer-uri" or "job-uri"
target operation attribute MUST have the same scheme as that indicated in
one of the values of the "printer-uri-supported" Printer attribute.
2. When the server returns the "job-printer-uri" or "job-uri" Job
Description attributes, it SHOULD return the same scheme ('ipp', 'https',
'http', etc.) that the client supplied in the "printer-uri" or "job-uri"
target operation attributes in the Get-Job-Attributes or Get-Jobs request,
rather than the scheme used when the job was created. However, when a
client requests job attributes using the Get-Job-Attributes or Get-Jobs
operations, the jobs and job attributes that the server returns depends on:
(1) the security in effect when the job was created, (2) the security in
effect in the query request, and (3) the security policy in force.
3. It is recommended that if a server registers a non-secure ipp-URL
with a directory service (see [IPP-MOD] "Generic Directory Schema"
Appendix), then it also register an http-URL for interoperability with
IPP/1.0 clients (see section 9).
4. In any case, security MUST NOT be compromised when a client supplies
an 'http' or other non-secure URL scheme in the target "printer-uri" and
"job-uri" operation attributes in a request.
Tom
-----Original Message-----
From: Carl-Uno Manros [mailto:carl@manros.com]
Sent: Tuesday, January 23, 2001 19:17
To: McDonald, Ira; 'Carl Kugler'
Cc: ipp@pwg.org
Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
Guys,
Please note that Section 9 of RFC2910 does discuss backwards compatibility
with IPP/1.0 including some text relating to the HTTP scheme as opposed to
the IPP scheme. Admittedly that text is not vey explicit.
If you like to see more details on the URL subject, my suggestion is to put
it in the Implementer's Guide.
Carl-Uno
> -----Original Message-----
> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of McDonald,
> Ira
> Sent: Tuesday, January 23, 2001 6:52 PM
> To: 'Carl Kugler'; McDonald, Ira
> Cc: ipp@pwg.org
> Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
>
>
> Hi Carl,
>
> I agree that something should be added to the (next,
> not current) version of the IPP Implementors Guide.
>
> I also agree that it's perfectly possible to contact
> in IPP implementation using IPP/1.0 version and an
> 'ipp:' URL (although RFC 2565/2566 are entirely silent
> on this topic, except for the IESG nasty-gram on the
> cover sheets).
>
> Let's beat this issue up on the mailing list. If we
> can get some good concensus, then I'd be delighted to
> treat the issue right in the I-D (future standards track
> RFC) that registers the 'ipp:' URL scheme. According
> to the IETF, this kind of protocol version issue SHOULD
> be addressed right in the same RFC.
>
> Cheers,
> - Ira McDonald, consulting architect at Sharp and Xerox
> High North Inc
>
> -----Original Message-----
> From: Carl Kugler [mailto:kugler@us.ibm.com]
> Sent: Monday, January 22, 2001 4:30 PM
> To: McDonald, Ira
> Cc: ipp@pwg.org
> Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
>
>
>
> Well, then, maybe it should go into the Implementer's Guide or something.
> A lot of these rules for backward compatibility would be non-intuitive to
> me, for one. I've always thought that these backward compatibility rules
> are the hardest part of supporting the "ipp:" scheme.
>
> -Carl
>
>
>
> "McDonald, Ira" <imcdonald@sharplabs.com> on 01/22/2001 04:49:35 PM
>
> To: Carl Kugler/Boulder/IBM@IBMUS, ipp@pwg.org
> cc:
> Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
>
>
>
> Hi Carl,
>
> I was directed to REMOVE discussion of backward
> compatibility with IPP/1.0, because the IETF docs
> (RFC 2565/2566) for IPP/1.0 do not specify the
> use of the 'ipp:' URL scheme (although many
> implementations of IPP/1.0 correctly accept and
> process 'ipp:' URL schemes in clients and servers).
>
> Cheers,
> - Ira McDonald, co-editor of 'ipp:' URL scheme I-D
> High North Inc
>
> -----Original Message-----
> From: Carl Kugler [mailto:kugler@us.ibm.com]
> Sent: Wednesday, January 17, 2001 10:11 AM
> To: ipp@pwg.org
> Subject: RE: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
>
>
> What ever happened to the section about backward compatibility with
> IPP/1.0? It used to be in
>
> ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-scheme-981116.doc
>
>
> -Carl
>
> 1 Compatibility with IPP/1.0
> For compatibility with IPP/1.0, clients and IPP objects (i.e. a server)
> MUST support additional schemes as described in this section:
>
> · If a server receives an IPP/1.0 request, it MUST return an IPP/1.0
> response. That is, it MUST support an http-URL in the target "printer-uri"
> and "job-uri" operation attributes in a request. If the server
> returns any
> of the 3 attributes, "job-uri", "job-printer-uri" or
> "printer-uri-supported" in the response, the value of these
> attributes MUST
> be http-URLs. For security, a server MAY also support https-URLs.
> · When a server returns the printer attribute "printer-uri-supported",
> it MUST return all supported values for an IPP/NV request. For an IPP/1.0
> request, a server MUST NOT return values that are ipp-URLs, i.e. it MUST
> return only the http-URLs and https-URLs.
> · The table below shows the type of URL that a server returns for the
> "job-uri" and "job-printer-uri" job attributes for all operations based on
> how the job was created. The "or" in the table below indicates an
> implementation option.
> |-----------+------------------------------------|
> | Operation | Job created via |
> | attributes| |
> | for a | |
> | request | |
> |-----------+------------------------------------|
> | | ipphttphttps |
> |-----------+------------------------------------|
> | ipp | ippippNo URL returned |
> |-----------+------------------------------------|
> |http | httphttpNo URL returned |
> |-----------+------------------------------------|
> |https | https or httphttps or httphttps |
> |-----------+------------------------------------|
>
>
>
>
>
>
> · If a server registers an ipp-URL with a name service, then it
> MUST also register an http-URL. If a printer supports a secure
> connection using SSL3, then it MUST register an https-URL.
> · An IPP/NV client MUST use an ipp-URL for non-secure printers
> unless it receives a "version not supported" error
> message. Then it
> MUST try to send a request in version 1.0, using the http-URL in
> place of the ipp-URL for the target "job-uri" and "printer-uri"
> operation attributes in the request. For secure printers,
> an IPP/NV
> client must operate as an IPP/1.0 client and use an https-URL. An
> IPP/1.0 client MUST use an http-URL for non-secure printers and an
> https-URL for secure printers.
>
>
>
> --- In ipp@egroups.com, "Hastings, Tom N" <hastings@c...> wrote:
> I've made a .pdf file with line numbers from the .txt I-D and posted
> both of
> them at:
>
> ftp://ftp.pwg.org/pub/pwg/ipp/new_URL/draft-ietf-ipp-url-scheme-00.pdf
> ftp://ftp.pwg.org/pub/pwg/ipp/new_URL/draft-ietf-ipp-url-scheme-00.txt
>
> As usual, send any comments to the DL. This will also be on the
> agenda for
> next week's IPP WG meeting and maybe today's telecon, if callers want
> to
> discuss.
>
> Tom
>
> -----Original Message-----
> From: Internet-Drafts@i... [mailto:Internet-Drafts@i...]
> Sent: Monday, January 15, 2001 03:45
> Cc: ipp@p...
> Subject: IPP> I-D ACTION:draft-ietf-ipp-url-scheme-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Internet Printing Protocol Working
> Group of
> the IETF.
>
> Title : Internet Printing Protocol (IPP): IPP URL
> Scheme
> Author(s) : R. Herriot, I. McDonald
> Filename : draft-ietf-ipp-url-scheme-00.txt
> Pages : 15
> Date : 12-Jan-01
>
> 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@p... mailing list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ipp-url-scheme-00.txt
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-ietf-ipp-url-scheme-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> mailserv@i...
> In the body type:
> "FILE /internet-drafts/draft-ietf-ipp-url-scheme-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility. To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command. To decode the response(s), you will need "munpack"
> or
> a MIME-compliant mail reader. Different MIME-compliant mail
> readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been
> split
> up into multiple messages), so check your local documentation
> on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> --- End forwarded message ---
>
>
>
>
>
>
This archive was generated by hypermail 2b29 : Wed Jan 31 2001 - 21:47:30 EST