Re: proposal for issue 457

On Fri, 13 Feb 2004, Jacek Kopecky wrote:

> Yves,
>
> just as a point of clarification, I expect this proposed htx:env element
> is to be a child of a Representation header, right?

Yes.

> If so, do you really need the envelope? Its children can become children
> of the Representation header with no information or capability loss.

I am still hesitating with no wrapping element, 1 (like in the proposal,
to identify a single extention entry), and 2 (meta, for the reply headers,
and context for the request headers and different clock values).


> I also have other minor restructuring suggestions, should be apparent
> from the following pseudoXML:
>
> <Representation>
>  <htx:Request name="GET" version="HTTP/1.1">
>    <!-- the URI is on the Representation -->
>    <htx:Header name="Accept">
>      image/png,image/jpeg,image/gif
>    </htx:Header>
>    <htx:Header name="Accept-Encoding">
>      gzip,deflate,compress;q=0.9
>    </htx:Header>
>    <htx:Header name="Date">
>      Fri, 13 Feb 2004 11:23:28 GMT
>    </htx:Header>
>    [...]
>  </htx:Request>
>  <htx:Reply version="HTTP/1.1" status="200">
>    <!-- the status string is unnecessary, isn't it? -->

Status string is mainly informative, so no big deal to remove it if
needed.

>    <htx:Header name="Content-Type">
>      image/png
>    </htx:Header>
>    <htx:Header name="Date">
>      Fri, 13 Feb 2004 11:23:28 GMT
>    </htx:Header>
>    [...]
>  </htx:Reply>
> </Representation>

Thanks,

>
> Best regards,
>
> Jacek
>
> On Fri, 2004-02-13 at 15:25, Yves Lafon wrote:
> > Here is a proposal to accomodate the HTTP use case for UC2 to allow an
> > implementation to act as a URI resolver using a local cache.
> > Note that it is not a proposal to actually describe a complete portable
> > cache (ex: it does not address the variant lists)
> > The goal here is to give all information used to reconstruct the
> > information a cache would need.
> > The calculation of the age and cache validity is up to the application, as
> > the originator should not be forced to undertand the caching issues of
> > HTTP/1.1
> > Exemple:
> >
> > <htx:env xmlns:htx="http://www.w3.org/2004/02/xop/http">
> >  <htx:request>
> >    <htx:request-line name="GET" version="HTTP/1.1">
> >      /someuri/us.png
> >    </htx:request-line>
> >    <htx:header name="Accept">
> >     image/png,image/jpeg,image/gif
> >    </htx:header>
> >    <htx:header name="Accept-Encoding">
> >     gzip,deflate,compress;q=0.9
> >    </htx:header>
> >    <htx:header name="Date">
> >      Fri, 13 Feb 2004 11:23:28 GMT
> >    </htx:header>
> >    [...]
> >  </htx:request>
> >  <htx:reply>
> >   <htx:status-line version="HTTP/1.1" status="200">
> >    OK
> >   </htx:status-line>
> >   <htx:header name="Content-Type">
> >     image/png
> >   <htx:header>
> >   <htx:header name="Date">
> >    Fri, 13 Feb 2004 11:23:28 GMT
> >   </htx:header>
> >     [...]
> >   </htx:reply>
> > </htx:env>
> >
> > It is mainly the complete headers and request/status line for the request
> > and the reply, as context of the attached binary.
> >
> > Also, for completeness, the local time when the request is issued (usually
> > there in the Date: header) and the local time of the same machine when the
> > reply is received would be a good addition to cope with clock issues,
> > something like <htx:time>{RFC 1036 time string}</htx:time> in
> > <htx:request> and <htx:reply>
> >
> > The only remaining issue regarding time (not fixed) is the possible clock
> > desynchronization between the SOAP sender and the SOAP recipient.
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Friday, 13 February 2004 19:55:00 UTC