See also: IRC log
<trackbot> Date: 01 September 2009
<scribe> Scribe: jwray
<scribe> ScribeNick: jwray
<fjh> 8 Sept Kelvin is scheduled to scribe
fjh: Kelvin will scribe for next week.
<fjh> TPAC Overview: http://www.w3.org/2009/11/TPAC/overview.html
<fjh> Please register: http://www.w3.org/2002/09/wbs/35125/TPAC09/
<fjh> Note registration fee increases after 21 September 2009
<tlr> We meet Thursday/Friday 5-6 November 2009
<fjh> http://www.w3.org/2008/xmlsec/wiki/Implementations
<fjh> interop shows changes and features are supported, are implementable
Sean: Perhaps add interop status to implementation entries in wiki?
<fjh> list of implementations provides information about existing implementations, honor system
fjh: Should be clear that there is no endorsement for implementations on wiki.
<fjh> ACTION: fjh add warning to implementation wiki [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action02]
<trackbot> Created ACTION-357 - Add warning to implementation wiki [on Frederick Hirsch - due 2009-09-08].
<fjh> 11 August 2009 teleconference
<mullan> ACTION: mullan add jdk7 implementation to wiki [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action03]
<trackbot> Created ACTION-358 - Add jdk7 implementation to wiki [on Sean Mullan - due 2009-09-08].
<fjh> http://www.w3.org/2009/08/11-xmlsec-minutes.html
RESOLUTION: Minutes from 11 August approved.
<fjh> Algorithms cross-reference (ACTION-217)
<fjh> Updated contributors list (ACTION-215)
<fjh> use-clause for schema
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0017.html
fjh: Issue is use=required vs optional for curve-type.
<fjh> optional is default for use, may need to be explicit
<fjh> proposed resolution is add use="required" to URI attribute for NamedCurve type
RESOLUTION: Add use="required" to URI attribute for NamedCurve type.
<fjh> ACTION: fjh to respond to Anders [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action04]
<trackbot> Created ACTION-359 - Respond to Anders [on Frederick Hirsch - due 2009-09-08].
<scribe> ACTION: Brian to make change to schema. [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action05]
<trackbot> Created ACTION-360 - Make change to schema. [on Brian LaMacchia - due 2009-09-08].
<fjh> suggest we make other attribute use attributes explicit
<scantor> we probably have to use elements as the carriers for parameters because of the wildcard schema on c14nmethod
<esimon2> +1 to standalone spec
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0019.html
<fjh> scott suggesting new document for new signature 2.0 material, with conformance clear
<fjh> sounds like discussion might be primer etc
scantor: Modifying 1.1 to incorporate new 2.0 model might be confusing to new readers. might be better to produce two docs instead.
<esimon2> Ed reiterates that he thinks <KeyInfo>, because it is common to Signature, Encryption, and XKMS, should be in its own specification.
scantor: People interested in new
model shouldn't have to wade through old 1.1 stuff. Need
stand-alone doc for 2.0 implementors.
... even though 1.1 isn't being "deprecated"
<fjh> proposed plan is new 2.0 doc with only new material, then allow use of old transforms but in additional document or referencing second edition
<fjh> ie 2.0 doc has all you need for new approach, but supplement with older transform model
<fjh> might be one document, depends, but another section
<fjh> a 2.0 signature with a 2.0 transform MUST use C14N2.0
scantor: Need WG decision over relationship between C14N 2.0 and DSig 2.0.
<fjh> scott note concern about enabling 2.1...
<fjh> scott asks do we really need to flag enveloped, since it is obvious when present
<fjh> scott suggests any c14n alg must be compatible with input requirements
scantor: Perhaps text constraining C14N algortihms only to those that reference subtrees.
fjh: Proposal: : Remove material from 2.0 draft that references previous version (unless it is incorporated into 2.0). In particular, leave out old transform model..
RESOLUTION: Remove material from 2.0 draft that references previous version (unless it is incorporated into 2.0). In particular, leave out old transform model. Make it clear that 1.1 is still allowed, but defer exact approach.
<scribe> ACTION: pdatta to edit 2.0 spec accordingly. [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action07]
<trackbot> Created ACTION-361 - Edit 2.0 spec accordingly. [on Pratik Datta - due 2009-09-08].
<fjh> action-353?
<trackbot> ACTION-353 -- Ed Simon to draft text explaining meaning of URI attribute on Reference element -- due 2009-08-18 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/353
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0026.html
<fjh> please review use of URI and Pratik's email regarding database access
<fjh> personally prefer use of URI and simpler approach
<fjh> but these needs review
<fjh> empty URI means this document
<fjh> is a database query a transform?
<fjh> note to chair - URI semantics and use a topic for future agendas
<fjh> example, URI identifier for database, query is transform
tlr: URI identifies a resource, doesn't necessarily say how to dereference it.
<tlr> we don't want to reinvent EPRs.
<tlr> ?SELECT%20t%20WHERE%20...
<fjh> concern is representation that is not necessarily octet stream
<fjh> relationship of http, content-type
tlr: Should include assertion of content-type (representation of the resource).
<fjh> discussion of whether octet stream appropriate or not
<fjh> pratik notes concern of needing to parse material from stream when it was already parsed
<fjh> cid: mime part example, with mime headers etc
<fjh> be consistent with web architecture, use URIs with query strings etc as appropriate
<fjh> ACTION-350?
<trackbot> ACTION-350 -- Ed Simon to propose text to align node set result treatment for XSLT and XPath in 1.1 spec -- due 2009-08-04 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/350
<fjh> close action-353
<trackbot> ACTION-353 Draft text explaining meaning of URI attribute on Reference element closed
<esimon2> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0007.html
<fjh> action-353: proposal in http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0007.html
<trackbot> ACTION-353 Draft text explaining meaning of URI attribute on Reference element notes added
<fjh> suggestion, accept change from Ed without parenthetical
<fjh> ed will review XPath Filter 2 and emails
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0018.html
<fjh> scott notes can defer extension points during schema development, or use other instead of any
<fjh> action-257?
<trackbot> ACTION-257 -- Konrad Lanz to follow up and provide unified proposal for changes to support randomized hashing and signing -- due 2009-04-14 -- OPEN
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/257
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec/2009Aug/0012.html
<fjh> action-127?
<trackbot> ACTION-127 -- Thomas Roessler to draft text on trade-off between different extensibility mechanisms, for BP draft -- due 2009-08-18 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2008/xmlsec/track/actions/127
RESOLUTION: Accept the email proposal for Action-127
<scribe> ACTION: fjh to edit document accordingly [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action08]
<trackbot> Created ACTION-362 - Edit document accordingly [on Frederick Hirsch - due 2009-09-08].
<fjh> scott notes that we have an XSD schema that is normative, and certain items cannot be changed
<scribe> ACTION: scantor to respond on substantive points. [recorded in http://www.w3.org/2009/09/01-xmlsec-minutes.html#action09]
<trackbot> Created ACTION-363 - Respond on substantive points. [on Scott Cantor - due 2009-09-08].
<fjh> proposal - xsd schema is normative, any RNG schema is informative
<tlr> ISSUE: What interoperability and security issues arise out of schema validation behavior?
<trackbot> Created ISSUE-138 - What interoperability and security issues arise out of schema validation behavior? ; please complete additional details at http://www.w3.org/2008/xmlsec/track/issues/138/edit .
RESOLUTION: XSD schema is normative; Any RNG schema is informative
<fjh> close ACTION-127
<trackbot> ACTION-127 draft text on trade-off between different extensibility mechanisms, for BP draft closed
<fjh> close action-356
<trackbot> ACTION-356 Send revised version of 2009Jul/0067 e-mail closed
<fjh> close action-263
<trackbot> ACTION-263 Generate working examples for ISSUE-115 and review how toolkits handle the issue closed
<fjh> resolution of ACTION-263 is related to XPath nodesets in C14N, other more specific actions open, ACTION-350