RE: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]

Oh I certainly wouldn't be pushing for any more "decoration" of UA strings. They're decorated enough as it is. We can do without header bloat. My point is that there's already enough information in the existing headers for the practice of device detection to work successfully, and the DDR is the next step after detection wherein a repository can be queried to find any additional information you want.

Nevertheless, I can imagine cases where a Web application would use an agent on the client (e.g. a XHR carring client-side information obtained via DCCI or some similar client-access mechanism). The agent would communicate additional information back to the application, which could be included into the Evidence. This would enable applications to be more refined about the device capabilities while not imposing header bloat on the rest of us.

Yes, I accept that it is not necessary that the additional evidence from an agent be combined with the regular DDR evidence. Outside of the environment of the application there would be little use for this agent-gathered evidence, so nobody would be interested in such "enhancements" for their DDRs. Or would they? Given that there is some effort going on to standardise client-side APIs (e.g. the recent developments in the OpenAjax Alliance guidelines for client-side JavaScript-based APIs), it is certainly possible that there could emerge a standard (or at least widely used) set of agents. In this case it would make sense to extend evidence to include whatever is gathered by these agents.

My point is that the DDR has the concept of Evidence, and while today there is no strong demand to extend the instances of Evidence beyond HTTP headers, it is *possible* for such extension to occur and thus the DDR is positioned to support device detection within the context of applications, beyond the current server-side sniffing that is dominant today.

For now, most applications are not so sophisticated that they would require this additional awareness of the client context, so the current practice of using the existing HTTP headers is sufficient. For now, anyway.

---Rotan.

(To be clear, I do not believe that the world would be better if more was added to the HTTP headers, though I know that some vendors are already contemplating this. UA strings should be sufficient to identify devices and enable reference to "a priori" knowledge of the device capabilities. No more.)



-----Original Message-----
From: Jo Rabin [mailto:jrabin@mtld.mobi] 
Sent: 16 October 2008 08:56
To: Rotan Hanrahan
Cc: Sullivan, Bryan; Mobile Web Best Practices Working Group WG
Subject: Re: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]

The point of the best practices document is, in part, to point out bad 
things and deprecate them, to point out good things and promote them.

Applications that use HTTP should use HTTP according to its specification.

So are we saying a) that there is consistent and widespread abuse of 
HTTP by current Web apps? or that b) the world would be a better place 
if additional information were included in HTTP headers?

If so what additional information is implied? It might be useful to 
include a comment or product token in the User agent field, like 
myWidget/1.0.

However, it is certainly arguable that increasing the variation of base 
user agent strings is harmful, as it makes device detection more 
difficult, and probably doesn't confer much benefit.

Case a) the XHR is made to the server that served the app - this is an 
internal issue and can be dealt with any way the server likes.

Case b) the XHR is made to another domain. Lets leave aside for a moment 
that this is contrary to the XHR spec, and hence instantly rules itself 
out of qualifying for Best Practice. The other domain usually derives no 
benefit from the myWidget/1.0 bit because it knows nothing about the 
other domain's widgets and SHOULD just serve up the content in whatever 
way it usually does.

I'm sorry if I am dramtically missing the point here. I think on balance 
that further decoration of the underlying UA string makes life 
marginally more difficult for the server with no real benefit.

Those interested in UA strings will no doubt have seen the following 
amusing post [1].

Jo

[1] http://www.webaim.org/blog/user-agent-string-history/




On 16/10/2008 08:37, Rotan Hanrahan wrote:
> Good points Bryan.
> 
> Regarding the user-agent, accept and profile headers to which you refer, these are indeed data used by the DDR to identify the device in use and subsequently adapt to that device using previously recorded capability information. The DDR uses the concept of "Evidence" as the key to perform that lookup. To date, the overwhelming source of evidence is the HTTP headers, though we could also envisage that such evidence might come from the application, from the user, from some third-party monitoring, an Ajax agent and many more potential sources. The DDR has envisaged these possibilities.
> 
> However, the established practice in almost all cases is to base evidence on the HTTP headers, particularly the User-Agent and Accept headers. (Not necessarily to parse what is contained in those headers, but instead to use them as a "fingerprint" that can be used as a key to find the real capabilities. After all, who believes an accept header that says "*/*"?)
> 
> I am encouraged by the recent support for acknowledgement of the role of context/capability awareness in Web applications, particularly the mobile space where diversity is the norm.
> 
> ---Rotan.
> 
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Sullivan, Bryan
> Sent: 16 October 2008 08:12
> To: Mobile Web Best Practices Working Group WG
> Subject: RE: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]
> 
> Hi all,
> 
> Following up on this issue with further information. Testing I have done with various web applications, both mobile and desktop, show that the webapps do specify a particular user-agent header (or extend the web runtime default header, including host device information) and in some cases specific accept-types that are supported or relevant to the particular request. This tells me that there is value in identifying the application via the user-agent header, and the capabilities via the accept header at least.
> 
> Also, they are not limited to sending requests to one server, but can and do send requests to multiple domains based upon the content they are retrieving.
> 
> In contrast, if we narrow the MWABP focus to:
> - webapps that are distributed as browser-based Javascript applications and thus are restricted to cross-domain script limitations (while those constraints still exist)
> - webapps that are specialized to operate per the inherent expectations of the content server, or vice versa, content servers that provide content to webapps with an inherent assumption of the webapp's capabilities (and those of the host platform)
> 
> Then, IMO, we are not adding a lot of value with the MWABP in the area of context/capability awareness (like we did at least with BP1), since ignoring that objective will not reflect the reality of the webapps market, which has already expanded beyond the browser.
> 
> At the least, it would be beneficial if the server can determine the host device type so that it can adapt content to the device capabilities. I don't see why we went to all the trouble of the DDR in the DDWG if we are to ignore that work by saying that webapps don't have to tell the server what type of device is in use. That info is one of the keys to DDR lookup, and is essential for any server application which is concerned with content adaptation/personalization.
> 
> We could of course leave all this off the table and let webapps do such capabilities disclosure at the application layer. But that is just punting the issue into a non-standardized space, or one where the proposed standards seem to be having real market traction issues (e.g. DCCI). I don't see how that serves the developer and content provider, when we have a widely deployed practice available, thru the user-agent, accept, and profile headers.
> 
> I have not heard, on this list, convincing arguments why context/capability awareness is a non-issue with web applications. In the absence of such, why would we ignore the existing best practices in this area?
> 
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Mobile Web Best Practices Working Group Issue Tracker
> Sent: Friday, September 26, 2008 8:52 AM
> To: public-bpwg@w3.org
> Subject: ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]
> 
> 
> ISSUE-281 (DiscloseCapabilities): MWA should disclose their capabilities in HTTP requests, to allow service adaptation [Mobile Web Applications Best Practices]
> 
> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/281

> 
> Raised by: Bryan Sullivan
> On product: Mobile Web Applications Best Practices
> 
> The MWABP should make recommendations on the use of Widget interface features and Javascript functions (e.g. XMLHttpRequest) to achieve what the MWBP comments to the Widgets 1.0 Requirements were attempting to promote, e.g. interoperability, through:
> (a) identification of the widget in HTTP requests (user-agent header)
> (b) disclosure of Widget and device capabilities (Profile and Accept headers)
> 
> Example:
> var client = new XMLHttpRequest();
> client.open('GET', 'http://dcd.server.com/channel?ID=21');
> client.setRequestHeader('User-Agent', 'DCD Widget/1.0');
> client.setRequestHeader('Accept', 'application/vnd.oma.dcd, multipart/mixed, multipart/related');
> client.setRequestHeader('Profile', '"http://megawidgets.com/dcd-widget1.0..rdf"');
> client.send();
> 
> These methods ensure that the capabilities of Web Applications are disclosed (or at least the application identity is disclosed, which is useful as a lookup key for detailed info in a DDR), and thus the Content Provider can adapt services appropriately. Web Applications are expected to have diverse purposes/capabilities and use diverse content types, so it's important that we carry forward and extend as needed the "adapt services to device capabilities" guidance that we provided for browsers in BP1. Because these capabilities may not be disclosed by default though the underlying platform features (XHR or other native HTTP request API), the Web Application developer should be prepared to disclose them directly.
> 
> 
> 
>

Received on Thursday, 16 October 2008 09:05:31 UTC