See also: IRC log; full minutes (member-confidential)
<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
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: 4.3.3.1 is typical spec language of the time to keep spec open to IRIs and almost any kind of URL like thing in there;
4.3.3.1 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 4.3.3.1
<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 4.3.3.1 on Friday morning
Sean: will decide if he will call into XML Core
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
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
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
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