Thanks for writing this up; it may help me to better articulate my views.
> 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.
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.
> - 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.
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.
> - 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.
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.
> 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.
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: