XML Security Specifications Maintenance Working Group Teleconference
30 Oct 2007


See also: IRC log; full minutes (member-confidential)


Frederick_Hirsch, Ed_Simon, Thomas_Roessler, Sean_Mullan, Rob_Miller, Konrad_Lanz, Phill_Hallam-Baker_Bruce_Rich
Frederick Hirsch




<trackbot-ng> Date: 30 October 2007

<FrederickHirsch> Meeting: XML Security Specifications Maintenance WG Conference Call

<FrederickHirsch> Rob, are you able to please scribe a session during the F2F?

There is no teleconference next week.

(November 6)

Next meeting is with XML Core on Tuesday 8:30 to 10; use XML Core IRC

Goal is to deal with Canonicalization 1.1

XML Security WG F2F Thursday - Friday, 8-9 NovemberXML Security WG F2F Thursday - Friday, 8-9 November -- 13:30-18:00 Thursday, 8:30 - 18:00 Friday.

See admin pages for meeting details.

<FrederickHirsch> confidential minutes from last week http://www.w3.org/2007/10/23-xmlsec-minutes.html

<FrederickHirsch> http://www.w3.org/2007/10/23-xmlsec-minutes-public.html

Resolution: Minutes of last week are approved.

<FrederickHirsch> WAF Charter - http://lists.w3.org/Archives/Member/member-xmlsec-maintwg/2007Oct/0008.html

<FrederickHirsch> EXI joint session expectatations

Frederick would like to talk about EXI

what do we want to do with chartering wrt EXI

XML Signature URI attribute value

Member-confidential discussion of implementation behavior showed that several implementations assume that a proper URI reference (as constrained by the syntax in the URI specification) is written into the URI attribute.

<FrederickHirsch> tlr: intent was to allow extensibility to IRI through this spec language, as used at that time

tlr: is typical spec language of the time to keep spec open to IRIs and almost any kind of URL like thing in there; was written to allow conversion of URI variants to convert to URI;

tlr: what is the best thing to put into spec now?
... suggestion - this is an ordinary URI attribute so put in escaping rules on creation to maximize interoperabiiity

frederick: let

<tlr> Text from the e-mail: " The URI attribute identifies a data object using a URI Reference [URI]. The mapping from this attribute's value to a URI reference MUST be performed as specified in part 2, section 3.2.7 of [XMLSCHEMA]."

frederick: let's clarify the text of

<tlr> Additionally: Some existing implementations are known to verify the value of the URI attribute against the grammar in [URI]. It is therefore safest to perform any necessary escaping while generating the URI attribute.

<FrederickHirsch> tlr: also had - The value is anyURI type allowing any value of that type, however ...

Sean: (in response to Konrad) will check into what Java versions support IRIs

Frederick: agreement in what Thomas was suggesting?
... will need to follow up with other implementers

<sean> I generally agree with the wording

Consensus to go forward with Thomas' wording

<sean> yes, but not at xml core

Will discuss on Friday morning

Sean: will decide if he will call into XML Core

XML Core items

c14n appendix A

Paul responded to Appendix A

Paul: Appendix looks quite complex, reluctance to change it,

tlr: Had meeting with Paul, implementations of Appendix A seem consistent
... drop Appendix A and say what it is supposed to do -- say it has same results as RFC 3986

<klanz2> +1

<tlr> "same as RFC 3986, but keep leading ../"

<tlr> -- if that's all we need to change

Appendix A is about path merging in canonicalization

Sean: does not agree he would have gotten it right with Appendix A, used Konrad's examples as baseline
... put Konrad's examples in appendix

Konrad: do that in combination with what Thomas suggested

Frederick, Konrad: remove algorithm description

Bruce: move away from language in Appendix A
... need example with triple slash to illustrate those

<FrederickHirsch> Bruce: consider leading / case in addition to ../ also need additional example with multiple /

<tlr> I wonder whether that can ever happen if the start string did not have a leading slash. Anyway.

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Oct/0024.html

JCC: how about pseudo-code to illustrate

<klanz2> http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Oct/0023.html

JCC: pseudo-code could detail all the functionality rather than natural language

Konrad: check links he posted - similar steps to what JCC proposes

<tlr> -1 to informative algorithm

Frederick: XML Core does not want to restart the process

tlr: disagrees with pseudo-code as normative, cannot be sure it is a valid implementation

<FrederickHirsch> +1 to thomas, not wanting divergence of language and informative pseudo-code

tlr: we set ourselves up for implementations, some of which use pseudo-code; others with prose and examples

Konrad: the algorithm is not too hard, so we could write it up again; need to stay close to 3986

<FrederickHirsch> correction - what was hard was trying to stay close to 3986

Konrad: 3986 not suitable to achieve what we want to do,

<FrederickHirsch> konrad proposal on xml core list - http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Oct/0023.html

Konrad: concern is that similar mistakes will be made again; what is perceived hard is to stay close to 3986
... believes he has a simplified way of expressing 3986

<FrederickHirsch> Two proposals on table: 1. Remove Appendix A algorithm text, put in sentence overview and examples

Frederick: proposal to remove appendix text, put in overview and examples

<FrederickHirsch> second proposal - adopt new algorithm description as in http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Oct/0023.html

jcc: Core group does not want to re-open issue; how about in canonicalization document that // has to disappear, then XMLsec group makes this a matter of best practice

Frederick not comfortable with removing the issue from actual specifications

<tlr> the issue hasn't been closed in the first place!

<jcc> personally, prefer first approach: include algorithm in specification, but if the core group

<klanz2> 2.

<jcc> ...does not want to re-open the issue, I would like yet to allow implementers access to the algorithm details

<FrederickHirsch> my non chair preference is #1, no algorithm, but examples

Ed: no opinion

<jcc> sorry: I was meaning option#2. ALgorithm in specs

<sean> proposal 1 is my preference

call for straw poll on proposal 1 vs proposal 2

<brich> i could go either way, but think #1 may be more achievable

<tlr> tlr: leaning toward #1, no explicit algorithm, but would prefer to make it more concrete before firming this up

<FrederickHirsch> phb #2

<jcc> jcc also for proposal #2

<klanz2> #2

<klanz2> yes

Straw poll result: Proposal 1, introductory text and Konrad examples vs. Proposal 2 (pseudo-code)

Frederick: take a closer look at what Konrad's posts
... straw poll result, fairly evenly divided between Proposal 1 and Proposal 2

Ed: in general, my preference is to use mathematically-precise means of expression wherever possible

Frederick: please review this topic by XML Core next Tuesday

<tlr> ACTION: thomas to send proposal for "appendix A without pseudo code" [recorded in http://www.w3.org/2007/10/30-xmlsec-minutes.html#action01]

<trackbot-ng> Created ACTION-106 - Send proposal for \"appendix A without pseudo code\" [on Thomas Roessler - due 2007-11-06].

Frederick: let's discuss on list before Tuesday

JCC: will check his implementation re URI processing

EXI Meeting

what should we do in that meeting?

Frederick: start at 1:30, admin stuff, review XML core, xml:base, two presentations from Eric (PWH) and Ed

start chartering review process, look at xmlsig issues, exi joint session, then chartering and best practices again

see official agenda for details

Charter Draft

did not mentions streaming, performance -- they need to be mentioned

will discuss canonicalization

Konrad: what people think about future work -- big changes or small changes

Frederick: postpone that for F2F as that is a big topic

Konrad: please think about it

XMLBase processing

Under this agendum, there was member-confidential discussion about the progress made by various implementers on outstanding issues identified during the interoperability testing.

<scribe> ACTION: Sean to send an email re test case 102 [recorded in http://www.w3.org/2007/10/30-xmlsec-minutes.html#action02]

<trackbot-ng> Created ACTION-107 - Send an email re test case 102 [on Sean Mullan - due 2007-11-06].

close action-81

close action-102

Summary of Action Items

[NEW] ACTION: Sean to send an email re test case 102 [recorded in http://www.w3.org/2007/10/30-xmlsec-minutes.html#action02]
[NEW] ACTION: thomas to send proposal for "appendix A without pseudo code" [recorded in http://www.w3.org/2007/10/30-xmlsec-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/11/27 15:18:34 $