RE: CfC: publish FPWD of "app: URI scheme"; deadline April 26th

Agreed.  Thanks,
-Giri

-----Original Message-----
From: Marcos Caceres [mailto:w3c@marcosc.com] 
Sent: Thursday, May 09, 2013 9:44 AM
To: Mandyam, Giridhar
Cc: Mounir Lamouri; public-sysapps@w3.org; wonsuk11.lee@samsung.com; Dave Raggett
Subject: Re: CfC: publish FPWD of "app: URI scheme"; deadline April 26th

On Thursday, May 9, 2013 at 5:41 PM, Marcos Caceres wrote:
> 
> 
> On Thursday, May 9, 2013 at 5:32 PM, Mandyam, Giridhar wrote:
> 
> > Mounir, Marcos,
> > I appreciate all the efforts that Marcos has gone through, in particular sorting through the detailed feedback I provided on the doc. I agree we need to move this forward and get this to FPWD soon.
> > 
> > I believe we are at an impasse on one issue prior to releasing to FPWD: how to handle Section 6.4. My latest proposal is that the text be marked as non-normative (http://lists.w3.org/Archives/Public/public-sysapps/2013Apr/0230.html). I don't believe Marcos is in agreement. So I'll propose the following change:
> > 
> > Change
> > 
> > " To dereference a app: URI to a file in a app package a user agent MUST apply the rules for dereferencing an app: URI. "
> > 
> > to
> > 
> > " To dereference a app: URI to a file in a app package a user agent SHOULD apply the rules for dereferencing an app: URI. ", where SHOULD is as per RFC 2119.
> 
> I think it would be better to say:
> 
> Note: A user agent can deference a URI scheme using other means/technologies (e.g., a proxy), but the end result needs to be indistinguishable from the result that would be obtained by following the specification. 
> 
> Changing the conformance requirements to a SHOULD would just confuse implementers. All that matters is that you get back the data in a consistent and predictable manner. 
I should also add that it should not be a requirement that packaged apps run off the app: URI scheme. The runtime spec should RECOMMEND it. That should address Giri's concerns and give more freedom of choice if implementers want to use something else (e.g., a local http server per application). Again, all that matters is that the results are predictable and interoperable, not that app:// is used.  

-- 
Marcos Caceres

Received on Thursday, 9 May 2013 16:44:58 UTC