Subject: IPP>MOD - HTML and IPP streams

From: [email-masked]
Date: Thu, 27 Feb 1997 12:38:42 -0500

Classification:
Prologue:
Epilogue: Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

Yesterday's conference call was very lively. I appreciate the debate, it helps
me to sort out things
in my own mind.  Based on the updated diagram I have drawn and posted in a
separate note, and
yesterdays discussion, 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?

---

From: [email-masked] (Robert Herriot)
Date: Thu, 27 Feb 1997 15:03:47 -0800

You stated quite well what I think we agreed to.  I would like to be
able to agree with your last statement:

   "After some thought, I would be happy if a server only had to implement
    the HTML binding, both for query and submission."

But the last time I suggested it, others said that HTML would not be
a good representation for a client that needs to get the meaning from it.
Do you have some additional proposals to resolve this issue? Are you
suggesting that HTML tags could hold such information?

On another related issue, would you expect an IPP query could supply the
sort of information that a ppd file supplies, namely the PostScript that
is associated with a particular attribute value?

Bob Herriot

> From [email-masked] Thu Feb 27 14:15:50 1997
> 
> > Date: Thu, 27 Feb 1997 13:06:37 -0800
> > From: [email-masked] (Robert Herriot)
> > 
> > > From [email-masked] Thu Feb 27 09:40:59 1997
> > > From: [email-masked]
> > > 
> > > ... I'd suggest the following relative to the use of HTML
> > > and IPP:
> > > 
> > 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.
> 
> I would express Rogers list of statements somewhat differently and I
> think the difference is important as to why we said we would require
> HTML from the user.
> 
>   A Client of the IPP Model may support access to that model using an
>   HTML binding to the model information.
> 
>   A Client of the IPP Model may support access to that model using an IPP
>   defined binding to the model information (see Protocol Group)
> 
>   An IPP Server must support must support both the IPP defined binding and
>   the HTML binding to the model information
> 
> This recognizes the difference between supporting the model and
> supporting a partiucular binding to the model. At least from my point of
> view, this is why we made the statement.
> 
> After some thought, I would be happy if a server only had to implement
> the HTML binding, both for query and submission.
>         Steve
>

---

From: [email-masked]
Date: Fri, 28 Feb 1997 08:44:07 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

Steve Zilles Wrote:--

If this is the case, I don't know why we bother to do a standard at all.
Clearly, I can gin up
whatever set of html pages (including forms java applets, etc) I want to and
since I send
them out to a browser there is no interoperability problems and the client is
forced into
whatever model I want to describe on the server side. Saying that it confomrs
to IPP is
rather uninteresting!

---

From: [email-masked] (Bill Wagner)
Date: Fri, 28 Feb 1997 11:28:02 -0500

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:  [email-masked] 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

-- 
Randy Turner
Network Architect
Sharp Laboratories of America
[email-masked]

---

From: [email-masked]
Date: Fri, 28 Feb 1997 12:22:25 -0500

Classification:
Prologue:
Epilogue: Roger K deBry

I doubt that we have consensus here.  Personally, I think the use of HTML as
optional support is quite a nice approach to providing information not in IPP or
to provide it in a more elegant or manufacturer-unique way. The use of HTML
templates in the Microsoft implementation is a nice example of allowing the
printer manufacturer to adorn their responses with a logo or whatever they use
to add unique value.

Another example would be the Kinko's case where I could use standard HTML to
put up a slick intro-page, advertise the day's specials, negotiate complex
printing
costs (print 50-100 copies for $xx.xx), etc., but then use standard IPP to
actually
communicate the print job.

In both of these cases, I think that we ought to view HTML as an optional
support
in a printing system, and not a mandatory server capability!!! It's certainly
not part
of IPP in my mind.

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/28/97 10:12
AM ---------------------------

        ipp-owner @ pwg.org
        02/28/97 09:25 AM

To:
cc: ipp @ pwg.org@internet
Subject: Re[2]: IPP>MOD - HTML and IPP streams

     Bill Wagner, Osicom/DPI

        * The core document
        AND

Just my 0.02 worth

Randy