> >> It seems to me there are few if any clear, overwhelming technical merits
> >> on either side of the proposals. The printing community is firm on how it
> >> believes customers and users will perceive and use IPP and believes
> >> "ipp:" is not the right approach. Since other than encoded within the
> >> application/ipp body, "ipp:" is never on the wire, there is no real
> >> difference from the network's infrastructure
> >
> >That's not true. ipp: would appear "on the wire" in all sorts of
> >places -- in HTML documents, LDAP responses, ACAP responses, etc. --
> >any time someone needs to refer to a printer.
> >
> >Keith
>> Yes, but in all these cases, a human being does not see this raw material.
> It is technically irrelevant whether the responses say "ipp:", "http:", or
> anything else for that matter.
No, that's not true either. People deal with these things all the time.
People explicitly type URLs into web pages, into their directory entries,
etc. People will type printer URLs into dialog boxes and printcap files.
This stuff doesn't just appear out of thin air.
> My argue stands, the right people to deal
> with the user's perception are the people shipping the products and they
> have reach consensus that "ipp:" is the wrong answer.
The folks who are shipping printers aren't even close to representative
of the people who are going to be using this stuff.
> One of the major scenarios this group continues to discuss is what does the
> naive person do with a URL received from another individual? It is a
> common belief among those of us developing products that they will stick
> them in a browser and see what happens. With "ipp:", nothing will happen
> except the browser complaining. We firmly believe that well designed IPP
> servers when presented with a GET operation at its HTTP URL will return
> something of significance and use to the person trying it out.
>> Specifically, we expect the server to return an HTML page that will help
> the user "bootstrap" themselves into being able to print to that printer.
> That scenario is completely broken with the "ipp:" scheme. If we don't do
> our work to enable IPP to work for those who have only minimal experience
> then we have done no one (especially ourselves) a favor.
No, ipp: doesn't prevent that at all. If someone wants to put up a web
page with an http: URL that tells someone how to bootstrap a connection
to their ipp: printer, and if they want to export that http: URL in HTML
documents and directory entries and so forth, they're quite welcome to
do so -- nobody can stop them. The same is true for any printer vendor
that wants to build this functionality into its printers.
But if IPP gets to overload the http: URL, then you're *forcing* the user
to go through such a mechanism, because he has no other way to know that
he's talking to a printer. And you're somehow expecting that in
every case doing a GET on the http: URL is going to return something
reasonable that lets the user configure that printer on his system.
This is putting the functionality in the wrong place, because it
expects that the server knows what the user needs to do. That just
doesn't fly in a heterogeneous world. If you use ipp: the client
will realize that the other end is a printer, and it will (eventually)
know what to do with it.
Keith