headers
Sullivan, Bryan | 1 May 2009 04:31
Picon
Favicon

RE: [widgets] Comments to <access> element text

Hi Robin,
I appreciate the consensus on the required attribute. 

The duration attribute is an attempt to address the more fine-grained "needs vs policy" alignment that is
hinted at in the "required" flag. As widget runtime environments are deployed with policy controls on
what can be accessed (e.g. OMTP's BONDI), we need to figure out how to let users know as soon as possible in
the widget lifecycle (i.e. discovery/installation/use) that a widget will not work unless it is allowed
certain permissions in the user's device. It is undesirable for users to find out that a widget will not
work after having gone through the trouble of downloading it (and maybe paying). So some expression of the
intended behavior (or necessary permissions) of the widget is needed, more fine grained than simple
access to an API. Alternatively, some way for the widget or widget source (e.g. app store) to discover the
permissions that will apply to the widget could be provided.

However the "required" flag is at least a good step in the right direction, and I am OK with postponing the
"duration" attribute for further discussion.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Robin Berjon [mailto:robin <at> berjon.com] 
Sent: Thursday, April 30, 2009 7:54 AM
To: Sullivan, Bryan
Cc: public-webapps
Subject: Re: [widgets] Comments to <access> element text

Hi Bryan,

On Apr 30, 2009, at 16:06 , Sullivan, Bryan wrote:
> Here are a couple of suggestions for the <access> element
(http://dev.w3.org/2006/waf/widgets/#the-access-element
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jonas Sicking | 1 May 2009 08:41
Gravatar

Re: I18N issue: case-sensitivity of locale subdirectories

On Wed, Apr 29, 2009 at 7:16 AM, Robin Berjon <robin <at> berjon.com> wrote:
> Hi,
>
> the following issue has cropped up in the I18N model as described in the
> excellent I18N document from Marcos[0].
>
> Assume we have two localisation subdirectories:
>
>  locales/en/
>  locales/EN/
>
> What happens? BCP47 (which we reference) is defined to be case-insensitive
> so it doesn't help us much in this respect.
>
> There are multiple options:
>
>  a) we define a canonical casing and all others are ignored;
>  b) we select an order of priority and we only consider one (the first to
> match);
>  c) we select an order of priority and we merge them all (in that order,
> with a given precedence rule);
>  d) the device on which the user agent is catches fire.
>
> I think that (a) should be ruled out because as BCP47 tells us, ISO639-1
> recommends lowercase (language codes), ISO3166-1 recommends uppercase
> (country codes), and ISO15924 recommends titlecase (script codes). These are
> different, but likely to be confusing, and I don't think that developers
> should have to worry about that.
>
> I'd like to reject (d) as out of line with our design preferences.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Wilson | 1 May 2009 11:36
Picon
Gravatar

Re: Widget instances and widget invocations

Hi Robin,

I think you're missing a scenario, which is where your multiple  
instances are for different users. In which case "A" is the only  
viable option. "C" would mean that User A gets User B's preferences  
for their widget.

I imagine for most if not every UA that invoking a widget involves  
instantiating a containing object  which has a persistent local  
identifier, so the issue you raise on the "A" option is a non-issue  
for existing UAs.

Note that the issue largely arises because of this "Kill widget"  
behaviour which is not one which is defined in the specification:

- If you try this out now in Apple Dashboard, for example, you'll find  
that "Kill Widget" (i.e. remove from dashboard) also deletes all  
information associated with the instance, so the issue would not arise.

- In our implementation (Wookie), if you delete an instance from the  
page (i.e. remove a widget block from a user profile page in a social  
app), then add another instance of the same widget, the original  
preferences have been removed in the same manner as in the Apple  
Dashboard example, as each widget block is a unique context as far as  
the web application and Wookie are concerned. However, if you just  
close down the browser window, and then reopen the same page in a new  
browser window, then the server supplies the persisted instance ids on  
re-rendering the page, so instances retain the same preferences keyed  
on their original context.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kai Hendry | 1 May 2009 12:49
Picon

Re: [widgets] dig sig and requirements ready for pub!

http://dev.w3.org/2006/waf/widgets-digsig/#identifier-signature-property

I'm not sure what "signature management" is exactly, though can
someone please inform me what a UA is supposed to do with
dsp:Identifier?

I'm also keen on seeing a simple self sign sign/verify example using
http://www.aleksey.com/xmlsec/ or some other opensource tool.

Kind regards,
Permalink | Reply | 17 comments |
headers
Arthur Barstow | 1 May 2009 15:15
Picon

Re: [widgets] Comments to <access> element text

I added the 'duration' attribute to the Widgets V2 Feature List:

  <http://www.w3.org/2008/webapps/wiki/Widgets2_UC% 
26R#Features_Wish_List>

-Regards, Art Barstow

On Apr 30, 2009, at 10:31 PM, ext Sullivan, Bryan wrote:

> Hi Robin,
> I appreciate the consensus on the required attribute.
>
> The duration attribute is an attempt to address the more fine- 
> grained "needs vs policy" alignment that is hinted at in the  
> "required" flag. As widget runtime environments are deployed with  
> policy controls on what can be accessed (e.g. OMTP's BONDI), we  
> need to figure out how to let users know as soon as possible in the  
> widget lifecycle (i.e. discovery/installation/use) that a widget  
> will not work unless it is allowed certain permissions in the  
> user's device. It is undesirable for users to find out that a  
> widget will not work after having gone through the trouble of  
> downloading it (and maybe paying). So some expression of the  
> intended behavior (or necessary permissions) of the widget is  
> needed, more fine grained than simple access to an API.  
> Alternatively, some way for the widget or widget source (e.g. app  
> store) to discover the permissions that will apply to the widget  
> could be provided.
>
> However the "required" flag is at least a good step in the right  
> direction, and I am OK with postponing the "duration" attribute for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arthur Barstow | 1 May 2009 16:48
Picon

LCWD of Widgets 1.0: Digital Signatures published 30-Apr-2009

On April 30 the WebApps WG published a LCWD of the Widgets 1.0  
Digital Signatures spec:

[[
<http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/>

Introduction

This document defines a profile of the XML Signature Syntax and  
Processing 1.1 specification to allow a widget package to be  
digitally signed. Widget authors and distributors can digitally sign  
widgets as a mechanism to ensure continuity of authorship and  
distributorship. Prior to instantiation, a user agent can use the  
digital signature to verify the integrity of the widget package and  
to confirm the signing key(s). This document specifies conformance  
requirements on both widget packages and user agents.

A widget package can be signed by the author of the widget producing  
an [XMLDSIG11] signature that cryptographically includes all of the  
file entries other than signature files. A widget package can also be  
signed by one or more distributors of the widget, producing  
[XMLDSIG11] signatures that each cryptographically includes all of  
the non-signature file entries as well as any author signature.
]]

We explicitly seek comments from the XML Security WG; comments from  
other WGs as well as the TAG are welcome.

The comment period ends 1 June 2009.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Marcos Caceres | 1 May 2009 16:57
Picon
Favicon
Gravatar

Re: review of A&E

On Thu, Apr 23, 2009 at 2:04 PM, Max Froumentin <maxfro <at> opera.com> wrote:
> Hi Marcos,
>
> All changes approved, except the 2 below:
>
> Marcos Caceres <marcosc <at> opera.com> writes:
>
>>> 5. [Dependencies on Other Specifications] The last 2 statements logically yield "A user agent MUST
attempt to implement [some specifications]"
>>>
>> now reads:
>> [[
>> A user agent supports a specification if it attempts to implement that
>> specification.
>>
>> A user agent MUST support:
>>  * the [Widgets-Packaging] specification,
>>  * the [WebStorage] specification's Storage interface, with the
>> exclusion of the Database interface.
>>  * the [DOM3Core] specification.
>> ]]
>
> It ends up to the same logical conclusion, no? If you substitute "support" in the second sentence you get:
> "A user agent MUST attempt to implement: ....". Surely, 'attempt to' is extra, no?

Ok. I guess it it MUST support then it is expect to be a complete
implementation.

>>> 14. [The authorName Attribute] This is a comment on P&C: <author> is used to deduce the  "author name"
property, but in the definition of <author> it's not specified that the element must contain the author's name.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcos Caceres | 1 May 2009 17:18
Picon
Favicon
Gravatar

Re: New Widgets A&E Editors Draft

Hi Rainer,
On Fri, Apr 24, 2009 at 4:18 PM, Hillebrand, Rainer
<Rainer.Hillebrand <at> t-mobile.net> wrote:
> Dear Arve,
>
> Here are my comments on your Widgets A&E last editor's draft.
>
> 1. Change "A environment in which a Widget interface is presented to the user." to "An environment in which
a Widget interface is presented to the user."
>

Fixed.

> 2. All URLs in the "Step 8" hyperlinks in section "The Widget Interface" have a backslash at the end.
>

fixed.

> 3. Section "The Widget Interface", definitions of "viewMode" to "version" attributes: e.g. "Upon
instantiation, this attribute MUST be set to the value of widget window mode, which is derived from the
configuration defaults from processing the configuration document in the [Widgets-Packaging]
specification (Step 8)." In step 3 of [Widgets-Packaging], a user agent must assume the defined default
values. In step 7, the configuration document is processed. So, "Step 8" seems to be the wrong step.
According to my understanding, when a widget uses the Widget interface, step 3 and step 7 were already
processed. This means the return value is either the default value or the value that was set in the
configuration document. Isn't it the case for all readonly attributes? Only the definition of the
identifier attribute contains the "if one was used in the configuration document" condition. What would
you think about a definition like "The identifier attribute represents the value of widget element's id
attribute, if one was used in the configuration document ([Widgets-Packaging], Step 7). Otherwise,
this attribute MUST be set to the value of widget id, which is derived from the configuration defaults from
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 1 May 2009 17:20
Picon
Favicon
Gravatar

Re: Proposal to update signature text in Packaging and Config, remove from Widget Signature

On Tue, Apr 28, 2009 at 12:13 AM, Marcos Caceres <marcosc <at> opera.com> wrote:
> I will make the changes below and change the style sheet to uppercase
> rfc2119 terms.

Ok, done.

> On Monday, April 27, 2009, Frederick Hirsch <frederick.hirsch <at> nokia.com> wrote:
>> I suggest the following
>>
>> remove from widgets signature:
>> http://dev.w3.org/2006/waf/widgets-digsig/#use
>>
>> "A user agent MUST prevent a widget from accessing the contents of a
>> digital signature document unless an access control mechanism
>> explicitly enables such access, e.g. via a an access control policy.
>> The definition of such a policy mechanism is out of scope of this
>> specification, but may be defined to allow access to all or parts of
>> the signature documents, or deny any such access."
>>
>> change packaging and config,
>> http://dev.w3.org/2006/waf/widgets/#digital-signatures
>>
>> replace 2nd paragraph which is currently
>>
>> "Where a user agent that implements this specification interacts with
>> implementations of other specifications, this user agent must deny
>> other implementations access to digital signature documents unless an
>> access control mechanism is in place to enable access according to
>> policy. The definition of such a policy mechanism is out of scope of
>> this specification, but may be defined to allow access to all or parts
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcos Caceres | 1 May 2009 17:27
Picon
Favicon
Gravatar

Re: I18N proposals document review...

Hi Addison,

On Thu, Apr 30, 2009 at 6:28 PM, Phillips, Addison <addison <at> amazon.com> wrote:
> Hello Marcos,
>
> Sorry about the delay in responding to your e-mail of the 16th [1] regarding the document at:
>
>  http://dev.w3.org/2006/waf/widgets/i18n.html
>
> Our WG had a bit of a break due to holidays, etc., so we're just now catching up. I realize that your WG had a
desired date of the 23rd for a response from us. However, we're just now getting to it. We definitely will
have comments for you.
>

Great!

> The Internationalization WG expects to send you a complete our review during our next teleconference,
which is scheduled for 6 May 2009. Please let me know if this is inconvenient for you or your WG.
>

Not a problem at all, we really appreciate any help/guidance i18n
members can give us. We are really looking forward to your comments to
help us move forward on these issues!

Kind regards,
Marcos

--

-- 
Marcos Caceres
http://datadriven.com.au
(Continue reading)

Permalink | Reply | 0 comments |

Gmane