Subject: IPP> IPP scheme dilemma

From: Carl-Uno Manros <[email-masked]>
Date: Sun, 12 Jul 1998 15:25:10 PDT

All,

As I will be on the road Monday and Tuesday, I thought I would give you my
view before I take to the road.

It seems that we have narrowed down the IPP scheme discussion to be mainly
about the "user experience". This is a tricky one because it is not really
clear to me who is "right" and who is "wrong" in this debate.

My understanding of the WGs thinking on this is:

- We never had any intension to specifically involve or make IPP dependent
on web browsers (apart from the fact that an IPP URL will most certainly be
found on HTML pages - which does not determine which scheme is used).

- We believed that the "user experience" will initially be a competetive
element among different IPP implementations, after which we might decide
later on whether a standardized behaviour in web browsers or other user
interfaces would be needed.

- We believed further that a user would seldom or never have to actually
see an IPP URL, it would typically be buried somewhere in the IPP client
code, or behind a user friendly name on an HTML page.

- We believed that in the most common case, which is to print from an
application, an IPP printer would look no different to a user than the
proprietary print solution he/she uses today. There could be some
differences in a print manager software, but again user friendly names are
typically used in those for end users.

The Area Director / IESG view seems to be:

- The IPP scheme has to be introduced so that users can distinguish an IPP
printer from any other type of object (by looking at the scheme in the
URL), in directories, web browsers, on HTML pages etc.

- In order to achieve this, it is neccesarry to introduce the IPP scheme,
even if it has different characterists and behaviour than most other
schemes in use today.

It is obvious to me that the IPP WG and the AD/IESG sees the world
differently.

However, according to the IETF rules the IESG is eventually right.

This means that if the WG ever wants to see the IPP specs mature to the
IETF standards track, we will have to accept the world as the IESG views it.

My recommendation is to go along with the official IESG view, when we have
it fully documented, and see where it takes us. 

Remember that in the IETF a Proposed Standard is supposed to be the basis
for prototyping. In the event that such protoyping would show that the IPP
scheme is less than ideal, I assume that the IESG can reverse decisions
that turn out not to work in practise. 

A real life problem though, is that we might see a number of
implementations which do not use the IPP scheme, before such prototyping
has been performed. This will lead to the same situation as with HTTP,
where products came before the standard.

On the subject of how IPP should or should not use proxies, I can only hope
that some people who actually build the things would speak up and tell us
what can and cannot be used. There must be some more experts out there who
can help sort that out. I have no opionion on that matter.

Finally, if we should decide to go along with the IPP scheme, I recommend
to use the scheme name "ipp-http", which better describes the dual naming
of the scheme, and would not use up the name "ipp" for something better
that might show up later.

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 13 Jul 1998 20:34:46 -0400

Carl-Uno,

Thanks for writing this up; it may help me to better articulate my views.

> interfaces would be needed.

I think we share the above two assumptions.   However, even if there 
were a "standard behavior in web browsers" I don't think this would 
be the only way that people identified printers. 

> code, or behind a user friendly name on an HTML page.

In writing about "users" I'm including people like system administrators,
network administrators, and those who write HTML pages.  (The latter 
includes a lot of "normal users" - I never cease to be amazed at how 
many nontechnical people have learned to write HTML.)

I used to be a system administrator, so I sympathize with their needs.
And the current system administrators that I've talked to about this
have felt strongly that it's important for them to have the ipp: vs. 
http: distinction, even if this were less visible to normal users.
A number of the IESG and IAB folks are also involved in administration
or operations at one level or another, so this may explain why they
also feel strongly about this.

> typically used in those for end users.

I wouldn't limit this to only printing from applications, but otherwise
I agree.  I expect that in most environments, "printing to an IPP printer" 
will work much the same as "printing to a network printer" works today.

Today, in Win95 I can do this by going into Control Panel, selecting
Printers, selecting Add Printer, selecting "add Network Printer",
and typing in \\spot.cs.utk.edu\slug, where spot.cs.utk.edu is the 
name of my samba server and slug is the name of one of the printer 
queues on that server.  (samba will gateway CIFS printer requests
to lpd)  Someday I would like to be able to run ipp on my print server 
and in a similar fashion be able to tell Win95 to print to  
ipp://spot.cs.utk.edu/slug

The point, I suppose, is that even ordinary users will be seeing
whatever identifiers are used for printers - at least, if ordinary 
users ever mess around with Control Panel.  Even if there are other
ways for users to discover printers - web pages, SRVLOC, ACAP,
etc, sometimes people will still be typing in the URLs by hand.

> even if it has different characterists and behaviour than most other

I think this is accurate, though IESG would see using "ipp:" as consistent
with the established practice that different services get different URL 
types, rather than a departure from established practice.

Keith

p.s. one more thing - the convention is that the URL type matches the
protocol name.  So if you're going to name the URL ipp-http: I think
you should rename the protocol "Internet Printing Protocol over HTTP"
or some such.  But while I prefer ipp: (or even printer:) as a URL
prefix, I won't object to ipp-http: