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 07:56:49 UTC