See also: IRC log
Date: 7 AUG 2007
<scribe> Scribe: Anne
<artb> RRSAgent make logs member
<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
* Read Access Control for Web Resources
* XBL 2
* DFAUI (8 aug 1500-1800)
* AOB (fairly large)
AB: [Elaborates on the topics.]
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
... 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
... 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
... 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
... 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
... 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
... 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> (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.
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
MC: OCF has looked at both ZIP
... 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
ABe: remove CSS 1.0 because it is not really implemented
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
... if the manifest contains a proprietary element is the manifest non-conforming?
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
... 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
... 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
... 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
... 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
... 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
... 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].
<anne> also food (for people where they are not ===)
AB: Section 3.6. Digital Signature
BS: one question - should we use
... question 2 if we do use it, how do we use it?
MC: we've discussed this before; not sure there any good alternatives.
BS: PKCS#7 is a set of standards defined by RSA;
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
... 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!
This is scribe.perl Revision: 1.128 of Date: 2007/02/23 21:38:13 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Arve - mainly widgets/AB = Arve Bersvendsen/ Succeeded: s/AB = Arve Bersvendsen/ABe = Arve Bersvendsen/ Succeeded: s/Gorm - Web Apps; other projects/GE = Gorm Eriksen/ Succeeded: s/afraid/concerned/ Succeeded: s/Topic: Widgets/Topic: Widgets Requirements"/ Succeeded: s/Topic: Widgets/Topic: Widgets Requirements/ Succeeded: s/I see a lot that are server hosted/These are not concerned with server-side widgets?/ Succeeded: s/Widgets Spec/Widgets Requirements/ Succeeded: s/Widgets Requirements Requirements"/Widgets Requirements/ Succeeded: s/may be lots/are lots/ Found Scribe: Anne Inferring ScribeNick: anne Found Scribe: ArtB Inferring ScribeNick: artb Found ScribeNick: artb Scribes: Anne, ArtB ScribeNicks: artb, anne Present: Art Anne Guido Marcos Arve Gorm Bernardo Agenda: http://lists.w3.org/Archives/Member/member-appformats/2007Jul/0020.html Found Date: 7 Aug 2007 Guessing minutes URL: http://www.w3.org/2007/08/07-waf-minutes.html People with action items: 3.3 3.4 about add bernardo info marcos pkcs re-write references send will[End of scribe.perl diagnostic output]