ACTION-575 Techniques for Guidlines Document

Here is a list of possibly mad, bad or inane suggestions following my
ACTION-575 from the call on Tuesday. I should add for the sake of
clarity that there are undoubtedly some good suggestions too, and that
the mad, bad and inane ones are likely to be my fault. However, for the
sake of completeness I think they should be examined.

When considering possibilities, per my observations yesterday on the
call I suggest that we need to be grounded in some kind of fact - i.e.
we should have tested support in various well known servers and on a
suitable range of live sites. That merits a separate issue I think.

I hope that the various suggestions here are a fair summary of the
discussion that has flowed to date on the list - as well as the
injection of other ideas by me. The notes on pros and cons are largely
my opinion, though I have allowed opposite views to escape through, here
and there. Please add your voice if your opinion is not represented
fairly. (And the action was to provide pointers, which I haven't)

I haven't made any attempt to relate these techniques to use cases, and
in particular am aware that not all the functions that Magnus suggested
are needed [1] are covered. i.e. this is just a tool kit. It would
really benefit from being read in conjunction with that. I also think
that we need to spell out the use cases more clearly - e.g. consenting
and non consenting parties in various combinations. 

[1]
http://lists.w3.org/Archives/Public/public-bpwg-ct/2007Sep/att-0014/00-p
art

This would better be done on a Wiki but the idea is that folks comment
by adding notes, new suggestions etc. in-line. 

Anyway here goes - all very much a work in progress.

A. REQUEST

1. Use of TRACE - in theory allows a client to find out what's going on
and to see how their headers have been affected when they see the
response

- how many servers support this?
- how realistic is it to think that clients would actually implement it?
- how much would it add in terms of delay to operational scenarios?
- oftentimes we are actually only interested in the operator gateway
though techniques should be extensible to multiple proxies/paths

2. Use of OPTIONS request with max-forwards

- could be useful to make sure that client is able to talk to proxies it
is aware of
- how many clients would actually use this and what for? (Well, maybe to
say that they are already adapting and that the request and content
should be left alone)
- looks like the definition of how to use options is open to us to
define should we choose to go there, but do we?

3. Add an X-Real-User-Agent header

- fake the real user agent
- assume that anyone who wants to know the real user agent will be
interested enough to do so
- means changes to established libraries?
- means existing mobile aware apps ALL must change
- is there a need to reflect the presence of multiple proxies with
different user-agent offerings?
- not really adequate for this to remain an X- so one would want to know
that this was on the standards track?

4. Add the real user agent as part of the massaged user agent string

- could be used as a technique to add a X-I-AM-BOGUS/1.0 at least, part
- or an addition to the comment field to the same effect?
- not clear how this would work with existing UA detection libraries
- not clear how one would add this without messing things up totally

5. Tasting of content with original header

- Means a round trip, but not over the air
- increases server load
- results can be cached so round trips minimised
- GET should be idempotent so that should be OK, what to do about POST?
- could use HEAD, but does this really work in practice?

6. Put Expect: X-Real-User-Agent-Support in the request when adding
X-Real-User-Agent header - or modifying the actual user agent

A Cleverer version of the above but what does it actually tell the
proxy?

A 417 response is REQUIRED if the server doesn't understand this. That
doesn't mean that server do actually support it ... but ...

- would allow the addition of the real user agent and a fake user agent
- servers that want to read the X- header can respond normally
- other servers will respond 417 and the request remade
- mobile aware but non-consenting and non mobile aware treated equally
- results need to be remembered when a 417 response received so header
not added again
- if a server actually ignores the Expect then what should we infer?
i.e. does a normal response mean yes I understand, or does it mean I
didn't and didn't conform to the protocol - seems like there is a need
for something in the response to say "yes I understand"


7. Embed original HTTP headers as part of a multipart mime encoded
elaboration of the request as a message/http part

An elaboration of the X-Real-User-Agent idea, only preserving all the
original headers, which seems like something one should actually do
since if the proxy modifies the accept field then this might mislead a
standards compliant server to use the real user agent but infer wrong
things about the content-types supported

- How easy for content developers to access this info
- Makes requests bigger, but not on over the air segments
- Servers may barf / misoperate
- Can be used for server to analyse what multiple proxies have done with
the request if each adds the header as received
- Need to be able to point to the right header
- Existing mobile aware servers need to change to get the correct info
- might use Expect: X-Support-Embedded-HTTP-Request as above

8. Extend interpretation of host or nickname fields in the Via Header

- can enough info be encoded?
- is it safe?
- comments MAY be dropped by intervening proxies - but are they
actually? And if they are is this really a problem?

9. Add an X-via field

- not understood by existing implementations
- need to move it on from X- status
- what do we actually want to include in the comment that is so valuable
that couldn't be done by simple name mangling?

10-19 reserved for further mad bad or silly ideas ref request

RESPONSE

20. Add a no-transform directive to the Cache-Control header

- makes it clear that the content is not to be messed with
- very blunt instrument - no clear that the server understands that the
user agent presented may be wrong and may make a bad situation worse
- would be better to have further graduations of this, such as
"no-reformat" which means don't alter the presentation but fix the
markup if you must

21. Add a Vary header

- makes clear that the server is varying in its own right and that if
wrong headers have been presented then the content is likely wrong

22. Taste the content

Look see if the headers indicate XHTML-MP, taste content looking for
DOCTYPE

- not desirable in the long term, locks in certain formats for mobile,
whereas increasingly people will want to deliver plain old HTML to
devices that can eat it, consequently may cause false negatives
- doesn't work for images or any format other than HTML

23. Look  for LINK elements

- not clear how flexible this is - e.g. if you have several mobile
variants then how would you indicate this
- if your mobile representation has the same URI as every other
representation what does it mean to say that the alternate is the same
URI?
- works only on html

24. Use any one of a catalogue of "grey area" HTTP headers and/or invent
new ones

- link header, for example, but also Alternates, Content-Version,
Derived-from ... (which seem to be mime related)

25. Use the 300 Multiple Choices response

- human choice
- machine choice by new specification of use of <link> elements? (only
works for html, so link headers preferable - but how to sue to represent
the range of choices one might wish to?)

26. Look at any mobileOK labels that might be attached to the content

- it doesn't necessarily follow that something that is mobileOK doesn't
want to be transformed, but it is probably a good working assumption
- the mobileOK label may be wrong

27. Additional Headers and Footers

- not sure hat we actually mentioned this in the problem statement and
maybe we should have done -  it screws up any servers calculation of
available height. But do we need a way to say - "don't frame my
content"? Should this be under 20. above

Received on Wednesday, 10 October 2007 19:26:25 UTC