See also: IRC log
<scribe> Scribe: Art
<scribe> ScribeNick: ArtB
Date: 19 November 2009
<drogersuk> I can't hear anything either
<arve> neither do I
<drogersuk> that's better
<arve> now, I'm at least hearing ArtB talk
<Steven> Doug and I keep ending up on the same call, but no one else
<marcin> Marcos, :)
<Marcos> Marcin, quickly check out the email I just sent you
Steven, Doug - we're all here on 9231
<Steven> Doug and steven on a separate call again
AB: draft agenda is
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0763.html
... any change requests on the agenda?
<marcin> Marcos, long email :). I think option 3 should win, but I need to check what parameters we may have. I will respond shortly.
AB: any change requests on agenda?
[ None ]
MC: can we add Marcin's regarding P&C?
AB: yes
AB: No Voice Conf on 26 November;
next one will be 3 December
... Reminder: last day to request publications for 2009 is
Friday 18 December
... WebApps has been asked to submit comments re OASIS'
Packaging spec for ODF for Office Apps spec; see ( http://www.w3.org/mid/4B016692.2090408@w3.org
) for details
... Doug, anything to add?
DS: they are using ZIP too
AB: if there are comments, send them to the OASIS list
DS: if need clarification on list, let me know
AB: any other annoucements?
[ None ]
DS: I am on the ODF Tech
Committee
... my main reason is SVG
... but I can be a pipe for other ODF comments
SP: I will also join the ODF TC but not as a W3C rep
AB: November 19 is the last day
to submit comments re P&C LC#3 ( http://www.w3.org/TR/2009/WD-widgets-20091029/
).
... the comment tracking document is (
http://www.w3.org/2006/02/lc-comments-tracker/42538/WD-widgets-20091029/
). Marcos, that document must be up to date before the
Director's call.
... the Director's call is tentatively set for Nov 23
... Marcos, which comments still lack a WG response? My count
is 5 total: 2 from Marcin (
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0711.html
and
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0750.html
), 1 from Ericsson (
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0567.html
), 1 from Scott Wilson ( http://lists.w3.org/Archives/Public/public-w
ebapps/2009OctDec/0808.html ) and 1 from Benoit ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0469.html ) .
AB: let's make sure we are all on
the same page re these comments
... what's the plan to populate the CT doc?
MC: I'll start tomorrow
... Benoit's is open
<scribe> ACTION: benoit close the loop on your P&C comment [recorded in http://www.w3.org/2009/11/19-wam-minutes.html#action01]
<trackbot> Created ACTION-458 - Close the loop on your P&C comment [on Benoit Suzanne - due 2009-11-26].
AB: it appears Ola is OK with your response Marcos?
MC: yes
AB: we need closure on Scott's comment
<scribe> ACTION: wilson close the loop on the author element discussion [recorded in http://www.w3.org/2009/11/19-wam-minutes.html#action02]
<trackbot> Sorry, amibiguous username (more than one match) - wilson
<trackbot> Try using a different identifier, such as family name or username (eg. awilson2, swilson3, ChrisWilson)
<Marcos> http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0808.htm
AB: Scott proposes support for multipe authors?
MC: no, he was just asking how to
do that
... I don't think it was a spec comment
<scribe> ACTION: marcos seek clarification with Scott Wilson re his intent for multiple authors [recorded in http://www.w3.org/2009/11/19-wam-minutes.html#action03]
<trackbot> Created ACTION-459 - Seek clarification with Scott Wilson re his intent for multiple authors [on Marcos Caceres - due 2009-11-26].
AB: re Marcin, his comment #1 was bug fixes and editorial, right?
MC: yes
MH: yes
AB: then we have closure on
that
... what about MH comment #2?
MC: param ambiguity at the end of
a mime type decl
... e.g. charset
... can also use <content> to declare mime type
... not sure which one wins
AB: will this require a new LC to fix?
MC: it should not
... break any impls
... I've clarified the behavior
MH: I don't think we need another
LC
... I do think it is a bug
... I think we can resolve this over email shortly
... think the registration is also a bit buggy
<Marcos> 1. kill the parameter bit - using the ABNF you suggest below.
<Marcos> 2. say that it is allowed, but left up to the implementation.
<Marcos> 3. say that parameter is allowed, but if it includes an encoding
<Marcos> parameter, then @encoding beats it (or the other way around).
AB: does anyone have any additional comments on MH's comments?
<Marcos> <content src = "start.php"
<Marcos> type = "text/html;charset=Windows-1252"
<Marcos> encoding = "ISO-8859-1" />
AB: is the WG being asked to choose one of these opts?
RB: I think #3 is the most logical
MC: yes, I agree with #3
<marcin> +1 for 3, but I - as author - would be kind of crazy putting two different values there :). Maybe I would like to crack the WUA?
AB: any other opinions?
... I think we need some time to review the proposals
... not sure we can agree on this call
Arve: agree we need some
time
... what are the security implications of these opts?
MH: think we should continue on email
RB: don't think we are adding new
security concerns (that are already there)
... I don't think this is a big issue
... want to decide now
AB: I heard MC, MH and RB voice support for #3
Arve: if I have to choose now, I'd say #3
DS: no opinion
AB: is #3 a bug fix or a
substantive change
... I'm hearing that MH, MC, and RB say it is a bug fix
... is that correct?
<marcin> yes
MC: yes
RB: yes
MH: yes
DS: would it change impls?
MC: no, don't think so
DS: based on MC's description, this would be a class #2 change thus would not require going back to LC
AB: draft proposal to accept
proposal #3 above
... any objections?
[ None ]
RESOLUTION: group agrees to proposal #3 in MC's response to MH's comment #2 email re P&C LC#3
AB: are there any other LC#3 comments?
MC: there is something else in
MH's email
... re references to media type RFCs
MH: W3C media type reg says use
RFC 2046 should be used for regis
... but 2046 says use 2048
... I think this is a W3C and IETF process issue
MC: let's see what IETF says about our registration
AB: are there any other comments from MH we need to discuss today?
MC: our use of SNIFF spec is
questioned by MH
... I think we are using it OK
... but need to hear from Marcin
AB: Marcin, can we live with what is in the spec now?
MH: yes
... SNIFF spec is still a WIP
MC: my proposal is to work with
Adam Barth to make sure we are aligned with SNIFF
... on the P&C side, I don't think the proc model will
change
MH: yes, I agree
... we may need to ask Adam to make some changes/additions
AB: any other issues from Marcin?
MC: no
MH: no
AB: you two, MC and MH, please get closure on your emails so we have public record of agreement
MC: I've already changed to the spec
<Marcos> http://dev.w3.org/2006/waf/widgets/
AB: anything else re LC#3
comments?
... the deadline is today
AB: on November 23 we have a call
scheduled with the Director but that will be postponed if
comments/issues are still open.
... I think we the best we can do now is to record a resolution
to publish CR but with a proviso
... Proposed Resolution: the group agrees to publish CR#2 of
the P&C spec provided no substantive and unresolved issues
are raised on Nov 19
... any comments?
MC: we've addressed all comments
submitted
... we have made no substantive changes since LC#3 was
published
... think we are ready to go to CR
RB: I agree with Marcos
AB: anyone else have comments on
CR#2 readiness?
... any objections to the proposed resolution above?
[ None ]
RESOLUTION: the group agrees to publish CR#2 of the P&C spec provided no substantive and unresolved issues are raised on Nov 19
AB: last week Apple excluded two
of the patent applications from the W3C's Royalty-Free
Licensing Requirements for the WARP spec ( http://www.w3.org/2004/01/pp-impl/p73
)
... this presumably means a new PAG will be created
... Doug and/or Steven, do you have any information to
share?
SP: PLH will talk to Rigo today; want to start the PAG in about 1-weeks time
AB: wow; that would be excellent
RB: indeed
DR: these are patent
applications, not patents
... anyone can go to USPTO and present prior art
DS: does anyone know if there is precedence for excluding patent apps
AB: I am not aware of that, in the context of patent apps
DS: wondering if one could take someone to court for infringing on a patent app
<scribe> ACTION: doug I will follow-up with the IE we had for the Updates PAG [recorded in http://www.w3.org/2009/11/19-wam-minutes.html#action04]
<trackbot> Created ACTION-460 - I will follow-up with the IE we had for the Updates PAG [on Doug Schepers - due 2009-11-26].
AB: Rigo reported to me
"Participants in the Webapps WG are free to contact the USPTO
to oppose the application if they are aware of prior
art."
... as we already know, we may continue to work on the WARP
spec i.e. work do not need to pause nor stop our work on
WARP
RB: I think we should insist on continuing
DS: re USPTO, does it have to be prior art or can "obvious" be included
DR: need to ask Rigo
AB: thanks DS and SP for your info
AB: several discussion re WARP
are continuing on the mail list: Robin (
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0745.html
) and Bryan (
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0757.html
).
... and yesterday, RIM started a new thread (
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0774.html
). Implementing that proposal could affect the P&C such
that a new LC would need to be published.
... my short summary re WARP is the main tension is if the
intentionally simplistic model as reflected in the latest ED (
http://dev.w3.org/2006/waf/widgets-access/
) is sufficient or do we accept some set of the additional
features/proposals e.g. UPnP addresses, RIM's proposal, Bryan's
proposal, etc.
... an additional consideration is, given related patents in
this area, is it wise to increase the scope and hence attack
surface for "non-friendly" patents.
MH: re UPnP, I think it needs to
be addressed
... it would be bad to exclude the UPnP use cases
... if we don't address these UCs, the spec is dead for UPnP
usage
... the WARP spec could say local net traffic is out of scope;
doesn't say it is excluded though
<Zakim> darobin, you wanted to propose a general approach
AB: MH says UPnP needs to be
supported
... what do others think?
RB: I think the door for new
features is already closed
... a lot of people like JIL are waiting for it
... I propose no new features for WARP
... we can make some changes e.g. some refinements
... If there is a need for additional features, they can be
done in a branched spec e.g. WARP 2.0
SC: being a newcomer, I'm not
sure about the scope
... we think it is vauable to have our proposed feature in the
standard
... don't feel too strongly about 1.0 vs 2.0
... we should try to address the high priority features
RB: I'm fine with the new features, just want them in 2.0
SC: what is the impact on the
features being added
... will it really add a bunch of time versus starting with a
new 2.0 spec
... concerned about the review cycles
RB: can get a 2.0 spec started rather quickly
SC: I think what I proposed is useful
RB: would you be willing to edit 2.0 spec if group agrees?
SC: I'd consider it
... If we want new features, then we need to assign an
Editor?
RB: yes
AB: yes, that is the case
MH: re UPnP, I proposed a special
value of local
... I also proposed that local nets are out of the scope
<Marcos> +q
MH: I don't think there any
objections to my local networks proposal
... think the BBC use case should be in 1.0
<arve> what about the current incarnation _prevents_ uPnP from working?
RB: I think it should be in a separate spec
MC: the main use case is using
HTTP to get stuff from the web
... My proposal is we create a new Doc like "widget access for
UPnP"
<darobin> +1 to WARP4U
MC: and we do something like that for other protocols
<Suresh> If we are talking about just a few weeks or so and see good use cases, I would encourage inluding the new features in 1.0
Arve: I agree with MC
... UPnP belongs in a separate spec
... there a other things to consider re UPnP in the context of
widgets
... think UPnP needs its own spec
AB: MH, are you interested in driving a UPnP + WARP spec?
MH: maybe; but think WARP should explicitly say UPnP is out of scope
Arve: but there's a bunch of stuff out of scope
AB: we could add a ref to a WARP4U spec
Arve: would that require a re-charter?
AB: I had not thought about the
Charter implications; good point;
... that is something we need to consider
<arve> [Clarification: we need to consider whether re-chartering is necessary, I'm not saying it is so]
SC: if there is a way to proceed without changing the Charter and referencing Editor's Drafts even if informative, seems like a good way forward
<darobin> RB: I don't think it would imply a re-charter
<darobin> MH: me neither
SC: want to make sure though that we can get things out quickly
DS: what is the time scale for WARP v2?
RB: as soon as an ED is ready
AB: first need to know if anyone is willing to commit to driving a WARP4U spec
DS: we will re-Charter in
June
... but may need to re-Charter earlier
... and at that time, could add the UPnP+WARP then
... but the work could proceed before the Charter
<Marcos> AB: lots of poeple agreed in the summer that we are feature complete
<Marcos> AB: the market is adopting our specs already
<Marcos> AB: we agree that that new features are important but should be added to a new docuemnt
<Marcos> AB: To have new features
<darobin> AB: in order for us to go down the path of a new spec, we need an editor
SC: what is the next pub plan for WARP?
RB: LC#2
<Marcos> SC: can we have a summary?
<Marcos> SC: I might be able to commit
<Marcos> SC: I have a question. Right now it's an editor's draft?
<Marcos> DB: it's in last call
<Marcos> SC: it it progressing to CR
AB: yes, that's correct
SC: I'm willing to take an approach where we create new Drafts for new Features
<Suresh> and having informative references from the WARP 1.0
MH: I already proposed text to
handle local traffic
... I could put that in a new ED
... and then ED I create WARP4U
... could then in WARP spec, refer to WARP4U
RB: ok, we could do that i.e. add an Informative Ref to WARP4U if/when it exists
MH: that's not acceptable
... want to have an explicit statement that UPnP is not in
scope for WARP and it is defined in WARP4U
... I can create an ED of WARP4U
... let's discuss over e-mail
RB: need to discuss Bryan's email
<darobin> RB: we should discuss Bryan's suggestion that by default instead of excluding everything we should allow the same sutff that browsers do, e.g. images from anywhere
RB: if we do what browsers do, we
don't need WARP at all
... but I don't think that's what people want
MC: we do need it for
cross-origin access because a widget doesn't have an orgin like
a browser's web page
... HTML5 defines behavior if have HTTP origin but is silent on
Widget origin
RB: that would require a bunch of mapping
MC: right; that's why we have the WARP spec
RB: need to be careful with white-lists
<Suresh> WARP = whitelist,
MC: need to align with Web security model
AB: have recent changes been made?
RB: not since the call for
review
... propose we reject Bryan's proposal and move to LC#2
AB: any comments on Robin's proposal?
RB: if someone wants to implement BS' model, they could define it in a new spec
SC: do we need a resolution on
how to handle new features via new specs?
... I get the sense new features aren't acceptable
... Given this, should we capture the process for new features
e.g. as a resolution?
RB: I'm OK with that
... but would be concerned about adding Informative Refs to the
new drafts
SC: right, Informative for now
but eventually could become Normative
... would like a resolution
AB: draft resolution: new features for WARP will be handled via new documents
<darobin> +1
<marcin> -1 for this text, refinement is needed
<Suresh> new features for WARP will be handled via new documents
SC: want to add something about references
<Suresh> New features for WARP will be handled via new documents and informatively referenced from WARP 1.0
AB: any objections to SC's modified resolution?
RB: yes, want to say "Informatively Referenced when the docs are published"
AB: IOW, FPWD is an entrance
block
... SC, is that qualification acceptable?
<marcin> this delays the other specs allowing WARP to block the other texts
<marcin> therefore the scope of WARP must be precisely defined
SC: so EDs cannot be referenced?
RB: they shouldn't be
DS: that's not true
RB: well, I think they shouldn't be
SC: I want to address the LC comments and keep the work going
<Marcos> -q
RB: I can live with Informative refs to EDs if the group agrees to move those specs fwd
<marcin> it is still not clear what the relation is between WARP and the other texts
AB: the maturity level for Informative refs is quite low, correct Doug?
DS: yes
AB: proposed resolution: New features for WARP will be handled via new documents and informatively referenced from WARP 1.0
RB: that's OK "as long as the group agrees they are mature enough"
AB: any objections?
<Suresh> world is not perfect:-)
MH: yes
... unclear about relationship to WARP and new text
RB: that's up to the new spec
MH: WARP must state what it is about
AB: what specifically do you object to re the wording of the proposed resolution
MH: I object because you think
UPnP must be part of WARP 1.0
... no, that's not quite right
Arve: I do not think we have agreement yet on the definition of "local"
BS: may be able to find a defn in UPnP
Arve: UPnP's defn of local is
only good for IPv4
... thus we don't have agreement on local
AB: unable to reach consensus; must stop for today
AB: earlier today Robin began responding to Larry Masinter's comments ( http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0131.html ) . I believe LM was only person to submit comments for the LC ( http://www.w3.org/TR/2009/WD-widgets-uri-20091008/ ).
RB: I want to start a CfC on WARP LC#2
AB: I think we need to try again
to get consensus before we make a CfC for LC#2
... Next call will be December 3 - NO CALL ON NOVEMBER
26!
... meeting adjourned
... please continue WARP discussions on the mail list
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/Steve/Steven/ Succeeded: s/W3C 2046/W3C media type reg says use RFC 2046/ Succeeded: s/but that would require a re-Charter/would that require a re-charter?/ Succeeded: s/MC/MH/ Found Scribe: Art Found ScribeNick: ArtB Present: Art Arve Robin David Marcin Steven Marcos Frederick Suresh Benoit Doug Chitturi WARNING: Replacing previous Regrets list. (Old list: Frederick) Use 'Regrets+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Regrets+ Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0763.html Found Date: 19 Nov 2009 Guessing minutes URL: http://www.w3.org/2009/11/19-wam-minutes.html People with action items: benoit doug marcos wilson[End of scribe.perl diagnostic output]