IPP>MOD - HTML and IPP streams

IPP>MOD - HTML and IPP streams

IPP>MOD - HTML and IPP streams

Randy Turner rturner at sharplabs.com
Thu Feb 27 16:54:03 EST 1997


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




More information about the Ipp mailing list