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 at us.ibm.com]
Sent: Monday, January 22, 2001 4:30 PM
To: McDonald, Ira
Cc: ipp at 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 at sharplabs.com> on 01/22/2001 04:49:35 PM
To: Carl Kugler/Boulder/IBM at IBMUS, ipp at 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 at us.ibm.com]
Sent: Wednesday, January 17, 2001 10:11 AM
To: ipp at 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 at egroups.com, "Hastings, Tom N" <hastings at 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.pdfftp://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 at i... [mailto:Internet-Drafts at i...]
Sent: Monday, January 15, 2001 03:45
Cc: ipp at 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 at 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 at 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 ---