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

From: [email-masked] (Robert Herriot)
Date: Thu, 27 Feb 1997 13:06:37 -0800

> 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:
> 
> 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.

---

From: Randy Turner <[email-masked]>
Date: Thu, 27 Feb 1997 13:54:03 -0800

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: "Steve Zilles" <[email-masked]>
Date: Thu, 27 Feb 1997 14:17:26 PST

> Date: Thu, 27 Feb 1997 13:06:37 -0800
> From: [email-masked] (Robert Herriot)
> 

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: Carl-Uno Manros <[email-masked]>
Date: Thu, 27 Feb 1997 16:17:33 PST

>information and capabilities via IPP and HTML.

I am starting to get really confused about this whole discussion. We have
decided that the model specification is to be made in a TRANSPORT
INDEPENDENT manner, and now people start suggesting that we should make IPP
dependent on HTML!

I think we are on the wrong track here and need to back up to the point,
where people started assuming that we make HTML part of the package. 

My assumption up till now has been that certain functions in our overall
scenarios COULD be realized by using HTTP/HTML, but that such functions
would be OUTSIDE THE SCOPE of our three IPP standards document. I think
that bringing in HTML in this disciussion is starting to mix in too many
ideas about implementation into our model discussion, which we should not do.

Carl-Uno 
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]