If we want to stress the idea of "Be conservative in what you send, and liberal
in what you receive", then what we're really doing is opening up how liberal
the server might be. In that case, we would restrict any language that is
non-conforming to talk about how a server might behave if it receives a request
that is not "strictly conforming".
Also, when we talk about these exceptional cases we should not use
"standard" language terms like MAY, MUST, SHOULD, and NOT. Since this is an
implementer's guide and not a specification. These are essentially a list of
hints and suggestions compiled from implementation experience. I wouldn't
think anything in the implementer's guide is mandatory or optional. It's just a
compilation of WG suggestions for implementers.
Randy
Manros, Carl-Uno B wrote:
> Randy,
>
> Please note that this is suggested for the Implementor's Guide that will be
> an informational document. We have already established that there are
> currently
> a number of HTTP client and HTTP server implementations that have
> implemented
> some, but not all, the HTTP 1.1 features. This was intended to give guidance
> to implementors on how to cover such intermediate real life scenarios.
>
> Carl-Uno
>
> > -----Original Message-----
> > From: Randy Turner [mailto:rturner@sharplabs.com]
> > Sent: Wednesday, October 21, 1998 12:38 PM
> > To: Hastings, Tom N
> > Cc: ipp
> > Subject: Re: IPP> PRO - Issue 2.7 - regarding Disabling chunking
> > responses
> >
> >
> >
> > IMHO, it doesn't sound very good for any of our documents to
> > talk about what
> > non-conforming implementations should be doing. In no way
> > (either implied or
> > explicitly) should we be advocating non-compliant
> > implementations. I think this
> > text falls in the "implied" category, and should not be included.
> >
> > Just my $0.02
> >
> > Randy
> >
> >
> >
> >
> >
> > Hastings, Tom N wrote:
> >
> > > With respect to Issue 2.7, the answer is proposed to be:
> > >
> > > Add to the IIG (IPP Implementers Guide):
> > >
> > > Clients should anticipate that the IPP server may chunk
> > responses and should
> > > handle them. However, a client that is not fully
> > conformant MAY attempt to
> > > request an HTTP 1.1 server to not use chunking in its response to an
> > > operation by using the following HTTP header:
> > >
> > > TE: identity
> > >
> > > This mechanism should not be used by an IPP server to
> > disable an IPP client
> > > from chunking a request.
> > >
> > > So I guess we need to keep it that way, ok?
> > >
> > > Tom
> > >
> > > >-----Original Message-----
> > > >From: Larry Masinter [mailto:masinter@parc.xerox.com]
> > > >Sent: Tuesday, October 20, 1998 23:46
> > > >To: Hastings, Tom N
> > > >Cc: Carl-Uno Manros; Xavier Riley
> > > >Subject: RE: Disabling chunking responses
> > > >
> > > >
> > > >> Is this technique for disabling chunking ok to use?
> > > >
> > > >I'm suspicious, but it looks legal.
> > > >
> > > >> How wide-spread is its support?
> > > >
> > > >This is something that I don't know; there are reports of
> > > >support, but it's a market issue rather than a technical
> > > >one. Test.
> > > >
> > > >> Is it an HTTP 1.1 only feature?
> > > >
> > > >Chunking is HTTP/1.1 only, so disabling it is too.
> > > >
> > > >Sorry I can't be more helpful.
> > > >
> >