See also: IRC log
Date: 26 August 2008
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
<claudio> Fabio Ricciato
<MikeSmith> ArtB: if you have the phone set up, can you please call 1.617.761.6200 with code 26632 ?
AB: any change requests for the agenda
Josh: I won't be here on Thursday
Arve: I need to leave early
... want to push APIs to Wednesday
AB: any other change requests?
AB: anything from Kryztof we want to discuss?
MC: no; I will respond to his comments by end of next week
AB: I18N is done, right?
AB: Josh submitted some comments at the end of last week
MC: yes mostly editorial comments but 1-2 issues
AB: Josh submitted two
... 1. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0450.html
... 2. http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0451.html
... one issue is about proxies and we already identified that as an issue (#17)
MC: we decided the proxy used by an instance of a widget is an impl detail
JS: there is also an issue about the proxy and a signature
ABe: but we are signing the
... agree proxy is an implemenation detail
MC: we removed the requirement an
end user can specify the proxy
... since that is an implementation detail
BS: so what will the spec say?
MC: we no longer have a related
... We could have an informative note about it
... we are saying that if a Widget instance wants to use a specific proxy that's OK but we don't need our spec to saying anything Normative about this
AB: proposed Resolution: Issue
#17 is Closed - this is an implementation detail for Widget
User Agents; we may add an Informative note in one of the
... any objections?
RESOLUTION: Issue #17 is Closed - this is an implementation detail for Widget User Agents; we may add an Informative note in one of the specs
<scribe> ACTION: Barstow close Issue #17 [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action01]
<trackbot> Created ACTION-218 - Close Issue #17 [on Arthur Barstow - due 2008-09-02].
AB: are there any other comments in Josh's first email we want to discuss?
JS: no; but let's look at my 2nd email
<timeless> R40. Automatic Updates
<timeless> what happens if i have 3 instances of a widget? do they all get upgraded?
JS: the other issue is what happens when 3 instances of one widget are installed - what happens during auto-update?
<Benoit> they should...
ABe: I think this should be an impl detail
MC: I think all 3 should get updated
ABe: I don't think we should be
overly prescriptive here
... don't want to have to add a bunch of APIs to support this
JS: < reads Req #40 >
MC: I think we need to be flexible here
BS: could say the user should be able to check (when there are multiple instances installed)
AB: there is also the scenario of a device having more than one Widget UA
<arve> ABe: Could we add an informative note that a UA MAY treat two installations of a widget from a source URI as either two different widgets, or as two instances of one widget
AB: propose new Issue: should
text about auto-updates regarding multiple instances of
installed widgets be Informative or Normative?
... anyone object to this issue being addressed by Informative text?
MC: I object
... I don't think we should mention it at this point
... if Benoit or someone else provides some text, I can add it to the auto updates spec
<Benoit> ok to take it out
AB: propose Resolution: the reqs
doc will be silent on auto-updates and multiple instances
... any disagreements
RESOLUTION: the reqs doc will be silent on auto-updates and multiple instances (but some Informative text may be added to the auto-update spec)
AB: any other comments Josh?
JS: not to discuss now
MC: Marcos, can you commit to
responding to Josh's two email by the end of next week?
<scribe> ACTION: Marcos respond to Josh Soref's two e-mail comments by Sept 5 [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action02]
<trackbot> Created ACTION-219 - Respond to Josh Soref's two e-mail comments by Sept 5 [on Marcos Caceres - due 2008-09-02].
... unfortunately this is a Member-only link
... I don't like this
MC: it's because some of the WG's responses could include Member-confidential info
AB: what's the status?
MC: it contains everything but: 1) Krzystof's comments; 2) Josh' latest two e-mails
MC: re issue LC-1983 from Josh, Issue #1 is "should we mandate that developers and admins be allowed to
install their own certs?"
MP: this is related to req
... I submitted some comments about this to the mail list
... and proposed new text
AB: has this been addressed in the Editor's Draft?
MC: no; waiting for more input
ABe: I think the most we can specify here is a MAY
MC: this can be viewed as in impl detail of the Widget UA
MP: I agree it should be impl-specific
<timeless> propose Could the digital signature specification have an informative note that widget authors should not expect to be able to sign widgets using certificates which are not chained to well known public roots.
MP: but we don't want it to break
the security model
... If the requirement was removed from the Reqs doc that is OK
... from VF's perspective, we could remove it
MC: I propose "Additional Digital Certificates" (Issue #38 in the LC doc) be removed from the Reqs and it becomes an Informative note in the DigSig spec
AB: any comments or objections to Marcos' proposal?
RESOLUTION: Additional Digital Certificates" (Issue #38 in the LC doc) be removed from the Reqs and it becomes an Informative note in the DigSig spec
AB: what about the comments submitted by Frederick Hirsch (Chair of the XML Security WG) submitted on August 25?
MC: we have already addressed his
... they were both Editorial
... I will add his comments to the LC Disposition of Comments doc
AB: with the possible exception of Krzystof's comments and our responses raising some new Issues, I think we're mostly OK with the comments we received re the LC Reqs doc
MC: I will need to address the
URI and IRI references correctly
... it would be good to get a URI expert to review my changes
AB: any other comments we need to discuss?
MC: some of Krzystof's comments
are a bit academic
... but again, I will respond to all of his comments
<barstow> AB: we have Issues identified in the Editor's Draft
<barstow> ... as well as Issues defined in our Action and Issue DB http://www.w3.org/2008/webapps/track/
<barstow> ... Marcos, what is your preference for reviewing these issues?
<barstow> MC: let's first look at the issues in the latest ED
<barstow> ... I made an update during my flight from Brisbane
<barstow> ... I will upload it now ...
<barstow> AB: latest Editor's Draft is http://dev.w3.org/2006/waf/widgets/
<barstow> MC: we are restricted to the limits of ZIP as implemented and deployed today
<barstow> ... UTF-8 now supported in ZIP format
<barstow> ... can also now explicitly add an encoding
<barstow> MC: a question for us - which version of ZIP do we want to support?
<claudio> is conference 26632 expired? I cannot dial in...
<MikeSmith> claudio: yeah
<barstow> ... supporting the latest version of ZIP could add some additional problems and/or complexity
<MikeSmith> claudio: please use 26631
<barstow> MC: the motion is "we only support UTF-8 encoded file names"
<claudio> ok we're in
<barstow> AB: what happens if we make this a firm requirement regading existing impls?
<barstow> MC: I think Apple will fail
<barstow> ... when Dashboard widget is un-zipped on a Windows system
<barstow> MC: we don't have to add other encoding now; they can be added later i.e. in a subsequent version of the spec
<barstow> ABe: I think what we have currently spec'ed is OK
<barstow> AB: version of ZIP do we now support is what, Marcos?
<barstow> MC: 6.3
<barstow> ABe: frankly, we need an open spec for ZIP
<barstow> ... we shouldn't be blocked by PKWare
<barstow> MC: ISO is working on such a spec now
<Ralph> you folks have two teleconferences running and 1 person on each
<Ralph> I will attempt to move the person on the first teleconf to here
<barstow> MC: the motion is "UTF-8 and CP437" support
<barstow> MC: the I18N WG recommended this change
<barstow> MC: I propose step #8 of the ZIP Archive Verification step be left as is and we would not accept the change proposed by the I18N WG
<barstow> AB: any objections to Marcos' propsosal?
<barstow> RESOLUTION: step #8 of the ZIP Archive Verification step be left as is and we would not accept the change proposed by the I18N WG
<barstow> JS: should we explain why?
<barstow> MC: I already stated rationale in my response to Addison: <http://email@example.com>
<barstow> AB: issue is: http://www.w3.org/2008/webapps/track/issues/16
<barstow> MC: Tim Berners-Lee and some other members of the TAG have suggested we use http: scheme
<barstow> ... and we should not mint/create a new scheme
<barstow> MC: the UUID part of the grammar is a "straw man"
<barstow> TL: why not use a relative path?
<barstow> MC: in the DOM must have an absolute path
<barstow> TL: but an author of a Widget just needs to know relative path
<barstow> JS: but on different platforms, relative paths could be treated differently
<barstow> MC: widget developers are heavily discouraged from ever using absolute URIs
<barstow> ABe: the author can't predict the domain part of the URI (expect some type of UUID)
<barstow> AB: besides Tim, Stuart Williams and Roy Fielding (also on the TAG) also raised some concerns about the widgets: scheme
<barstow> ... Roy: http://lists.w3.org/Archives/Public/www-tag/2008Aug/0066.html
<barstow> AB: regarding the process, when the spec is ready to go to Candidate, if this issue is still Open, we will need to convince W3C Management the WG made the right decision to ignore this feedback
<barstow> MC: query strings are another part of the scheme that is an open issue
<barstow> MC: do we want to support POST?
<barstow> MC: I think Roy is over complicating the issue
<barstow> JS: Roy recommends "cid" scheme
<barstow> ... has anyone looked at it?
<barstow> ... At a minimum, we should look at it and respond
<barstow> JS: If you look at Roy's first statement, I think he's wrong.
<barstow> AB: perhaps he doesn't clearly understand our use case; seems like he is thinking about "web widgets"
<barstow> MC: our use case is taking files and put them in a ZIP
<barstow> TL: not sure it's good to make a differentiation between WebApps Widgets and "Web Widgets"
<barstow> MC: our approach is that a single file is transferred and transfer can come over Bluetooth, Infra-red, etc. but it doesn't necessarily need to be HTTP
<barstow> ABe: I agree there may be some work we can do to better define our use case
<barstow> TL: why not use "file"?
<barstow> JS: because file: has some issues e.g. security
<barstow> ABe: Widget authors could easily abuse file: and do some very bad things
<barstow> MC: the widget: scheme is supposed to create a sandbox
<barstow> TL: so we just want the Widget to only be able to access its own resources
<barstow> JS: cid: doesn't appear to be appropriate
<barstow> ... because it requires MIME support
<barstow> NA: the widgets scheme gives a security box, right?
<barstow> MC: yes, but some privacy too
<barstow> JS: the Widget UA needs to be able to expose to the Widget a unique resource that is related to itself (and nothing else)
<barstow> [We pause and look at R6: http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing Addressing Scheme and then continue discussion]
<barstow> JS: perhaps the requirement needs some additional text re uniqueness
<barstow> NA: I think there are some security aspects of the widget: scheme that are implied and perhaps should be more explicit
<barstow> ... perhaps the use cases need to be expanded
<barstow> CV: Stuart Williams asked for additional use case information
<barstow> CV: Stuart also asked about widget to widget communication
<barstow> MC: HTML5 is addressing document to document communication and presumably Widgets could leverage that mechanism
<barstow> ABe: I think using our own widget: scheme will help reduce security risks
<barstow> AB: so where does this leave us?
<barstow> MC: we need to clarify the model; it is based on the "old timers" in the WG
<barstow> ... I can clarify the text and address any ambiguities
<barstow> MC: we will have to continue discussions with the TAG
<barstow> ... I suspect they may have not actually read our spec thoroughly and don't understand our use cases
<barstow> BS: perhaps we can invite them to one of our voice confs
<barstow> AB: we can meet with them f2f in Mandelieu
<barstow> MC: I think we are doing the right thing and agree we need to continue to engage with them
<barstow> AB: I can invite Stuart and the TAG to one of our voice confs
<barstow> ... I think it would be helpful to first expand on our Use cases and Rationale
<barstow> TL: still think the distinction between Widgets and Web Widgets is causing confusing
<barstow> ABe: don't think of Widgets as web pages but a collection of resources that can be packaged and installed
<barstow> MC: I think the Web widget model and Webwag widgets are a different model; perhaps we'll get there in v2
<barstow> ABe: the widget: scheme will allow browsers to reuse their security model (sandbox)
<barstow> ACTION: soref respond to Roy Fielding's email regarding the widget scheme and his proposal to use cid: [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action03]
<trackbot> Created ACTION-220 - Respond to Roy Fielding's email regarding the widget scheme and his proposal to use cid: [on Josh Soref - due 2008-09-02].
<barstow> AB: do we need more motivational text?
<barstow> MC: I think we have already responded well enough
<barstow> ... I don't think the requirement needs to be updated
<barstow> AB: do you want me to invite Stuart and/or the TAG to our voice conf?
<barstow> MC: not yet; let
<barstow> ... us wait until Roy responds to Josh's e-mail
<barstow> [ the network is not capable of delivering the entire Editor Draft of the latest P&C spec thus I cannot add the text Marcos created re the URI query ... ]
<marcos> MC: how do we resolve: <content src="index#1.html?foo=bar"> ?
<barstow> AB: does this need to addressed for v1?
<barstow> MC: yes, I think so
<barstow> ABe: I think the example is a bit of an edge case
<barstow> AB: if we say query strings aren't allowed, what breaks?
<barstow> ABe: I tried your example in a couple of different browsers and they yield different results
<barstow> ... The question isn't about forbid vs. not forbid, but if query string should be supported
<barstow> MC: once we hit the "#" we don't say what happens
<barstow> ABe: one of the two user agents I tried has a bug; we should clarify in the spec
<barstow> MC: we should just say the value of the src attr is a URI reference
<barstow> ... I will also need to update the definition of the IRI attribute
<barstow> [ Marcos adds text to his latest ED that describes the results of our discussion: we don't chop stuff off the end but we don't interpret it either ]
<barstow> MC: need to add text about the encoding
<barstow> ABe: I would expect a UA to map any CP437 chars to UTF-8
<barstow> ABe: we could say anything outside of US-ASCII must be UTF-8
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
AB: agenda: http://www.w3.org/2006/appformats/group/TurinF2F
... I'm indifferent as to the order we discuss the issues
AB: issue #34 - http://www.w3.org/2008/webapps/track/issues/34
MC: we discussed this in IRC a
week or two ago
... we being me and Arve
ABe: I think this is an impl detail and a fatal error
JS: I want this to be a fatal
... I don't think a UA should limp along
... if it can't handle all of the files
ABe: if a UA canNOT represent all resources in the package, it must be a fatal error
JS: a UA could tell the user if there aren't enough resources and ask them to remove/stop something
AB: I'm not convinced we need to address this question
JS: there is no guarantee the user can be given a message before it dies
AB: what would we need to specify and in what spec would we address this?
MC: we could say something in the
P&C spec but probably nothing normative
... in the extraction phase, the Widget UA should stop the widget
... if there is a storage failure
AB: does anyone think this issue is important enough to submit an input to address the issue?
AB: I propose we close this issue
and say we will consider it for v2
... any objections?
ABe: I don't think this issue
should be handled by a spec
... but could be covered in some type of informational doc
RESOLUTION: we will close this issue for now (not critical) and we may consider it in the future
<scribe> ACTION: Barstow close Issue #34 with resolution above [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action04]
<trackbot> Created ACTION-221 - Close Issue #34 with resolution above [on Arthur Barstow - due 2008-09-02].
AB: issue is http://www.w3.org/2008/webapps/track/issues/46
MC: the issue is that part of the
widget should be author-able with Right-to-Left and other parts
... the proposal is a <span> element like the one in HTML
ABe: so this would mean the description element can support more than one span element?
AB: do any web browsers support this requirement?
ABe: how do I handle different descriptions?
MC: put each description in a different file
ABe: what attributes would be placed on <span>
MC: probably just direction
BS: why do we need <span> if localized text is placed in localized folders
MC: because authors may want to use both directions in a single description
AB: Marcos, you will spec the span element with just the one direction element?
MC: yes; plus need to change the parsing model
AB: I'm wondering about the burden to the UA
Marcos: ask I18N WG if Unicode RTL is sufficiently supported in UAs; if not we will include the <span> element in the Widgets spec
JS: HTML5 has a <bdo> element we should consider
ABe: I think we need some more solid research
AB: issue is: http://www.w3.org/2008/webapps/track/issues/20
[ Marcos demonstrates the issue by showing a Dashboard Clock widget as one instance and the Digital Clock "text" at the top tool bar ]
PB: in Java can have one application that has two different running instances - each with a different view e.g. presenation
MC: in the mobile world a single clock widget could take up the entire screen or just be a small piece on the idle screen
ABe: I don't want to have multiple content elements but perhaps provide APIs to control views
JS: on S60 the idle screen apps
cannot accept any input so they aren't really views in this
... an app can change modes e.g. full to small
... icons and notifications are covered elsewhere
... I think the answer to "can we have multiple <content> elements?" is no
BS: we need a way to suppport two
different views but those two views do not need to be
displayable at the same time
... I think that can be done with APIs rather than <content> elements
ABe: we support rendering widgets
in different "modes"
... with or without chrome and full screen and "dock mode"
... a problem with multiple content elements is how the instances communicate with each other
AB: I propose we close this issue now and put it in on the "consider for v2 list"
MC: I agree with that
AB: any objections?
RESOLUTION: Issue #20 will be closed and this feature will be added to the v2 Feature List
<scribe> ACTION: Barstow close Issue #20 with the resolution above [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action05]
<trackbot> Created ACTION-222 - Close Issue #20 with the resolution above [on Arthur Barstow - due 2008-09-02].
AB: issue is: http://www.w3.org/2008/webapps/track/issues/21
MC: some vendors have requested this feature
ABe: technically speaking, I
don't think this is difficult to implement
... but I do think some vendors with proprietary HTML extensions won't work very well
... I think this could be abused to make the default be an "upgrade here" message
CV: is this the same question as what a UA should do if an API isn't supported?
MC: no, I see it as different but related
BS: can we push this to v2?
MC: unless some vendor says it is mandatory for v1, I think we can push it to v2
AB: propose closing Issue #21 and
add it to the v2 Feature List
... any objections?
RESOLUTION: Issue #21 is closed and will be added to the v2 Feature List
<scribe> ACTION: Barstow close Issue #21 with the resolution above [recorded in http://www.w3.org/2008/08/26-wam-minutes.html#action06]
<trackbot> Created ACTION-223 - Close Issue #21 with the resolution above [on Arthur Barstow - due 2008-09-02].
<claudio> mission: providing means for accessing digital contents from everywhere via mobile
<claudio> WW definition of widget synthesize in single view lots of info
<claudio> WW is multiplatform, multidevice
<claudio> WW philosophy about Widget multidevice support: "smooth porting" rather than "write once/run everywhere"
<claudio> WW would like to support W3C spec as far as possible
<claudio> MC: will widgets be bound to server side for long time?
<claudio> WW: the installed widget mode might not scale...
<claudio> MC: deciding the balance between client and server is up to Widget implementors
<claudio> Arve: installed widget are more reliable in terms of security (signature)
AB: Meeting Closed
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 0.97) Succeeded: s/prose new/propose new/ Succeeded: s/we now support/do we now support/ Succeeded: s/page to page/document to document/ Succeeded: s/I think it/I think the example/ Succeeded: s/if a UA can/if a UA canNOT/ Succeeded: s/Addisson if/I18N WG if/ Found Scribe: Art Found ScribeNick: ArtB Found Scribe: Art Found ScribeNick: ArtB Default Present: +39.011.228.aaaa, Mike WARNING: Replacing previous Present list. (Old list: Art_Barstow, Marcos_Caceres, Mark_Priestly, David_Rogers, Fabio, Ricciato, Luca, Bruera, Benoit, Suzzane, Marco, Bartolini, Mauro, Sacco, Paddy, Byers, Lamorte, Thomas, Landspurg, Claudio, Venezia, Josh, Soref, Arve, Bersvendsen, Nick, Allot) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Art_Barstow, Marcos_Caceres, Mark_Priestly, David_Rogers, Fabio_Ricciato, Luca_Bruera, Benoit_Suzzane, Marco_Bartolini, Maruo_Sacco, Paddy_Byers, Thomas_Landspurg, Claudio_Venezia, Josh_Soref, Arve_Bersvendsen, Nick_Allot Present: Art_Barstow Marcos_Caceres Mark_Priestly David_Rogers Fabio_Ricciato Luca_Bruera Benoit_Suzzane Marco_Bartolini Maruo_Sacco Paddy_Byers Thomas_Landspurg Claudio_Venezia Josh_Soref Arve_Bersvendsen Nick_Allot Agenda: http://www.w3.org/2006/appformats/group/TurinF2F Found Date: 26 Aug 2008 Guessing minutes URL: http://www.w3.org/2008/08/26-wam-minutes.html People with action items: barstow marcos respond soref[End of scribe.perl diagnostic output]