HTML, etc. are part of the protocol documents. The model document will
not specify whether HTML is required or not. The protocol document
will address mappings from the model to a protocol. But the unanswered
question is what the protocol document will say about conformance,
especially if it defines two bindings (to use Steve's term).
Bob Herriot
> From cmanros at cp10.es.xerox.com Thu Feb 27 16:23:44 1997
>> At 01:06 PM 2/27/97 PST, 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.
> >
>> 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: manros at cp10.es.xerox.com>