Re: Record of http discussions at the Paris WWW conference

Daniel DuBois:
>[Koen Holtman:]
>>  - There is no spoofing mechanism: i.e. a response with come
>>    Content-Location header may _not_ be used by 1.1 caches for
>>    serving later requests which are done directly on the
>>    Content-Location URI.
>I disagree strongly with this change, both in it's nature, and in
>it's timing.

This change was not thought up in Paris.  We decided some time ago
that 1.1 would _not_ contain a spoofing mechanism because it spoofing
was too controversial to get convergence on before the end of this
month.  See my message titled `SPOOF issue (Was: Re: Rewrite of 13.12
(Cache keys))' to the http-wg on Sun, 28 Apr 1996 00:53:40 +0200 (MET

It is too late now to re-introduce spoofing in the plain 1.1 spec.

Note however that the 1.1 spec intends to allow for the possibility
that a future content negotiation spec will weaken the `may _not_ be
used by 1.1 caches to...' rule above, effectively introducing a spoofing

>In my mind, such a change defeats the purpose of the
>Location/Content-Location header with regards to content negotiation,
>as it has been discussed and developed over the last 5-10+ months.

The omission of spoofing from 1.1 only delays the introduction of this
aspect of the content negotiation draft, it does not block it.

>As a process issue, there's little (no?) justification for the ground
>work laid down by the subgroups over many weeks/months to be tossed
>in favor of last minute changes by the editorial group.

Speaking from a process standpoint, I would say that 1) there is no
explicit consensus about spoofing in the content negotiation subgroup
and 2) even if you disagree with 1), the spoofing mechanisms thought
up by this subgroup have not yet had sufficient review by the whole wg
to declare wg consensus on them.  This is why I closed the SPOOF
issue some time ago with a `not in 1.1'.

In my opinion, the last minute changes thought up by the editorial
group do not block the implementation of the work of the content
negotiation subgroup on top of plain 1.1.  The future content
negotiation spec could say something like `if an Alternates header is
absent, the Content-Location information serves the purpose of an
opaque variant-ID.  If an Alternates header is present however, then
the Content-Location information can also be used to....'.

However, I consider this point to be moot now.

I guess that the variant-id --> content-location simplification idea
of (some people in) the editorial group has met with enough
unhappiness on the list to make the use of this idea for the 04 draft

As far as I can see, we have no choice but to keep the variant-id
mechanism we have in the 03 draft now.  The only changes we can make
in the draft are to the terminology and concepts used to define the
mechanisms, not to the mechanisms themselves.

Some simplification ideas we discussed in Paris would also work
without any change to the mechanisms defined. I'll try to write it up
in a separate message tomorrow.

 [Rest of Dan's text deleted.  I share Dan's dream future of
 everything being transparently negotiated.  Our differences mainly
 seem to be in the timing of the move to this future]

>the Programmer formerly known as Dan          


Received on Wednesday, 15 May 1996 14:47:38 UTC