Subject: IPP> possible compromise?

From: Keith Moore <[email-masked]>
Date: Sun, 12 Jul 1998 19:47:32 -0400

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

---

From: Robert Herriot <[email-masked]>
Date: Tue, 14 Jul 1998 19:13:30 -0700

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

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Jul 1998 23:43:36 -0400

> of  IPP, most vendors will probably support it for pragmatic reasons. 

This had occurred to me.  What worries me about the idea is that it's
going down the slippery slope toward having http: visible to users.
My experience is that users will see the ipp protocol elements; they 
will not entirely be hidden.  Having them at the HTTP protocol level 
is confusing enough, but it seemed like a reasonable compromise
to make for the sake of code reusability.

As long as the client has to be able to deal with ipp: URLs from
users anyway, I don't see how having ipp: URLs in IPP protocol 
elements places any more hardship on the client.    It seems like
this conversion in the client only needs to be done in one place - 
in the code that interfaces to the HTTP layer.  Everywhere else,
the client should deal with URLs in ipp: format.

As for the use of https: in IPP attributes, I don't think IESG will 
be very sympathetic.  To me at least, the http:/https: distinction
seems insufficient for the purpose at hand, and I suspect that the 
security ADs will agree.  But whatever they decide about http/https, 
I'll defer to their judgement on that one.

> we have been unable to understand what it is.

There is definitely a benefit for clients that have plugins for different
URL types.  A new ipp: URL type can be accomodated with an ipp plugin,
while the behavior for http: is either wired-in, or changing it to support
ipp incurs the possibility of changing the behavior for ordinary http access.
(and it gets worse if there are more than two protocols that want to 
layer over http and use the http URL...whose plugin gets used -- the
ipp+http one or the xyz+http one?)

> receiving portions of the client.

I don't see the partition between sending and receiving portions of
the client.  The partition  I see is between the sending portion
of the client and its http module.  It seems like a clean translation
to me, especially because it only needs to be done in the ipp->http
direction.  What am I missing?

> to warrant a new scheme. 

Some thinking has been done about this.  A draft document that discusses all 
of these is being circulated internally by IESG and IAB, and being commented on.

> 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 

I'm not sure I follow the area code analogy.  To me the new area code
problem is that existing phone numbers have to change. That doesn't
happen when a new URL scheme is introduced, because it's naming new
services that didn't exist in the past.   

The closest analogous problem that comes to mind is where you have a 
service on protocol A named by an A: URL, and you want to offer
the service using (faster, cheaper, better) protocol B for those 
cases that the client also supports B.   This can be done with 
URI resolution techniques that are being worked on, but they're not
yet ready for prime time.  My guess is that the upcoming http-ng
work might well push this along, because nobody wants to change
all of those http: URLs that are out there for the sake of supporting
http-ng.

> someone had required a special fax number instead of a standard phone number.  
I don't think it's a valid analogy.  Faxes benefited from use of voice
lines - in most cases you didn't need a special phone line for faxes.
(and if you had needed a special fax line, the phone companies would
have tried to charge you more money for them.)  But if there had been 
phone lines and fax lines available at the same price, it would have 
been a convenience - not a burden - for phone numbers to look slightly
different than fax numbers.  Nobody would have ever gotten the two confused;
nobody would have ever dialed a wrong number and gotten a fax machine
instead of a voice, or vice versa.  

As it is, ISDN does distinguish voice from fax from data.  The distinction
didn't have to be in the phone number - it's another parameter in call
setup.  That's like saying that we don't require the distinction between
ipp and http to be in the domain name of the server host - it should
be in the URL prefix for consistency with other URLs.

Keith

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 15 Jul 1998 02:05:09 PDT

Robert, Herriot wrote:

# 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.
primarily:
     draft-ietf-urlreg-guide-02.txt

but also:
     RFC 1630 (URI in WWW)
     RFC 1738 (URL)
     draft-fielding-uri-syntax-03.txt
     RFC 2068 (HTTP)

The first document that describes the intent and goals of schemes
was RFC 1630 "Universal Resource Identifiers in WWW". This is an
Informational document, which was then followed by RFC 1738, "Uniform
Resource Locators" Soon after that document was released, there
was a lengthy debate over the issue of the use of the 'gopher:'
URL scheme for implementing the 'finger' protocol, and a belief
that -- even though you could think of 'finger' being a gopher
call on a different port, and restricted to a subset of gopher
syntax -- that it was an inappropriate use, and that finger should
have its own scheme.

After the publication of RFC 1738, a set of guidelines for registration
of new schemes arose in notes on the URI mailing list and
a web page maintained by Harald Alvestraad. Eventually, we formed a
working group (URLREG), which is developing guidelines for new URL schemes;
draft-ietf-urlreg-guide-02.txt is the latest document.  The document is
primarily focused on the converse issue to that at hand in IPP: the problem
of people trying to register schemes that are inappropriate, rather than
that of people trying to use existing schemes inappropriately.

But, for example, section 2.2.5 seems to allude to the fact that the "http"
scheme is mostly used as a mechanism to access a data resource.

In general, if a URL scheme is registered for one purpose, a new standards
track document should not (without review) usurp that scheme for a different
purpose.

# I would like to know how a protocol designer decides if a new service
# is different enough to warrant a new scheme.

There are guidelines, and then there is process. We can write better guidelines,
I hope, but coming up with a deterministic process may be hard.

Giving an effective decision procedure for when new schemes are appropriate
has been a thorny problem for the URL registration group, and the converse
(when is a new scheme REQUIRED) is likely to have the same difficulties.
In the end, it is a matter of judgement. The current process is that the
IESG is the authority for that judgement, and that IESG approval is required
for new registered schemes. One might imagine that the converse would hold:
that IESG judgement is required ultimately to decide on when it is appropriate
to reuse an old scheme for a new purpose.

Larry