WAF WG f2f Meeting in Oslo -- 7 Aug 2007

Date: 7 AUG 2007

<scribe> Scribe: Anne

<artb> RRSAgent make logs member

<artb> Agenda: http://lists.w3.org/Archives/Member/member-appformats/2007Jul/0020.html

Introductions

<artb> AB = Art Barstow

<artb> MC = Marcos Caceres

[People introduce each other. Not scribed.]

<artb> ABe = Arve Bersvendsen

<artb> AvK = Anne

<artb> GE = Gorm Eriksen

<artb> BS = Bernardo

<artb> GG = Guido Grassel

<bernardo> bernardo - opera browser widgets module development

Meeting topis

* Widgets

* Read Access Control for Web Resources

* XBL 2

* DFAUI (8 aug 1500-1800)

* AOB (fairly large)

AB: [Elaborates on the topics.]

Widgets Requirements

http://dev.w3.org/2006/waf/widgets-reqs/Overview.html

<marcos> http://www.w3.org/TR/widgets-reqs/

MC: goal is to clarify what widgets is in this specification as much as possible

<mikko> Hi artb, all, I'll be on irc most of the time.

MC: looking into what the enterprise requirements are for widgets
... I added requirements for what widgets engines in theory should support
... Wondering what Opera's position is on the requirements document?

ABe: The requirements document makes sense to me as well as template for the specification.
... It concerns me how it restricts vendors
... As long as it doesn't do that it seems fine

MC: It's not my intention to limit anybody
... If it turns out that the specification contradicts the requirements document we might change the requirements document.
... The specification sets the requirements on vendors, not the requirement document.

AvK: I'm concerned that the requirements document prevents progress on the specification

Widgets specification: http://dev.w3.org/2006/waf/widgets/Overview.html

MC: I think I'm sort of done with the requirements document so I can focus more on the actual specification

AB: I'm concerned about the recommended solution part

[... something the scribe missed ...]

ABe: I agree that we should probably not put the recommended solutions into the requirements document.

AvK: maybe we could rename the document to make it some type of "design" document

MC: I'll take out the recommend solutions stuff
... document can be considered frozen

ABe: the requirements document could point to the specification
... If the specification already has a solution

GG: I think it should just be taken out

RESOLUTION: recommended solutions will be taken out of the requirements document

MC: AvK said it should be note, I think it should be a spec (W3C Recommendation)

AB: There's certainly a precedent for req docs to go to W3C Recommendation
... Also vice versa

MC: I'm fairly happy with it

GE: what would be the next step?

MC: working on the specification

AB: I'd like to resolve a few of the TODOs
... in the reqs doc

AvK: I don't see any

MC: Market-Leading Widget Engines

GE: These are not concerned with server-side widgets?

AB: lets make market-leading widget engines a list of examples

MC: Other issue: relationship to Java Applets

AB: What accessibility requirements should we make?

GG: We don't say anything about the UI
... Bert raised the issue that we should say what language it is

ABe: Accessibility has to be dealt with in the UI language, such as HTML5

MC: The UI language should be in line with the accessibility guidelines

AB: We're not trying to create too much new specifications
... More codifying what's already done

MC: [shows how OCF handles with accessibility]

AB: I think the design goals are good; I would not consider it a requirement for us to have explicit references to design goals

AvK: I'm not sure they are to be listed; they are all obvious

ABe: I want to know what "device independent" means
... run the same everywhere? different interaciton models allowed?

MC: context here is rendering

AvK: why would rendering have to be the same?

MC: if you give an initial position and don't consider all target devices it may end up too small or too big

ABe: Using media queries to determine the initial rendering dimensions
... for instance, give the dimsions based on DPI
... I'd feel better if the example in r20 is removed

MC: I'll provide a rationale for it; I'll mention how Y! uses XML for that

<artb> Scribe: ArtB

<anne> http://dev.w3.org/2006/waf/widgets/Overview.html

<anne> (latest editor draft of Widgets 1.0 ^^)

AB: I would remove the ToDo for the SSL requirement

MC: OK, I will do that

AB: regarding the Proxy and SOCKS requirement - what about a reference?

AvK: I think Proxy is defined by the HTTP spec

MC: yes that's probably true but what about Socks?
... I think it different from Proxy.

ABe: I would drop Socks

<anne> ScribeNick: artb

MC: OK; will change title to Proxy Support

AB: OK, that's all the requirements what about the Appendix Marcos?

MC: I will probably delete it from the final version.

AB: I think it is useful info but don't feel strongly

GG: I think the data is useful if the data is updated

MC: one way to handle is it for me to write a separate doc/paper and then reference it.

Widgets Spec

<marcos> http://dev.w3.org/cvsweb/~checkout~/2006/waf/widgets/Overview.html

<anne> http://dev.w3.org/2006/waf/widgets/Overview.html

MC: I removed the old Introduction and put in some Red Blocks
... that indicate some material that needs to be added

AB: re section 1. - what is OCF model?

MC: the OCF spec digs into the details of ZIP
... I think we should look at it again.

AvK: I think it makes more sense to see what Widget implementations are doing?

MC: a problem is there is no thing as "normal ZIP"; ZIP spec is now 6. and most implementions are at level 2. or so
... The ZIP spec continues to evlove.
... If we want 64-bit support we must move version 4.5 of the ZIP spec.
... GZIP is RFC 1952 and is over 10 years now

ABe: if you implement ZIP spec must pay royalties to PKWare, I think.

<scribe> ACTION: marcos to determine the royalty situation for implementing ZIP; Art to help if needed [recorded in http://www.w3.org/2007/08/07-waf-minutes.html#action01]

<trackbot-ng> Created ACTION-101 - Determine the royalty situation for implementing ZIP; Art to help if needed [on Marcos Caceres - due 2007-08-14].

BS: open source implementation cover GZIP, not the ZIP spec

<marcos> http://www.pkware.com/documents/casestudies/APPNOTE.TXT

MC: OCF has looked at both ZIP and GZIP
... I'm OK with dropping back to ZIP v2 and not including 64 bit support

AvK: we want to use the simplest royalty-free spec

AB: and that means GZIP RFC1952, right?

MC: yes; but I still need to research the relationship between RFC1952/GZIP and ZIP.
... next is list of specs a UA must support

ABe: change XML 1.1 to 1.0

MC: OK

ABe: remove CSS 1.0 because it is not really implemented

MC: OK

AvK: not sure we need to enumerate the dependencies in this section

AB: what does the spec say about mandatory icon support?

AvK: says PNG, GIF87 and GIF89 are mandatory

MC: one way forward is to keep the list and then at the end we may end up deleting it

<scribe> ACTION: marcos add references to section 1.1.1 [recorded in http://www.w3.org/2007/08/07-waf-minutes.html#action02]

<trackbot-ng> Created ACTION-102 - Add references to section 1.1.1 [on Marcos Caceres - due 2007-08-14].

AB: section 1.2 Extensibility

GG: what is an extension in this context?

AB: who is the Actor?

ABe: the Actor is the Widget author
... if the manifest contains a proprietary element is the manifest non-conforming?

MC: yes

AB: I don't like that
... need to separate two issues: non-conforming packaging format and non-conforming manifest

MC: I will move the statement about non-conforming packaging format extensions to another section
... the question about the manifest containing proprietary extensions is handled in the processing model in section 4

AB: moving to section 2 Widget user agent initialization

MC: I am working on an experimental implemenation of a localization model
... using JavaScript
... Apple uses the same localization model for Widgets that it uses for native applications
... Microsoft also has one localization model
... Dashboard uses a lang-specific folder e.g. en_us for its localizable resources and strings file

ABe: I think that model adds too much complexibility for the author

MC: at run-time the Dashboard engine loads the appropriate resources and strings based on $LANG

GE: I think a model like that seems to make sense
... seems quite flexible and powerful

MC: want a model where only the localizable content is put in the localizable directories

ABe: want the library to take care of localization

AvK: we should focus on the 80% use cases

<anne> (In light of that statement it might be relevant to point out that MC said this would not be relevant for 99% of the widgets.)

AvK: I am in favor of standardizing the basics first
... and hold back on localization until a good proposal is contributed
... and agreed.

AB: is there a precedence for Localization at W3C?

AvK: no there isn't

AB: Section 3. Widget Package
... who is willing to write the Media type appendix?

AvK: we should wait until after the Security model is documented/completed.

MC: what about the .widget extension - is this OK?

ABe: some systems are limited to 3-char extensions. I prefer .wgt.

MC: that's OK with me. Any objections?
... No objections, extension name changed.

AB: Section 3.1 ZIP Support

MC: what about non-ASCII support for file names? Is it needed?
... Consensus: US-ASCII support is sufficient
... the list is from the OCF spec; we have now made some changes that make us incompatible with OCF.

AB: where did the stuff about byte 38 come from?

MC: that is from the OCF spec. I will remove it.

AB: Section 3.2. Bootstrapping

MC: I will remove this section given we now have no plan to define Localization strategy.

AB: Section 3.3. Structure of Archive

ABe: seems like this would be more readable if used pseudo code rather than lists and sub-algorithms

MC: I think the main logic is there but some definitions are missing

AvK: the intent is the start file is defined in the config.xml
... if that fails, it will use the fallback (files)
... if that fails the Widget is useless.

GG: here is the algorithm as I see it:

1. If /config.xml and has start file -> use it

2. If */config.xml and it has start file -> use it

3. Check for start file in / and use it if found

4. Check for start file in */ subdirs (1 level deep) and use it if found

5. Fail if #1-#4 result in no start file found

GG: I am concerned about what happens if <root> has two subdirs and each has a config.xml file.
... Which one wins?

<chaals> [/me notes that SVG has a switch test on system-language that is used for localisation]

ABe: the winner can be alpha-betical order.
... We already said US-ASCII is required for file names

<scribe> ACTION: Marcos will re-write 3.3 and 3.4 to use a more prose-like style yet maintain the same results as the current algorithms [recorded in http://www.w3.org/2007/08/07-waf-minutes.html#action03]

<trackbot-ng> Created ACTION-103 - Will re-write 3.3 and 3.4 to use a more prose-like style yet maintain the same results as the current algorithms [on Marcos Caceres - due 2007-08-14].

<chaals> ping

<anne> prolly

<anne> also food (for people where they are not ===)

AB: Section 3.6. Digital Signature

BS: one question - should we use XML Signature?
... question 2 if we do use it, how do we use it?

MC: we've discussed this before; not sure there any good alternatives.

<bernardo> pkcs#7

BS: PKCS#7 is a set of standards defined by RSA;

<bernardo> http://en.wikipedia.org/wiki/PKCS

MC: it appears RSA has some patents on PKCS
... RFC 2315. "Used to sign and/or encrypt messages under a PKI"
... Used also for certificate dissemination (for instance as a response to a PKCS#10 message). Formed the basis for S/MIME, which is now based on RFC 3852, an updated Cryptographic Message Syntax Standard (CMS).

BS: tools for XML Signature not readily available

GG: but a colleague of mine sent a tool to the mail list

BS: not clear how to use XML Sig e.g. what needs to be signed - each file, all of the files

GG: the spec says can sign all or any number of files

BS: I wonder about the performance, particularly on a mobile device
... especially if have to process many files

MC: I would like to see some data from vendors about XML Signature versus PKCS
... Also want to see the differences between the algorithms the two specs require.

BS: there are lots of tools for XML Signature on desktops but not sure about mobile platforms.

AvK: not clear the XML overhead is worth it

<scribe> ACTION: Marcos analyze the PKCS format and comapre with XML Signature [recorded in http://www.w3.org/2007/08/07-waf-minutes.html#action04]

<trackbot-ng> Created ACTION-104 - Analyze the PKCS format and comapre with XML Signature [on Marcos Caceres - due 2007-08-14].

GG: I don't understand what it means in practice to only sign parts of a Widget.

BS: should be able to support a signed component.
... The component can then for example access private/critical resources.

GG: How do you ensure the untrusted parts do not take advantage of the trusted component?

MC: I think it makes most sense to just sign the ZIP (and not all of the files).
... Like Yahoo! and tack on a signature.

ACTION Bernardo send info about PKCS to the mail list

<scribe> ACTION: Bernardo send info about PKCS to the mail list [recorded in http://www.w3.org/2007/08/07-waf-minutes.html#action05]

<trackbot-ng> Created ACTION-105 - Send info about PKCS to the mail list [on Bernardo Sampaio - due 2007-08-14].

BS: I want to minimize overhead and I think XML Signature is too high

AB: meeting adjourned for today!

- DRAFT -

WAF WG f2f Meeting in Oslo
7 Aug 2007

Attendees

Contents

Introductions

Meeting topis

Widgets Requirements

Widgets Spec

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

WAF WG f2f Meeting in Oslo 7 Aug 2007

Attendees

Contents

Introductions

Meeting topis

Widgets Requirements

Widgets Spec

Summary of Action Items

Scribe.perl diagnostic output

WAF WG f2f Meeting in Oslo
7 Aug 2007