One of the "major" steps missed was the discussion from the
Wednesday telecon. We discussed the difference between:
1. A network print provider wriitten to this new IPP protocol which is
submitting a job and which desires to get queries and status back using
some well formed protocol like IPP (not arbitrary HTML)
and
2. A Web Browser using a Job URL to query and get an HTML document
back showing status or results of queries.
The question was, do we have to pick on or the other for the IPP
protocol? The discussion in the telecon seemed to indicate that we could
use BOTH. Since there is a huge amount of input suggesting the need
for some well formed protocol (not HTML), we know that we have to do
that at least. The question remains is how to do the HTML response as
well? I don't think anyone is suggesting at this point (at least I have not
heard it outloud) that we should do job canceling via an HTML form that is
filled out and submitted. So in my view, HTML only comes into play when
a standard off the shelf today browser (no new IPP stuff) is being used
for job and printer status and queries. No submission or cancel.
This is not to be confused with the fact that HTML could be a PDL that is
sent to a printer using IPP as a job submission protocol. The job just
happens to be HTML rather than text or some PDL like PostScript.
Scott
>>> Bill Wagner <bwagner at digprod.com> 02/28/97 09:28am >>>
I, and I expect others, seem to have missed a major step here. I would
appreciate some clarification of the perceived relation between IPP
and HTML. "Support" is perhaps too imprecise a term.
1. If, as Randy suggests, HTML is considered as a PDL to be
delivered
to the printer interpreter, then it needs no mention in IPP any more
than any other PDL.
2. If, as Bob's message seems to suggest, HTML is a parallel
implementation to IPP ( "the same information and capabilities via IPP
and HTML"), some clarification of how this is to be done would be
helpful. In addition, the need for two parallel capabilities is
unclear. If IPP is browser oriented, and the browsers must 'support'
HTML, and the desired capabilities can be provided with HTML (???),
then why do IPP?
3. If, as Roger's message suggests, HTML is an optional facility that
may be used by IPP to, perhaps, provide more elegant messages to
the
user, it would seem that a fallback already exists and that HTML
support is optional.
Again, I would appreciate a quick summary of the perceived
relationship between IPP and HTML.
Bill Wagner, Osicom/DPI
______________________________ Reply Separator
_________________________________
Subject: Re: IPP>MOD - HTML and IPP streams
Author: rturner at sharplabs.com at Internet
Date: 2/27/97 1:54 PM
Keep in mind how future implementers are going to read the statement
"A Server must support HTML". We (and some future incarnation of
an IPP WG) are basically going to end up with a core
IPP standards-track RFC, with several other supporting documents,
similar
to:
* RFC XXXX IPP Model, Syntax and Semantics (Core Protocol)
* RFC XXXX IPP over HTTP 1.1 (1 particular mapping)
* RFC XXXX IPP over HTTP 1.0 (another...)
* RFC XXXX IPP over ONC (yet another....)
* RFC XXXX IPP over DCE (ditto)
* RFC XXXX IPP over (Other transports, etc.)
* RFC XXXX IPP Security
* RFC XXXX IPP Commercial Transaction Extensions
.
.
.
Etc.
IMHO, I think the core document should not mandate a particular mapping
or HTML,
an IPP implementation MUST be compliant with
* The core document
AND
* One or more mapping documents
And that should be about it. The way I see it, HTML is just another PDL,
and is
handled by some interpreter module that is outside the scope of IPP. The
only thing that
IPP includes that comes from the HTML world is the requirement that
URLs/URNs/URIs
must be generated and understood by clients and servers.
Just my 0.02 worth
Randy
Robert Herriot wrote:
>> > From rdebry at us.ibm.com Thu Feb 27 09:40:59 1997
> > From: rdebry at us.ibm.com> >
> > ... I'd suggest the following relative to the use of HTML
> > and IPP:
> >
> > A Web Browser must support HTML (pretty obvious)
> >
> > An IPP Client must support IPP, and may optionally support HTML
> >
> > An IPP Server must support IPP and may optionally support HTML.
> >
> > I don't think that we can say that an IPP Server MUST support HTML
in
> > order to be IPP compliant. Actually sounds pretty silly to me to say
that
> > HTML is required to be IPP compliant! I don't think that this is an
> > interoperability issue, is it?
> >
>> Actually, we did say that an IPP server must support IPP AND HTML
because
> if HTML is optional, then a client which expects HTML, must have a
fallback.
> If clients must have a fallback to IPP, then no server need have HTML.
>> I think the primary issue is whether a server gives exactly the same
> information and capabilities via IPP and HTML.
--
Randy Turner
Network Architect
Sharp Laboratories of America
rturner at sharplabs.com