Re: Content Transformation 1k - and Change List

Many thanks for this update, Jo!
It is extremely useful to have this updated view and be able to see the 
list of chunks that still require some attention.

I'll send an agenda for tomorrow in a few hours, and will try to include 
all these points.
Looking at it and the list of still opened actions/issues, I'd say we're 
both close to completion but still have a lot of things to review and/or 
fine-tune (does this ever end?).

Please find a few notes below.

Francois.


Jo Rabin wrote:
[...]
> 
> 4. From the minutes of 29 April
[...]
> RESOLUTION: Rewrite §3.2.1 roughly based on what it was before:
>     "They MAY also provide the ability for their users to make a
>     persistent expression of preferences."
> (not sure in what way this was meant to be different to a similar
> resolution from 15 April)

The difference is in the use of "semi-persistent". The discussion lead 
to saying that the distinction between "persistent" and 
"semi-persistent" was confusing and did not need to be done in this doc. 
The resolution was thus to remove "semi-persistent" from the sentence.

This was supposed to close the discussion on persistence vs. 
semi-persistence (and thus point C. below), but I do note from the 
minutes that you were not really in favor of that decision:
"jo: notes that we are avoiding having a discussion on something that
     might reveal important things but for now, let's do it your way fd"
Do you want to re-open the discussion?


[...]
> 5. From the minutes of 6 May
[...]
>ACTION-752 - Propose text for the final part
>of 4.1.2 taking into account resolutions and discussion on this and
> the previous call [on Jo Rabin - due 2008-05-13]. 

I note that, although it doesn't seem to appear in the minutes, I 
summarized it in the email I sent after the call:
http://lists.w3.org/Archives/Public/public-bpwg-ct/2008May/0006.html
... by: precise "still in doubt" at the end of 4.1.2 (jo)


[...]
> 6. From the minutes of 13 May
[...]
> NOT DONE [- Mention examination of URIs also in 4.1.2 (transformation of
> the
> request) to complete the list after "the proxy SHOULD analyze whether it
> intends to offer transformation services by referring to:".]

Right. Given that the result of our discussion on the mailing-list seems 
to indicate that this could be a useful heuristic for determining if the 
response is a rejected 200 response, that it's listed in 4.4 and that we 
have link to 4.4 in "issue a request with unaltered headers and examine 
the response", I suggest that we just drop it from there and will 
propose that on tomorrow's call.


> 
> 
> 7. No meeting 20 May
> 8. From the minutes of 20 May

Auto-generated minutes? Wow, cool ;-)
OK, sorry, Monday morning...


[...]
> A. Editorial Note: The BPWG requests feedback on the degree to which it 
> is necessary to distinguish between Content Transformation proxies that 
> interact with user agents using HTTP, and other types of arrangements 
> where a (proprietary) client application interacts with an in-network 
> component using other techniques.
> 
> this needs resolution

Indeed. Links to ACTION-678 on Sean.


> 
> B. normative Need link to definition
> 
> Where is the discussion of types of document?

Well, AFAICT, it's not so clearly defined anywhere.
Here are two suggestions:
http://www.w3.org/QA/glossary#N
http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential-requirements


> 
> C. Editorial Note: The BPWG is studying how to clarify the scope of 
> "persistent" and "semi-persistent".
> 
> Are we still?

See above. We're not. Unless you'd like to discuss it further.


> D. Editorial Note: The BPWG is studying heuristics for determining when 
> a response with a 200 Status should be treated as a response with a 406 
> Status.
> 
> We need an answer on this

Indeed. Links to ACTION-673 on Aaron.


> 
> E. Editorial Note1k: Need to put something at the end of the rainbow in 
> case the URI is ever resolved.
> 
> Need to action someone to make sure that a pointer to this document is 
> put at that URI ...

Yes, I had actioned myself automatically.
Reservation of such a namespace URI is done by the W3C Webmaster. I made 
the request, it's still pending as I write this message. Note that the 
final URI might be slightly different from the one that is in this draft 
(it could be http://www.w3.org/ns/ct for instance)


> 
> F. Editorial Note: The BPWG is studying the use of the link element of 
> HTML which is used for this purpose. It is noted that the link element 
> is not available in formats other than HTML, and it is noted that there 
> is currently active discussion about the use of the Link HTTP header, 
> which would serve this purpose well.
> 
> We have resolved that the proxy should follow links, but we never 
> discussed what the server should do by way of inserting links. 
> Additionally I'm unclear how to point to "self". Additionally we need to 
> be clear what happens to the link element in the multi-serving case ...

Well, the point to "self" did not receive much support as in "well, why 
not, but what does that really tell?", so we decided not to talk about 
it as a guideline. Looking at 4.2 "the medium for which the presentation 
is intended SHOULD be indicated", we have a contradiction in there, 
because there's no way to follow this guideline without that. So:
- either we drop the guideline
- either we clearly express how to point to self there.

The consensus seemed to be that the linking mechanism was rather to be 
used as a way to link to "real" alternate representations and that, if 
we do not use this as an explicit "handheld flag", then we did not have 
to insist on the mechanism, apart from saying that the CT-proxy SHOULD 
follow the link, as it's not directly a content-transformation issue (I 
can see ISSUE-222 glooming in the dark here).


> 
> G. Editorial Note: The BPWG is aware that more precision may be needed 
> in the above statement. If a transforming proxy has followed the 
> guidelines in this document, then it should not receive a response with 
> a Vary header if it has not already received such a response to a 
> request with unaltered headers.
> 
> Don't find any discussion on this, suggest we just drop this note

I thought we had agreed to clarify this thing at some point, but it
seems to have fallen through the cracks. The point was to clarify what
"MUST be prepared to re-issue the request" would mean since there is no
real practical case when one follows the guidelines to end up in this
situation.


> 
> H. unless the resource referenced is the current resource (1k) as 
> determined by [unresolved discussion] ....

Links to pointing to self above (point F).
I'm not sure we need to precise anything here, though. I'd say it's 
CT-proxy business to avoid infinite loops and determine when the 
resource pointed to by the link element is indeed the resource received.


> 
> I. 4.1.2 Proxy Decision to transform - this needs a bit of a write 
> through as discussed under ISSUE-255
> 
> J. Need to review all ISSUES and ACTIONS to make sure they are dealt with.

Yes and yes...

Received on Monday, 9 June 2008 10:06:34 UTC