RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging & Configuration spec

Hi Marcos, Art, All,

Please find below Vodafone's comments on the Widgets 1.0: Packaging and
Configuration specification. I have divided them into what I consider to
be substantive comments and editorial comments.

Thanks,

Mark


------------------------------------------------------------------------
----------------------
Substantive comments
------------------------------------------------------------------------
----------------------
Step 5 Process the Digital Signatures 

We disagree with the stage 2, specifically "If the file entry is deemed
by the [Widgets-DigSig] to be an invalid widget, then a widget user
agent must treat this widget as an invalid widget.", on two grounds: 

(1) Because one signature is invalid it doesn't mean that all of the
signatures are invalid; 
(2) Just because one signature or all signatures are invalid does not
mean that the widget should not be installed, only that it should _not_
be treated as a signed widget. The security policy of the device might
be configured not to install an unsigned widget or a widget with an
invalid signature but this should be dependent on the security policy
implemented.

-----------------------------------------------
Step 4 Locate Digital Signatures for the Widget 

I'm not sure whether the packaging and configuration specification is
the correct place to do this but IMHO there needs to be a statement that
a files with a file name corresponding to the naming convention for
digital signatures are not accessible from the widget once the widget is
installed / instantiated. Failure to impose this restriction will make
it possible to include a signature and then reference it from the signed
code, which presents a security hole.

-----------------------------------------------
7.10 The access Element 

The access element defines a network attribute as "A boolean attribute
that indicates that the widget might need to access network resources as
specified in [Widgets-Security]. "

Based on this description we would like to make the following
observations and suggestion: 

The access element contains security permissions that will be used as
hooks in the yet to be written [Widgets-Security] specification. The
problem is that the permissions haven't yet been discussed in detail and
so we may find that we want to represent additional context other than a
black and white "is network access required?". For example, it may be
the case that it is important from a security point of view to know
which bearer or protocol will be used, or to nest a set of domains/URLs
with which the widget wants to communicate. I do not have a strong view
on what might be relevant here, and I am not suggesting that it needs to
be considered as part of the last call of the Packaging and
Configuration spec, only that it is likely that the permission will need
to be more complex when we look at it from a security perspective. 

There is also the case in which the network permission may be used to
determine whether or not the user wants to install a widget, or by the
widget user agent may want to indicate whether or not the widget can run
when there is no available network connection. Some widgets may only
operate when there is a network connection, whereas others may degrade
gracefully.

So to provide a degree of future-proofing we would like to suggest
something like:

<access>
    <network use="true/false" required="true/false"/>
</access>

(I realise that the "use" attribute in the above example is a horrible
name but I couldn't think of another word for access...There are
probably also better ways of capturing the meaning - we open to
suggested improvements)   

Sorry for not raising this earlier but it has only become apparent when
considering in more detail how the access element would be used.


------------------------------------------------------------------------
----------------------
Editorial comments
------------------------------------------------------------------------
----------------------
6 Widget Resources 

First 5 bullets should say "and/or" rather than "or" ?

-----------------------------------------------
6.5 Content Localization 

"The container for localized content is a folder at the root of the
widget whose the first five characters of the folder-name case
insensitively match the string 'locales/'." Why the first five
characters only? 

Also sentence has an extra "the" in the middle, i.e. "whose *the* first"

-----------------------------------------------
6.6 Start file and Default Start Files Sentence 

For consistency with other sections I suggest to add: 

"A default start file is a start file whose file-name case insensitively
matches a file-name given in the first column of the default start files
below and whose MIME type matches the MIME type given in the second
column of the table."

before the sentence starting: "A default start file is a start file that
a widget user agent..."

And then to combine the last two sentences before the default start
files table to: 

"A widget user agent will attempt to locate a file entry whose file-name
case insensitively matches one of the default start files based on the
order they appear in the table below (from top to bottom). "

-----------------------------------------------
7.1 Namespace 

It seems a bit tough that an invalid configuration document results in a
invalid widget as the configuration document is optional. Also, if the
configuration document in the localised folder is invalid, it could be
the case that there is a valid configuration document at the root of the
widget.

I don't have a strong opinion on this and have no objection to leaving
the text as it is, I just wondered if there was a reason why this
approach had been taken? 

-----------------------------------------------
7.2 Proprietary Extensions 

Should the "may" be a "should"? Otherwise, it could be interpreted as
suggesting that vendors may equally use other approaches?  

-----------------------------------------------
7.9 The icon Element 

(disclaimer - I may well be talking rubbish here as the following
comments are based on a _very_ basic understanding of graphics formats)

The text says that if the icon is vector format then the height and
width attributes will be used, however, isn't one the point of using
vector graphics that they could be re-sized to fit the available space.
Therefore shouldn't there be a statement saying that the widget user
agent MAY ignore these values? Equally should there be default sizes in
case the attribute is not used? 

In terms of raster graphics the text currently says "If the file pointed
to by the src is a supported raster graphic, this value may be ignored
by the widget user agent." but shouldn't the "may" in this case be a
"should"?

-----------------------------------------------
7.13 The feature Element 

In the sentence "The feature is used by an author to denote that, at
runtime, a widget may require access to a feature." the use of "may
require" is very slightly confusing given that the next attribute is
"required". Suggest changing "require" to "try to" or "attempt to". 

Likewise in the definition of the name attribute in the sentence "A URI
attribute that identifies a feature required by the widget at runtime
(such as an API)." change "required by" to "that may be used". 

-----------------------------------------------
8 Steps for Processing a Widget Resource

The sentence "The steps for processing a widget resource involves ten
steps that a widget user agent must follow, in sequential order,
responding accordingly if any of the steps result in an error." could be
slightly misleading as some of the steps are skipped depending on the
processing in a preceding step. I'm not sure if this is always in a
response to an error? 

A minor comment on section 8 as a whole - some of the steps have an
explicit link to go to the next step while others (like 9) don't. I t
would be nice if this was consistent. 

In addition, some of the algorithms, for example step 7, could be made
clearer by explicitly stating when to go to the next step (i.e. in case
of success in 7.1 and 7.2).

Finally, in Step 6 there is a sentence "Else, remove the last subtag of
the range and repeat this step 2.d. (e.g., if the range ...". Just to be
super clear perhaps "this step 2.d." could be change to "and go to 2.d
of this algorithm" 

>-----Original Message-----
>From: public-webapps-request@w3.org 
>[mailto:public-webapps-request@w3.org] On Behalf Of Arthur Barstow
>Sent: 28 January 2009 20:54
>To: public-webapps
>Subject: Reminder: January 31 comment deadline for LCWD of 
>Widgets 1.0: Packaging & Configuration spec
>
>
>A reminder for people interested in Widgets specs ...
>
>January 31 is the deadline for comments for the 22 December 
>2008 Last Call Working Draft of the Widgets 1.0: Packaging and 
>Configuration spec:
>
>  <http://www.w3.org/TR/2008/WD-widgets-20081222/>
>
>-Regards, Art Barstow
>
>Begin forwarded message:
>
>> Resent-From: public-webapps@w3.org
>> From: "ext Arthur Barstow" <art.barstow@nokia.com>
>> Date: January 9, 2009 1:38:51 PM EST
>> To: public-webapps <public-webapps@w3.org>
>> Subject: Request for Comments: Last Call WD of Widgets 1.0:  
>> Packaging & Configuration spec; deadline 31 Jan 2009
>> Archived-At: <http://www.w3.org/mid/E2D2E546-BB41-4380-BD22-
>> AC6D5245A7D6@nokia.com>
>>
>>
>> Bcc: public-i18n-core@w3.org, public-bpwg@w3.org, wai-xtech@w3.org, 
>> public-mwts@w3.org
>> Reply-to: public-webapps@w3.org (archived at [1])
>>
>> The Web Applications WG [2] explicitly seeks comments from the I18N, 
>> Mobile Web BP, Mobile Web Test Suites and WAI P&F Working Groups 
>> regarding the 22 December 2008 Last Call Working Draft of 
>the Widgets 
>> 1.0: Packaging and Configuration spec:
>>
>>  <http://www.w3.org/TR/2008/WD-widgets-20081222/>
>>
>> Comments from all others, including the Web Apps community are also 
>> encouraged.
>>
>> The comment period ends on 31 January 2009.
>>
>> -Regards, Art Barstow
>>
>> P.S. Note: Bcc was used to help reduce cross-posting. Please 
>send all 
>> replies to public-webapps@w3.org
>>
>> [1] <http://lists.w3.org/Archives/Public/public-webapps/>
>> [2] <http://www.w3.org/2008/webapps/wiki/Main_Page>
>>
>>
>
>
>

Received on Thursday, 29 January 2009 18:30:07 UTC