IPP> IPP scheme dilemma

[Carl-Uno Manros <[e-mail]>]

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 [phone], Fax [phone]
Email: [e-mail]