See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 23 April 2009
AB: we will drop 3a. and 3c. since consensus for both of these was achieved via email after I posted the agenda. Will add a new agenda item about ECDSA. Are there any other change requests?
[ None ]
AB: Please remember to register
for the London F2F meeting June 9-11 (http://www.w3.org/2002/09/wbs/42538/WidgetsLondonJune2009/).
... the first voice conference of the Widgets Updates PAG is
tentative scheduled for 13:00 Boston time on April 28 (http://lists.w3.org/Archives/Member/member-widgets-pag/2009Apr/0002.html)
but Rigo Wenning hasn't yet confirmed that call.
... any other annoucements?
[ None ]
AB: on April 7 Mark submitted a relatively long list of comments (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0070.html). Frederick and Marcos responded. If addressing any of these comments could benefit from some discussion today, we can allocate some time. Frederick, what's the status?
FH: I think we've reached
consensus on most comments
... one issue is sig file
... I use "widget sig" rather than file
... I think both usages makes the most sense depending on
context
MP: I agree most comments have
been addressed
... but I still need to do some review
AB: let's drop this topic for today and take any followups on the mail list
AB: the ECDSA issue (captured reasonably well as Issue #81 http://www.w3.org/2008/webapps/track/issues/81) is still open. The latest ED does two related things: 1) it includes a note that requests feedback on ECDSA; 2) it also does NOT mandate ECDSA as one of the Signature Algorithms (and thus is a departure from latest WD of XML Signature 1.1). Today there was more discussion on this (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0279.html). One q
FH: I think we need some text
about it
... we cannot ignore it
... but we don't know what XML Sig 1.1 will decide
... using SHOULD may be a good way forward
... their risks with other algorightms so having an alternative
to consider
<drogersuk> I agree with FJH
FH: I do agree MUST is too strong
DR: I agree with FH
<Marcos> +q
DR: failure to indicate a roadmap is not a good path to take
MC: I understand the concerns
here
... if company X implements all of the algs except ECDSA and
then they get a widget with ECDSA, there is a prob
... if SHOULD is used it will effectively make it required for
the implementors
... it is expensive to implement to implement all of these
algs
... perhaps for v1.1. we could add support for new algs
... would like some real proof there is real market demand for
EC
... but without that evidence I don't support including
it
... think it should either be MUST or not in the spec at
all
DR: I understand your concerns
Marcos
... need to try to forsee future issues with a limited
set
... VF have made it clear they see it on their roadmap
FH: I understand the issues with
switching suites
... we are following this in XML Sec WG
... we see a demand from US gov't at least
MC: OK, that's good
information
... and in that case, perhaps it should be a MUST
FH: in XML Sec WG we are leaning
toward a MUST but are considering various concerns
... think SHOULD would be a good indicator
AB: agree SHOULD would be a
reasonable compromise
... we need to make it clear we want feedback from Implementors
as well as Developers
MP: as I said on the list list,
we think SHOULD is the best thing for now
... we can't use MUST at this point in time
MC: so let's go with SHOULD
AB: any additional comments?
[ None ]
<fjh> ECDSAwithSHA256
AB: propose a resolution: we will add ECDSA support as a SHOULD in the Widgets DigSig spec
<fjh> proposed resolution - add ECDSAwithSHA256 as should in widgets digsig
AB: any objections to my proposal?
[ None ]
RESOLUTION: we will add ECDSAwithSHA256 as a SHOULD in the Widgets DigSig spec
AB: the basic question is what, specifically, needs to be done before this spec is "feature-complete" and hence for Last Call WD publication? Frederick responded to this yesterday (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0261.html).
FH: one question is how to work
this with Sig Properties spec
... not sure how to work this out as a Chair
... maybe we take this offline
AB: my gut feel is your WG should publish Sig Properties
FH: we probably want a single annoucement
<scribe> ACTION: Barstow work with Frederick re synching Signature Properties spec with Widgets DigSig spec [recorded in http://www.w3.org/2009/04/23-wam-minutes.html#action01]
<trackbot> Created ACTION-335 - Work with Frederick re synching Signature Properties spec with Widgets DigSig spec [on Arthur Barstow - due 2009-04-30].
<fjh> agree, xml security should publish signature properties. need to coordinate however.
AB: are we Feature Complete?
FH: I don't think the reqs are in synch with the Reqs doc
MC: the problem is the links
point to the ED rather then what is /TR/
... we fix this when we publish these two docs in /TR/
AB: my recommendation is that
when we publish the LCWD of DigSig we also at the same time
publish a new Reqs doc
... are we done with functionality?
FH: I think yes
<mpriestl> +1
MC: yes
MP: yes
<darobin> +1 on top of mpriestl
RB: yes
MP: yes, just need to update ECDSA
<fjh> need to add ECDSA, possibly other minor editorial tweaks
AB: propose Resolution: the
Widgets Digital Signature spec is Feature Complete; we will not
add any new functionality
... any comments on that proposal?
... any objections?
[ None ]
DR: how would this affect schedule?
MC: I think this would put us ahead of scheudle
<fjh> please indicate the dates so that I can work with XML Security WG to publish Signature Properties
AB: we never agreed on specific dates but talked about LCWD in April and CR in June
RESOLUTION: the Widgets Digital Signature spec is Feature Complete; we will not add any new functionality
<fjh> so I will ask XML Security WG to agre to publish Signature Properties next week in XML Security WG call
<arve> we'll dial in anew
AB: I will start a new discussion on when to publish the LC of DigSig
<arve> we can't seem to dial in again
AB: that's it for DigSig for today. Thanks again FH for your great work here!
<mpriestl> + 1 on the thanks to fjh
<fjh> thanks, thanks Mark, Marcos
<fjh> as well
AB: Marcos proposed (http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0197.html) dropping screenshot for v1 and has already added it to the V2 feature list (http://www.w3.org/2008/webapps/wiki/Widgets2_UC%26R). My recollection is all comments on this proposal were positive. Does anyone object to this proposal?
<MikeSmith> ArtB: try again now
AB: any objections to dropping screenshot?
RB: no
RESOLUTION: screenshot will not be in v1 (already added to the v2 feature list)
<MikeSmith> Marcos: is it a local phone problem? or a problem with Zakim?
<MikeSmith> arve: trying calling back in now, if you can
AB: Robin made a short proposal several weeks ago (http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0943.html). There has been a little follow-up on the mail list but certainly no consensus on a solution. This is one of the major open issues that is blocking the publication of a new LCWD.
<MikeSmith> is P11 arve and Marcos ?
AB: Robin, where are we on this?
RB: I think we do have consensus,
the issue is on the wording
... I will create some tighter wording
... but feature wise, the comments have been positive i.e. at
the right level
AB: has your proposal been added to the ED?
RB: yes
AB: what's the next step?
RB: there really is no next
step
... just need to fix the wording
AB: any comments?
MP: I support the current
proposal
... there were some comments from BONDI
<mpriestl> * The User Agent's security policy MAY prevent network access by the Widget to an IRI that does belong to the set of target IRIs.
MP: my understanding of the
current proposal is the above should be a MUST
... rather than the MAY
RB: I'm not sure I understand
MP: I'll need to go back and re-read it
AS: the sec policy may be more restrictive about IRI access then the P+C's access element
MP: yes, I agree with that
... and hence the BONDI statement is correct
AB: Arve, Marcos - do you have any comments about the access element?
MC: no, we still need to review
it
... it appears to be a bit thin; may not cover all of the UCs
we have in mind
AB: please, everyone, send all
comments re <access> ASAP!
... anything else on this topic?
... what's the status of Thomas on this proposal?
RB: he may have some issues; not clear yet
AB: Marcos submitted a
comprehensive localization proposal (http://dev.w3.org/cvsweb/2006/waf/widgets/i18n.html)
several weeks ago. The amount of feedback has been very low yet
this is a major open issue that is blocking the publication of
a new LCWD. Currently, only me, Jere and Marcos have expressed
their opinions on the various proposals thus I'd like to hear
from other people.
... what do people think about this proposal from Marcos?
[ Silence ]
<mpriestl> (sorry I have to leave the call)
AB: one interpretation of silence is agreement with Marcos
AS: I haven't reviewed it yet
AB: we need feedback ASAP
AS: yes, I understand the priority
AB: what's the next step?
MC: I think we need more feedback
<scribe> ACTION: barstow seek comments from WG members on Marcos' L10N proposal [recorded in http://www.w3.org/2009/04/23-wam-minutes.html#action02]
<trackbot> Created ACTION-336 - Seek comments from WG members on Marcos' L10N proposal [on Arthur Barstow - due 2009-04-30].
AB: we can spend a lot of time on this today
MC: that would be good
AB: Marcos, lead us thru A1 and A2
MC: A1 has no support for
sub-lang tags i.e. it does not support BCP47 and its lookup
mechanism
... A2 supports BCP47 lookup
... A2 will reduce the amount of content that must be
localized, particulary if there are multiple levels of
sublangs
AB: so there is an efficiency tradeoff here, right?
MC: yes
... Jere and Josh both proposed A2 model
... note that A2 is already in the P+C spec
AB: any comments on A1 versus A2?
MC: I prefer A2
AB: I think we should give people
one more week i.e. until April 30 to provide input
... During the Apr 30 call we will decide on each proposal
MC: what if there is disagreement on the 30th
AB: a decision will be made on all of these by the 30th, if not earlier
MC: David, can we get any feedback from BONDI on the L10N model?
DR: there hasn't been any
discussion to this yet
... when do you need feedback?
AB: April 30 is the
deadline
... Marcos, can you provide a short description of B1 and
B2?
MC: B1 proposes the UA's locale
can be a list of locales
... B2 proposes the UA just have a single locale
... HTTP supports multiple languages
... The basic question is: does the UA support one lang or a
list of languages?
AB: any comments on B1 vs B2?
AS: so one use case is about knowing which langs a UA supports?
MC: yes
AS: I would expect the UA to have
a single locale but a widget could be localized in many diff
languages
... could then use prefs to manage this
... I can understand a UA support multiple locales but I'm not
sure this is the best way to go about it
AB: yesterday I suggested we need
some more reqs work and some more UC's to understand why need
this stuff
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0269.html
... will you reply to my comments?
MC: I think you have some good
comments
... we need to get this done as soon as possible
AB: yes, agree. But I also heard Andrew asking for some UCs too
AS: yes; some UCs and Reqs would be helpful in understanding the problems we are trying to solve
MC: some of the proposals do go beyond what current engines do today
AB: I get concerned about the
complexity here for v1
... we seem to be moving from codifying the existing cow paths
to building a new super highway
... Marcos, would you please give us a summary of the C*
proposals?
MC: these about deriving te
widget's locale
... diff between C1 and C2 is the order of searching for the
widget's locale
AB: I hope that is clear to
everyone; any questions?
... what about the D* proposals?
MC: these three proposals are
about how to represent the widget's locale
... my preference is D2
AB: any comments or questions on these 3 D proposals?
[ Discussion between Andrew and Marcos about D2 and various scenarios ... ]
AB: can we get a short intro to E, F and G proposals?
MC: E proposals are about XML Base and whether we use XML Base itself or our own emulation of it
AB: I agree E1 seems reasonable to me
AS: does that apply to all URIs?
MC: yes
AS: OK; that's good
MC: F proposal addresses the
"missing content" problem
... F1 uses root directory in search; F2 does not use
root
... My preference is F1
AB: yes, F1 seems reasonable to
me
... I think it works with the principle of least surprise
... please introduce G1 and G2 Marcos
MC: this is similar to F proposals but if the lookup is using URIs
AB: Robin, what is your level of interest here?
RB: unless someone wants to lead this, I will start working on it next week
MC: we are interested and willing to collaborate on anyone that wants to lead it
AB: I think the plan is for Robin
to start working on this spec next week and for MC to
help
... is that right?
MC: yes
RB: yes
AB: meeting adjourned
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/i just muted// Succeeded: s/but IPR is an issue/but are considering various concerns / Succeeded: s/fine// Succeeded: s/RB: what/AB: what/ Succeeded: s/MC: what/AB: what/ Succeeded: s/sublants/sublangs/ Succeeded: s/a single language/a single locale/ Succeeded: s/resolving/deriving/ Found ScribeNick: ArtB Found Scribe: Art Present: Art Frederick David Robin Marcos Mark Arve Andy Marcin Andrew Mike Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0258.html Found Date: 23 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/23-wam-minutes.html People with action items: barstow[End of scribe.perl diagnostic output]