RE: ACTION-575 Techniques for Guidlines Document

I should have included 

27. The Warning response as noted by Sean Patterson in his original note

And I will add

10. Pragma - which is a possibly useful header and pretty much unused it
would seem.

Jo


> -----Original Message-----
> From: public-bpwg-ct-request@w3.org
[mailto:public-bpwg-ct-request@w3.org]
> On Behalf Of Jo Rabin
> Sent: 15 October 2007 11:01
> To: Aaron Kemp
> Cc: public-bpwg-ct@w3.org
> Subject: RE: ACTION-575 Techniques for Guidlines Document
> 
> 
> 
> 
> My further comments in-line
> 
> Jo
> 
> 
> > -----Original Message-----
> > From: Aaron Kemp [mailto:kemp@google.com]
> > Sent: 14 October 2007 20:56
> > To: Jo Rabin
> > Cc: public-bpwg-ct@w3.org
> > Subject: Re: ACTION-575 Techniques for Guidlines Document
> >
> > Wow Jo, nice list :)
> >
> > I think there is a lot to talk about here, so I have just picked a
> > couple and commented on them.
> >
> > On 10/10/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> > > 4. Add the real user agent as part of the massaged user agent
string
> >
> > This one I am not crazy about just because User Agent strings are a
> > mess already.  Trying to stuff more in there is probably not a good
> > idea.
> >
> I agree that one would need to assess what kind of damage this could
do
> aside from any kind of benefit it might bring. However, it seems
> possible, at least, that adding something like "I am bogus" in there
> wouldn't matter to died in the wool "you gotta say you are xxx or I
> won't talk to you" sites at the same time as causing more sensitive
> mobile aware sites to say, OK I know you're just kidding.
> 
> > > 5. Tasting of content with original header
> >
> > Assuming I understand what you are suggesting, I generally like this
> > one.  In fact this is what I think is probably the best idea.  We
> > could issue a request that looks as much like what the original
device
> > would have made as possible, then inspect the returned content.  If
it
> > looks like non-mobile content, we can have our way with it,
otherwise,
> > we'll pass it along.
> >
> > Now if the server returns content akin to "go away, you're not using
> > LatestBrowser X on CoolestPlatform Y", we'd have to fire off a
second
> > request with a spoofed User Agent.  We could record this fact
> > somewhere to reduce the round trips required for subsequent requests
> > (of course, this recorded value would have to be expired at some
point
> > so as to allow a site to modify their behaviour).
> >
> Yes, I like this one too subject to the caveats you mention. The issue
> seems to me to be that there are no doubt sites out there that return
a
> 200 status while at the same time as saying "go away ...". So
detecting
> this would mean some kind of heuristics that would be hard to specify.
> Nigel suggested in an earlier post that one should let this response
> float all the way back to the user and allow them to make a choice at
> that point, though in detail I'm not sure how the choice would be
> presented or how a proxy would know to offer it.
> 
> We also have various examples of the /mobile version yielding
> instructions for getting the service on mobile if the site thinks you
> are not mobile, while offering the service at the same URI if it
thinks
> you are. That's very broken from a THEMATIC_CONSISTENCY point of view,
> but doesn't mean it can be ignored, imo.
> 
> 
> > > 7. Embed original HTTP headers as part of a multipart mime encoded
> > > elaboration of the request as a message/http part
> >
> > Seems like a fairly large change that will break a lot of existing
> > mobile stuff.  It would be a complete solution though, for anyone
who
> > cared enough to use the information.
> >
> I wonder? I was kind of hoping that most Web servers simply ignore the
> HTTP entity body of a GET. Afaik there isn't any prohibition in HTTP
> from including one. That on its own doesn't mean that it wouldn't
cause
> problems, of course.
> 
> 
> > > 22. Taste the content
> > > Look see if the headers indicate XHTML-MP, taste content looking
for
> > > DOCTYPE
> >
> > So I like this, as I said above, but more involved that just looking
> > at the DOCTYPE.  For a given request, we presumably have a pretty
good
> > idea about what the device can actually handle, so we can transform
> > content in the response that we know it doesn't support, and pass
the
> > rest through.  This way, a nicely done mobile site will be
unmodified.
> 
> I think this is worth mentioning as a - "Using heuristics according to
> the content type may provide additional info, e.g. for HTML ...).
Won't
> work for images or formats that are intentionally non-standard or
opaque
> such as responses to XML-HTTP-Requests, downloads etc. so any such
> discussion would need to come with heavy caveats - like "you think the
> server is trying to send HTML but it looks broken, but actually turns
> out that this is a response to a request for half an HTML page which a
> process at the device is trying to insert into some already retrieved
> page."
> 
> 
> >
> > > 23. Look  for LINK elements
> >
> > Worth noting that although this method has shortcomings, it is
> > somewhat widely deployed.
> >
> 
> Sure. It really would be better in HTTP though.

Received on Thursday, 18 October 2007 18:39:47 UTC