WAF WG F2F Meeting in Cambridge, MA US — 5 Nov 2007

Introductions

<arve> I can't hear whoever's on now

arve, any better?

<arve> no

<danbri> I hear nothing

<arve> it's getting muted as noise half of the time

<danbri> lemme hangup see if it improves for arve

arve, I moved the mike, any better?

<arve> danbri: better

<danbri> (quite echoey still)

yeah: (

<danbri> (doc anne mentioned - http://www.w3.org/TR/access-control/ )

yeah: people continue to introduce themselves...

widget spec: http://dev.w3.org/2006/waf/widgets/

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

<danbri> Marcos, re the draft editors version, there is w3c boilerplate somewhere that says "Editor's draft" rather than "Working draft". Should be linked from pubrules...

<arve> I can't hear Art

<danbri> svg/webapps - http://www.w3.org/2001/sw/Europe/talks/200409-svgopen/

Artb: Just introducing the agenda for today and tomorrow.

<danbri> oh, echo gone... art did you do something different in last 10 seconds?

I moved the mike closer...

<danbri> thanks!

<arve> Marcos: are the slides up on slideshare yet?

<arve> Marcos: thanks

Artb: Anne and Marcos will do presentations on Access control, XBL, and widgets... after lunch we will talk about access control, at around 2-3 we will discuss widgets till the end of the day... tomorrow we will mostly be discussing widgets.

Charter renewal

<danbri> draft of new charter (linked from above): http://www.w3.org/2006/appformats/group/Charter

AB: Our charter states that we need to have a team contact, but since Dean Jackson left us we have been without one. Usually the team contact would help us with the charter.... I've circulated the charter and the working group feels the charter is fairly complete.

AvK: ... there has been talk of maybe merging with WebAPI

AB: yes, there has been some discussions about that, but nothing more.

<danbri> +1 on public fora :)

AB: art discusses some of the details of the new charter....
... ...we will try to complete the Access Control, the XBL, and widgets in the coming two years...
... art discusses the good standing rules as they relate to editors...
... Art finishes giving an overview of the charter.
... a question is asked about what other groups WAF will collaborate with.
... maybe with Open Ajax alliance, but we need to discuss this further.

<arve> I concur with Art's view here

AB: a small discussion takes place about Participation and the good standing rule...

<danbri> in my experience: many WGs end up being quite dependent on experts whose time is scarce, and who simply can't meet the formal good standing rules; i.e., the rules are widely ignored.

Overview of Enabling Read Access for Web Resources

<arve> Zakim: I am PP4

Access Control (Presentation)

UNKNOWN_SPEAKER: presentations slides will be put online later.

<arve> chaals: that the requirement remains as this WG has operated under

<arve> (correct me if I missed something)

<Lachy_> chaals, the good standing discussion just talked about applying the good standing requirement to editors only, rather than all members

DB: has this spec had a security expert review?

<danbri> has the spec had specific review from security experts?

<anne> yes

<danbri> ... example scenario, issues around mischievous intermediaries inserting headers; are we sure there are no new attack possibilities introduced here?

<anne> from Mozilla, Opera, W3C guys

AB: Dean and I spoke to TimBL about it, and he expressed some concerns. We have also had Thomas looking at it, who is a security expert for the W3C. We also have people from the Web Security Context WG....
... looking at it.

JF: I've also done a review of it from a security point of view. Open Ajax Alliance security people have also looked at it and have some concerns.

<danbri> Are the OAA concerns on the public record somewhere?

JF: I've looked at it, and I don't see any major problems

AB: thanks Anne.

Overview of XBL2

presentations: http://www.slideshare.net/mcaceres

see: W3C XBL 2.0 and Widgets 1.0

<danbri> (template model --- is that like XUL templates?)

<anne> Access Control for Cross-site Requests presentation: http://lists.w3.org/Archives/Public/www-archive/2007Nov/att-0023/cross-site-requests.htm

<Lachy_> http://www.w3.org/TR/becss/

<anne> complex example on inheritance: http://www.w3.org/TR/xbl/#mixing

<artb> AB: was inheritance part of sXBL, Jon?

<artb> JF: no it wasn't; we discussed it and could not get consensus thus it was removed

Overview of Widgets

<artb> MC: see http://www.slideshare.net/mcaceres

<artb> RC: is the widget packaging format overlapping work being done by the EXI WG?

<artb> HS: no, EXI is working on a compression schema for a single XML file, not an archive/packaging format

<arve> The definition of "Identifier" is currently unspecified

<danbri> who is it that has "tell widget"? yahoo?

<arve> FWIW, I think this should be left to the html5 wg

<danbri> I've wondered about a bluetooth-like "pairing" metaphor for interwidget comms, ... but yep if it can be done in html, so much the better

<arve> (Except specifying the origin and the discovery mechanism)

<arve> ok

<artb> HS: how does auto update relate to the HTML5 Google Gears offline?

<artb> MC: good question; we need to coordinate here with the HTML WG

<artb> RC: can you leverage XML Schema's versioning mechanism

<artb> MC: not clear we want to add the complexity of XML Schema

<artb> TR: perhaps the Widget's URI and the update URI could be combined (e.g. give the Widget URI version info)?

<danbri> something we wonder at joost, is where width/height should best live...

<artb> MC: agree we should consider something like this; think we need to work through some examples and do some experimentation

<artb> TR: does a widget have access to browser state e.g. cookies, etc?

<arve> I'm having problems hearing current speaker

<arve> someone give me a summary

<arve> ?

<arve> (Security concerns?)

<danbri> yeah, audio is not fantastic

<arve> Opera's security model has separation of both cache, cookies and storage for each individual widget

<artb> AvK: on opera the cache and state of the widget engine are separate from the browser

<arve> and said items are never shared with the browser

<danbri> so it is widgets until 12:00 boston time?

<artb> yes dan

<danbri> and a 25 min break now? ok

<arve> I'll call back in

<danbri> me too

<anne> arve, you still there?

<danbri> widgetty newsflash: http://blogs.joost.com/dev/2007/11/first_preview_release.html -- a dev build of joost that runs some opera/w3c widgets (chuck norris facts :)

<arve> anne: yes

<anne> arve, as it's getting late in Europe, anything you'd like to prioritize?

<anne> arve, there's about 45 min it seems

<danbri> did you start again?

<anne> almost

<anne> chuck norris facts, nice

see: again

chuck norris knows all

<arve> anne: obviously widgets

any section in particular

"Chuck Norris can divide by zero"

Widgets Requirements

<artb> MC: I haven't made significant changes recently

<arve> Marcos: you're dropping out

<artb> MC: lately I have started to fill out the Appendices

<artb> MC: now have a row in the table for Joost Widgets and Nokia's Web-Runtime

<artb> MC: also added a new table regarding configuration data

<artb> MC: also added an element types table with descriptions of the elements

<arve> I'm having trouble hearing the conversations because of echo and automuting

<danbri> i'm hearing everything twice

<danbri> could be

<arve> maybe

<danbri> i was muted locally

<anne> seems like it

<danbri> but zakim muting seems to fix it

<anne> maybe it was arve

<danbri> i'm happy asking Qs by Zakim

<artb> MC: some other tables are new e.g. API table

<artb> MC: also added a table of Properties and a table for Events supported

<danbri> we're talking about http://dev.w3.org/2006/waf/widgets-reqs/#appendix right?

<arve> Zakim: mute Arve

<danbri> to ask my Q in text, ... could you take care to capture something of the OpenSocial system recently proposed from Google? It's (like G. Desktop) based on Gadgets, but is more in the "social network extension" space

<artb> JF: this contains lots of useful info

<artb> AB: I agree and was wondering about moving the appendix table into a separate "Landscape" type doc

<artb> RM: I agree with that; the data will change quite a bit

Widget Versioning

<ferraiolo> Here is what OpenAjax is doing about versioning: http://www.openajax.org/member/wiki/OpenAjax_Hub_Specification_Libraries#OpenAjax.hub.registerLibrary.28prefix.2C_namespaceURI.2C_version.5B.2C_extraData.5D.29

<artb> MC: Arve, what about Debian regarding their versioning model?

<artb> ABe: I haven't found a detailed spec about Debian's model

<artb> JF: we discussed this at the OAA

<artb> JF: we use N.N.N and algorithms to compare

<arve> I can try to inquire with some of the Ubuntu developers

<artb> JF: we need this for our Ajax libs

<artb> JF: we also realize some people use text e.g. "beta" at the end

<artb> MC: we can make it quite open

<artb> MC: the other option is to follow Hixie's suggestion and just say "is it different?"

<artb> ABe: yes, knowing if it is different is indeed the important question

<artb> ABe: knowing the origin is also important

<artb> ABe: an important designing principle is easy for user to understand the model

<artb> MC: agree; I just need to know if something is new and don't care about the details

<artb> ABe: we allow user to download old versions of widgets but version numbers are created by the server and not the widget author

<artb> JF: client software e.g. browser or OS determines if there is an updated widget or not

<artb> JF: question is can everyone agree on this; think it may be futile to get such an agreement e.g. by MS, Apple, Google, etc.

<artb> JF: seems like its a bit premature to spec something that isn't settled in the industry

<artb> MC: I think something like FF and its extension model is a good working model

<artb> JF: but some models don't tell the user and do it behind their back

<artb> RM: need to go back to the question: why are the updates being done?

<artb> RM: until you understand that, not clear you can spec a good model

<artb> MC: we have an enumeration of some of the reasons in the Requirements doc

<artb> MC: agree we need to understand the user interaction model(s) being used by the major widget engines

<danbri> I'd suggest doing the signing/checking parts first, then coming back to versioning and auto-update (since doing the latter without the former is scary)

<arve> no

<danbri> (in terms or priorities i mean)

<danbri> artb: we have xml security spec maintainer coming tommorrow morning

<danbri> I meant in general, ... not in terms of this meeting

<artb> MC: we will specify how to sign a widget but actually doing so i.e. signing a widget would not be required

<artb> JF: good; don't make it required but do indeed support it

<artb> MC: could also use JAR as is being done by Joost

<artb> RM: also important to be able to uninstall the Widget

<danbri> re jar signer ... we're not 100% committed there, but yes having good supporting tools is v important to us

<artb> AB: but we don't actually state how to install a Widget

<artb> RM: what about widget dependencies, will they be spec'ed?

<artb> MC: nothing yet

<artb> AB: save that for v2 :)

<arve> will widgets be on the on the agenda at 15.00?

yep

<danbri> from my pov, having a solid treatment of I18N/L18N is one of the big selling points for adopting W3C specs

<arve> again: can zakim call in?

we will make sure it is set up

no, it can only call W3C team members

I was just told

<arve> ok

<arve> I'll stick around then

<danbri> I'm going to head off now, thanks for letting me join!

<sicking> Zakim: [Mozilla] is sicking

<sicking> Zakim: sicking is [Mozilla]

<sicking> Zakim: sicking is Mozilla

<sicking> doh!

<arve> sicking: zakim is really picky on the ','

<sicking> yeah, i forgot

<arve> I'd say that's a bug

<arve> marcos on his way back online

<arve> ?

<arve> I got a somewhat authoritative document on debian version numbers from an Ubuntu developer, http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

<artb> Scribe: ArtB

<Mez> http://www.w3.org/TR/access-control/

<MikeSmith> Observers and others present: Art, Marcos, Anne, Mez, FredrickHirsh, ThomasRoessler, YngvePettersen, IanFerry, JonFerraiolo, Roland, HenriSivonen, PhilippHallamBaker, DaveRaggett, HalLockhart, RogerCutler, Bill, Amit, KimDoan, Kangchan

<MikeSmith> On the phone: JonasSicking

<MikeSmith> Scribenick: MikeSmith

Access Control for Cross-Site Requests

anne: Hoping to rename the spec to this
... (as in Topic)

<artb> Anne's slides: http://lists.w3.org/Archives/Public/www-archive/2007Nov/att-0023/cross-site-requests.htm

[anne walking us through the slides]

[anne describing non-GET solution; see slides]

[now on Authentication request slide]

[now on final slide]

Hal: I think the term "authorization request" would be more accurate

<Mez> I'd particularly like to understand the security properties of the non get part

tlr: Hal is right

<Mez> but I haven't read the current draft; can anyone point me to a section?

tlr: You are describing a mechanism ...

<Mez> is Anne the only one who can answer me?

tlr: the current draft mixes at least two different protection goals ...
... the 2nd goal is to not allow cross-site posts, but with certain exceptions ...
... Is the current work on POST worthwhile at all? ...

Hixie: I had the exact same question ...
... implementors (specifically Mozilla) said they are "not willing to take the risk" of support cross-site posts

hal: What is the history that led to this?

<Mez> x site posts scare the heck out of me

artb: Origin of this work was from a Voice Browser WG note ...

<Mez> but I want to understand the security model before derailing anything more than IRC

artb: but use cases have expanded since then

Fredrick: Concerned about what the policy-enforcement point was ...

<Mez> "who" can perform the post? does it check both the identity and the origin of the call?

Fredrick: There's not state at the server, so it has to do its own access control in addition [to this]

JonF: [to Hixie] What exactly is Mozilla uncomfortable with?
... Does it come down to them being more comfortable if there were an authorization handshake?

Hixie: Yeah
... The attack being considered here is a cross-site scripting attack.

<sicking> i'm having trouble following the argument on phone, just following what's logged on irc

tlr: The differentiation we are making here is a very very weak one.

sicking: Cross-site posts are really scary.
... but you can't POST anything other than text/plain ...
... but XHR enables a lot more ...

<Mez> POSTing can be a web app command that does anything, right?

Henri: Is the assumption that site authors are clueful enough to be able to protect against POST but not about the other possibilities?

tlr: Should we be expending time on a processing model for this?

Hixie: problem is that browser vendors have already said they will implement proprietary mechanisms ...
... in the absence of any standard means

<Mez> I would like to understand that POST browser vendor issue more

<Mez> Why is POST important to GET for them?

<Mez> conceptual? usability? architectural? resource?

<tlr> It's a "safe" HTTP method.

<tlr> (See RFC 2616.)

Hixie: The feeling is that there are so many holes in the dam already, we don't want to add more.

tlr: The current processing model for POST in this spec is really bad
... cross-site POSTs has been around in XForms for years ...

<sicking> +q

anne: Yeah, but how widely used is that, and are they doing any security checks?

sicking: We do a secure check for XForms.

tlr: Is it documented anywhere?

sicking: Yeah, but I don't have the URL on hand

<sicking> -q

anne: Model is that before you perform the POST request, you use a GET request to perform an authorization request

<sicking> http://www.mozilla.org/projects/xforms/ReleaseNotes-20051026.html#c12

<tlr> thanks jonas

<sicking> hmm.. no, sorry, that's something else

<sicking> oh, no, it's right

<tlr> well, it sounds as if the security check is a local whitelist. Which strikes me as, umh, weak.

<sicking> it's basically just a whitelist

anne: Would need to have the GET authorization request for each URI

<sicking> tlr, we accept patches ;)

anne: The site is controlling whether the client is authorized to do a POST

Hixie: You can respond back with a list of domains that are allowed to do a POST

<sicking> +q

tlr: This effectively means that the authorization policy is communicated back by use of at least two HTTP headers and a processing instruction
... looks a little bit messy
... Could put it all in the Access-Control header

sicking: We have a preliminary implementation ... but can change it

<Hixie> (the briefly mentioned proposal was to move the method from Allow: to the Access-Control thingies)

sicking: we definitely need some sort of algorithm for [handling this problem case]

<Hixie> (as in <?access-control allow=... allow="post")

<sicking> -q

<anne> <?access-control allow="foobar.com" method="POST"?> ...

anne: We want to publish this as soon as possible

tlr: question about DELETE and other methods ...
... this is driven by the assumption that there are use cases for cross-site requests ...

Hal: We need more details about what threats you are trying to deal with

anne: I'm open to contributions.

artb: We would be happy to have an editor to write the Primer for this spec.

<Marcos> stride info: http://msdn.microsoft.com/msdnmag/issues/06/11/ThreatModeling/default.aspx

JonF: I think it's incumbent on W3C an this WG to convince yourselves that this is not opening up any new security holes.

<Mez> how could this not open new security holes?

JonF: I'm not sure that you have yet gone through and looked at POST [as carefully as needed]

<Mez> just adding this sort of complexity will create new browser bugs

<Mez> but perhaps you mean "if it is implemented perfectly"

hsivonen: Question: What happened with the GET vs OPTIONS debate?

<sicking> +q

hsivonen: GET interferes with HTTP caching ...

<tlr> +1 to not using GET there, also given the side-effect-heavy use on the street

hsivonen: if you are for example doing something like validator.nu does, I would prefer to [do the less expensive thing if possible]

Hixie: You know it's an access check because it has an extra header
... Problems with OPTIONS are that by default Apache returns an Allow header with everything in it ...
... the much bigger problem is that you don't get to run a script with OPTIONS ...

sicking: OPTIONS is more for checking server capabilities ...

hsivonen: Argument for using OPTIONS is that this use case does in fact meet the intended purpose of OPTIONS
... so option doesn't interfere with GET caching and using OPTIONS allows early dispatch to allow running the computation you would run on a normal GET

Hixie: If I can't write a ten-line script in Apache to make this work, then the spec is broken.

hsivonen: It would be easier to respond to OPTIONS than a GET
... it has not yet been researched that OPTIONS cannot be responded to

Hixie: I've actually done quite a bit of research on it.

sicking: Needs to be simple
... simple from the server side

Mez: I would really like to understand why browser vendors need for this spec to apply to POSTs?
... what are the use cases for allowing cross-site POST?

sicking: A use case for this is Google Calendar
... you could POST data in order to insert calendar entries ...

<fjh> in another persons calendar, with authorization

<Mez> I wish there was a less flexible way to enable very straightforward uses like the use cases discussed

<anne> why less flexible?

<fjh> in a stateless server REST world?

<Mez> because the flexibility will enable combinations that will allow for new attacks we haven't thought of

Hal: Should make it clear that this spec is in addition to any other access-control mechanisms.

<fjh> +1 to hal

<tlr> +1 to hal and fjh as well

<Mez> I'd be willing to place a bet on that; a pitcher of beer (or equivalent), within 6 months of substantial deployment

tlr: many good reasons for not overloading GET

Hixie: I agree but I think the onus should be on the person proposing an alternative to show how a 10-line perl or python (or whatever) script can implement the alternative.

<fjh> +1 tlr, to seriously consider using OPTIONS in place of GET due to caching issues, etc

Hixie: The problem that Google has with the first option is that we are likely to have a very long list of domains ...

<sicking> -q

Hixie: problem with OPTIONS is you can't do it simply on the server side ...

<Hixie> (specifically, implementing OPTIONS (or anything other than GET or POST) on a simple Apache setup appears to be non-trivial)

<tlr> well, hixie, that problem can be solved by writing one module and distributing that, no?

Roger: Problem of me giving a permission to an app to do something, but not knowing exactly what that app wants to do.
... or is it that you are not giving the app permission do anything, but you are giving it permission to try.

Hixie: Exactly.

tlr: Two authorization decisions, one at the client side, one at the server side, and we are dealing only with the one on the client side.

PHB: I respect the reason why we should make it work with deployed UAs ...
... but not that we should make it work with currently deployed Apache ...

<sicking> my worry with the current design of GET requests that include Referer-Root and Method-Check is that a HTTP cache sitting between the browser and the target server could cache a authorization-check (either a denying or allowing). When a subsequent authorization request is made to the same uri the HTTP cache will reply with the same decision, even though the Referer-Root and/or Method-Check...

<sicking> ...header is different

PHB: just get root and update your Apache ...

<sicking> This could be solved either by not having Referer-Root and Method-Check, forcing the full ACL to always be included. Or using OPTIONS, which won't get cached

<PHB> SAML=Security Assertion Markup Language, an OASIS standard

<PHB> WS-* = WS-Security and a suite based thereon, OASIS, W3C specifications.

<fjh> http://www.oasis-open.org/apps/org/workgroup/security/#samlv20

Hixie: I, like many other thousands of people, use a hosting provider that allows me to run CGI scripts, etc. but I don't have access to update the Apache instance running on that server

PHB - thanks

<fjh> http://www.oasis-open.org/specs/index.php#wssv1.1

hsivonen: There is an issue of whether to expose the content that the UA already got ...
... but the other issue ... the POST authorization ... there really isn't any trust model ... it's just a matter of whether the server knows whether this kind of case actually exists or not (whether the developers of the server are clueful [about current technology] or not ...

anne: I'm interested in hearing more about the caching issues.

<anne> sicking explained that above apparently

<anne> sorry for not following that more carefully

<anne> so evil.com -> example.org (denied, cached); good.com -> example.org (denied, because it's cached on the intermediate thingie)

<anne> s/tir/tlr/

tlr: we are talking about a deployment where this won't get widely deployed in browsers until 2 or 3 years ...
... [so why will not Apache get updated also in the mean time]

hsivonen: There are many cases where [Apache updates to deal with browser changes lag behind by many years]

<hsivonen> rather, there are cases where browsers have had to work around apache limitations due to apache opting not to fix

<Hixie> btw the completely undocumented ScriptTrapOptions is how you are supposed to be able to enable OPTIONS for cgi on apache

<Hixie> according to my research

sicking: We can't count on Apache making fixes any time soon ...

anne: I don't really see a better way than the current GET thing.

<artb> ACTION: Barstow seek input from the HTTP WG re the Read Access spec [recorded in http://www.w3.org/2007/11/05-waf-minutes.html#action01]

<trackbot-ng> Created ACTION-131 - Seek input from the HTTP WG re the Read Access spec [on Arthur Barstow - due 2007-11-12].

tlr: This working group should specifically solicit feedback on this from the HTTP working group

http://library.pantek.com/Mailing%20Lists/httpd.apache.org/bugs/02/12/4502.html

<artb> public-appformats

artb encourages everybody to continue discussion of the on the mailing list

artb thanks to Mez for sharing folks from the WSC WG for this session

<arve> going directly to widgets?

<Marcos> arve, if you are there, we can probably start

<arve> Marcos: here now

Widget Zip

<artb> Scribe: ArtB

MC: want to talk about ZIP format

AB: spec is here: http://www.w3.org/TR/widgets/

<MikeSmith> http://www.w3.org/TR/widgets/#zip-archive

<MikeSmith> Scribenick: artb

<scribe> Scribe: ArtB, MikeSmith, Marcos, Anne

JF: when a file is created author can choose standard Zip or the 64 bit extensions

MC: and engine should expect either format

ABe: concerned about use of MAY (section 2.5)
... what is the requirement for supporting 64bit?

MC: author can use 64bit even for small (=3 bytes) file
... Jon's after some future proofing

ABe: are there any problems with this?

MC: Windows Vista doesn't support it
... not sure about Mac OS

AB: if there is no evidence of widespread support I would remove it

MC: I've been talking to InfoZip people

ABe: I tend to agree with Art on removing this requirement

MC: Jon, do you have any comments?

JF: I didn't realize it wasn't widely implement so I tend to agree with Art

MC: I will add a "red block" and state that this requirement will be deleted unless there are compelling use cases and demonstration of wide-spread implementation

ABe: I'm generally OK with the other requirements in section 2.5

<arve> is it possible for Jon to move closer to the mic?

<arve> he's getting cut off a lot

CV: I'm OK with section 2.5; I see this as mostly a platform vendor problem
... is there any other real option?

MC: well "tar" is one option

JF: ODF chose Zip; Open Office format also uses Zip

<arve> Zakim: mute [Arve]

Widget Extensibility

AB: comment recently: http://lists.w3.org/Archives/Public/public-appformats/2007Nov/0003.html

MC: the general idea is to standardize an "ext" directory for extension files

ABe: not clear why this is needed

MC: tend to agree
... additionally potential issue with security e.g. if using non-HTTP protocol
... The spec does not preclude this from happening

<scribe> ACTION: Marcso to respond to Richard's extension proposal [recorded in http://www.w3.org/2007/11/05-waf-minutes.html#action02]

<trackbot-ng> Sorry, couldn't find user - Marcso

<scribe> ACTION: Marcos respond to Richard's extension proposal [recorded in http://www.w3.org/2007/11/05-waf-minutes.html#action03]

<trackbot-ng> Created ACTION-132 - Respond to Richard's extension proposal [on Marcos Caceres - due 2007-11-12].

ASCII names and UTF-8 names

MC: Zip has some limits regarding length of filenames, nesting directory levels, etc.

ABe: some other issues too like characters permitted in filenames
... e.g. need to exclude some specific characters

AB: is there a model we can leverage?

MC: yes, OCF

RM: someone must have already done this

<arve> There are also restrictions on domain names we could look at

<arve> RFC 3492

<arve> http://tools.ietf.org/html/rfc3492

ABe: RFC3492

File extension and Media Type

ABe: problem with the 3rd paragraph

<Marcos> "It is recommended that a widget resource is served over HTTP with the .wgt file extension in lower case."

<arve> If a widget user agent encounters a resource with an invalid Media Type, but with a .wgt files extension, the resource is in error and the widget user agent should not attempt to process the resource.

<arve> My proposal is to change "should not" to "must not" in this case

JF: expect file system to handle file extensions properly e.g. invoke the appropriate handler
... may want to look at what SVG specifies

MC: OK, I will do so
... I'm wondering if we should specify some type of content sniffing algorithm

ABe: we used to do something like that but not any more

JF: is the config file mandatory?

MC: yes, I think so

ABe: canvas defaults to 300x150 if not specified

AB: regarding is the config file mandatory, section 2.2 says no.
... regarding should we specify anything regarding content sniffing, I think we should be silent.

ABe: there could be some security issues with sniffing

MC: perhaps then we should say only process the Zip if it has a .wgt extension.

AB: we need to a time check
... tomorrow we will continue with section 3.
... Meeting Adjourned for today; see you tomorrow @ 09:00.