Subject: Re: IPP>MOD - HTML and IPP streams -Reply

From: Scott Isaacson <[email-masked]>
Date: Fri, 28 Feb 1997 16:37:45 -0700

>>> Robert Herriot <[email-masked]> 02/27/97 02:06pm
>>>
> 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.

What about current browsers that have not been written to IPP but have
been written to use HTML?  We leave them out in the cold?

> I think the primary issue is whether a server gives exactly the same
> information and capabilities via IPP and HTML.

The semantic mapping for IPP over HTTP will not include any presentation
information.  The semantic mapping for IPP over HTML must not as well. 
So IPP over HTML will just be abstract attributes and values.  There will
be an infinite number of ways to realize this in HTML.

I see IPP over HTML as just another way to do just a Get Attributes
operation (and maybe a Get Jobs) operation.  Not a Print or a Cancel. 
The resulting HTML file will not be parsable by a program, but should be
displayable by a browser and understandable to an end user.

Scott

---

From: Randy Turner <[email-masked]>
Date: Fri, 28 Feb 1997 16:27:59 -0800

> displayable by a browser and understandable to an end user.

One interesting note is that when you say "IPP over HTML", you're
implying
that HTML is a transport protocol. Usually when we have been speaking
about
IPP over <something>, the <something> has been HTTP, raw TCP/IP, or
maybe
ONC or DCE RPC. This might mean a re-thinking of our document strategy,
unless you really mean something like "IPP over HTTP 1.x w/HTML hooks"
;)

I'm not sure if HTML qualifies as a transport and if not then we need
to look at what the term "IPP over HTML" means, and would there be other
mappings to "languages" like HTML in the future.

Randy

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