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 Monday, 15 October 2007 10:01:58 UTC