After reading the email between Keith Moore and various members of the IPP
working group, I see much agreement, and some remaining points of
disagreement based on Keith's July 12th email "possible compromise?"
(enclosed below).
I will suggest a slightly different compromise.
Keith and the IPP working group are in agreement:
1) Clients send only 'http' schemes in the HTTP Request-Line
2) Servers support the reception only of 'http' schemes in the HTTP
Request-Line
Keith and the IPP working group are in disagreement about:
1) the scheme in the value of IPP attributes, such as "printer-uri".
Keith wants 'ipp'. The IPP working group wants 'http'.
2) the scheme in external notation for printer URL's. Keith wants 'ipp'.
The IPP working group wants 'http'.
The IPP working group wants an 'http' scheme for issue #1 because they
believe it is the cleanest design and avoids the mapping issue for clients
that never expose a URL to a user. We don't understand the virtue of having
an 'ipp' scheme in a block of data that a client must process, but that
neither a user nor networking software ever see. The 'http' choice (with its
lack of mapping) also allows a print server to use an 'https' scheme in an
IPP attribute without any mapping issues. Although 'https' is not a part
of IPP, most vendors will probably support it for pragmatic reasons.
Keith's solution creates a mapping problem for clients while giving no
apparent benefit to the client. If there is a benefit at the client level,
we have been unable to understand what it is.
If, indeed, the 'ipp' scheme is a good idea, I think that Keith's proposal
makes the wrong partitioning of 'ipp' and 'http'. The partitioning should
occur between client and user interface and not between the sending and
receiving portions of the client.
I might support a requirement that users refer to a printer with an 'ipp'
scheme (issue #2), even though such a requirement seems to be beyond a
protocol standard.
But before giving such support, I would like to understand why the IETF
wants a scheme to specify the type of service. I would also like to see an
IETF document that describes the intent and goals of this differentiation of
schemes, as well as the infrastructure needed to support it. I would like
to know how a protocol designer decides if a new service is different enough
to warrant a new scheme. I would like to know if someone has thought about
how to avoid the "new area code" problem as each new scheme is introduced.
Without a such information, I am left wondering if the requirement of a new
scheme for each new service will turn out to be a good idea.
Finally, I wonder how long it would have taken faxes to be deployed if
someone had required a special fax number instead of a standard phone number.
Bob Herriot
At 04:47 PM 7/12/98 , Keith Moore wrote:
>I was thinking about the problem where using ipp: URLs in
>the HTTP POST operation potentially makes IPP incompatible
>with existing servers, and came up with the following possible
>compromise solution. I'm willing to defend this to IESG if
>the IPP group buys into it.
>
>1. use the http: form of the URL in HTTP protocol elements
>
>if you're talking to a proxy, do
>
>POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
>
>if you're talking to an origin server, you should really do
>
>POST /myprinter/myqueue HTTP/1.1
>Host: myhost.com:631
>
>but origin servers are *also* expected to accept
>
>POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
>
>just as in vanilla HTTP 1.1.
>
>This way, the HTTP layer never has to see ipp: at all.
>This should preserve compatibility with HTTP servers
>and HTTP client libraries.
>
>2. use the ipp: form of the URL in IPP protocol elements
>that refer to printer objects
>
>3. define ipp: URLs as a standard external notation for
>referring to printers - and the IPP protocol document describes
>how to take an ipp: URL and generate the appropriate HTTP/1.1
>POST request. Printer clients are expected to be able to
>do this.
>
>That way, the ipp: URL can be used when it's useful to
>expose the fact that the named object is a printer.
>
>The IPP server is free to respond to a GET on the its
>printer URL, and return HTML that describes the printer,
>how to talk to it, etc. And users are free to export
>this URL as an http: URL if they want to do so and
>their printers support it.
>
>But users and clients should be cautioned to not assume
>that the "GET URL" is the same as the "print URL".
>
>Keith
>
--=====================_13432224==_.ALT
Content-Type: text/html; charset="us-ascii"
After reading the email between Keith Moore and various
members of the IPP
--=====================_13432224==_.ALT--
working group, I see much agreement, and some remaining points of
disagreement based on Keith's July 12th email "possible
compromise?"
(enclosed below).
I will suggest a slightly different compromise.
Keith and the IPP working group are in agreement:
1) Clients send only 'http' schemes in the HTTP
Request-Line
2) Servers support the reception only of 'http'
schemes in the HTTP Request-Line
Keith and the IPP working group are in disagreement about:
1) the scheme in the value of IPP attributes,
such as "printer-uri".
Keith wants 'ipp'. The IPP
working group wants 'http'.
2) the scheme in external notation for printer URL's.
Keith wants 'ipp'.
The IPP working group wants
'http'.
The IPP working group wants an 'http' scheme for issue #1 because they
believe it is the cleanest design and avoids the mapping issue for
clients
that never expose a URL to a user. We don't understand the virtue of
having
an 'ipp' scheme in a block of data that a client must process, but that
neither a user nor networking software ever see. The 'http' choice (with
its
lack of mapping) also allows a print server to use an 'https' scheme in
an
IPP attribute without any mapping issues. Although 'https' is
not a part
of IPP, most vendors will probably support it for pragmatic
reasons.
Keith's solution creates a mapping problem for clients while giving no
apparent benefit to the client. If there is a benefit at the
client level,
we have been unable to understand what it is.
If, indeed, the 'ipp' scheme is a good idea, I think that Keith's
proposal
makes the wrong partitioning of 'ipp' and 'http'. The partitioning
should
occur between client and user interface and not between the
sending and
receiving portions of the client.
I might support a requirement that users refer to a printer with an 'ipp'
scheme (issue #2), even though such a requirement seems to be beyond a
protocol standard.
But before giving such support, I would like to understand why the IETF
wants a scheme to specify the type of service. I would also like to
see an
IETF document that describes the intent and goals of this differentiation
of
schemes, as well as the infrastructure needed to support it. I
would like
to know how a protocol designer decides if a new service is different
enough
to warrant a new scheme. I would like to know if someone has thought
about
how to avoid the "new area code" problem as each new scheme is
introduced.
Without a such information, I am left wondering if the requirement of
a new
scheme for each new service will turn out to be a good idea.
Finally, I wonder how long it would have taken faxes to be deployed if
someone had required a special fax number instead of a standard phone
number.
Bob Herriot
At 04:47 PM 7/12/98 , Keith Moore wrote:
>I was thinking about the problem where using ipp: URLs in
>the HTTP POST operation potentially makes IPP incompatible
>with existing servers, and came up with the following possible
>compromise solution. I'm willing to defend this to IESG
if
>the IPP group buys into it.
>
>1. use the http: form of the URL in HTTP protocol elements
>
>if you're talking to a proxy, do
>
>POST
http://myhost.com:631/myprinter/myqueue
HTTP/1.1
>
>if you're talking to an origin server, you should really do
>
>POST /myprinter/myqueue HTTP/1.1
>Host: myhost.com:631
>
>but origin servers are *also* expected to accept
>
>POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
>
>just as in vanilla HTTP 1.1.
>
>This way, the HTTP layer never has to see ipp: at all.
>This should preserve compatibility with HTTP servers
>and HTTP client libraries.
>
>2. use the ipp: form of the URL in IPP protocol elements
>that refer to printer objects
>
>3. define ipp: URLs as a standard external notation for
>referring to printers - and the IPP protocol document describes
>how to take an ipp: URL and generate the appropriate HTTP/1.1
>POST request. Printer clients are expected to be able to
>do this.
>
>That way, the ipp: URL can be used when it's useful to
>expose the fact that the named object is a printer.
>
>The IPP server is free to respond to a GET on the its
>printer URL, and return HTML that describes the printer,
>how to talk to it, etc. And users are free to export
>this URL as an http: URL if they want to do so and
>their printers support it.
>
>But users and clients should be cautioned to not assume
>that the "GET URL" is the same as the "print URL".
>
>Keith
>