W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > July 2007

Draft minutes: XMLsec weekly 2007-07-17

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 17 Jul 2007 16:47:17 +0200
To: public-xmlsec-maintwg@w3.org
Message-ID: <20070717144717.GA3834@raktajino.does-not-exist.org>

Draft minutes from today's meeting are available online:


Thomas Roessler, W3C  <tlr@w3.org>


                                   - DRAFT -

      XML Security Specifications Maintenance Working Group Teleconference
                                  17 Jul 2007


   See also: [3]IRC log


          Thomas Roessler, Ed Simon, Sean Mullan, Konrad Lanz, Hal
          Lockhart, Juan Carlos Cruellas, Frederick Hirsch

          Frederick Hirsch

          Thomas Roessler


     * [4]Topics
         1. [5]Administrvia
         2. [6]action item review
         3. [7]XPointer
         4. [8]identifiers for xpath 2.0 and xslt 2.0
         5. [9]RFC 4514 and 2253
         6. [10]misc wrap-up
         7. [11]ACTION-60; mime types vs URIs
         8. [12]interop
         9. [13]next meeting
     * [14]Summary of Action Items


   Next meeting: 31 July, no meeting next week

   fjh: Tech plenary draft agenda is available.
   ... still soliciting papers for workshop ...
   ... please follow up on interop questionnaire ...
   ... minutes for last time ....

   <FrederickHirsch> [15]http://www.w3.org/2007/07/10-xmlsec-minutes

   tlr: umh, did I update the version in datespace


   That's the updated version.

   RESOLUTION: minutes approved

action item review

   ACTION-26: note for submission to CG; continued

   <FrederickHirsch> action-50 to be assigned to THomas, 31 July

   ACTION-50: reassign to Thomas; new due date on 31 July

   ACTION-53: work toward publication of decryption transform; blocked on
   XPointer issue

   ACTION-56: done

   ACTION-58: done; might need some refinement in terms of test cases

   ACTION-61: done; haven't heard back

   ACTION-62: clarify testing issues; done

   ACTION-63: done



   <fjh> i can scribe for thomas in this section

   <fjh> Both decrypt transform and xml dsig core include effectively
   normative reference to XPointer, but to CR

   <fjh> this was returned to WD, split into three, two went to REC

   xpointer() XPointer scheme

   <fjh> one part that includes material referenced did not , i.e

   <fjh> DSig core can reference XPointer REC and Element scheme()


   <fjh> look at

   <fjh> look for paragraph "When a fragment is not preceded "

   <fjh> barename now called shortname

   <fjh> three kinds of XPointer - barename (still exist, shortname) in
   XPointer framework

   <klanz2> do you have a link for the short name definition

   <fjh> second, #xpointer(/), identifies root element in nodeset

   <fjh> yes, in XPointer Framework...

   <fjh> syntax for element XPointer only allows document, but would lose
   comments after closing tag of document element

   <fjh> so cannot use element XPointer for this

   <fjh> hence definition in this draft

   <fjh> XPointer framework REC is

   <fjh> XPointer element scheme REC

   <fjh> looking at

   <fjh> no XPointer evaluation context defined in framework

   <fjh> edit for this, also to remove location-set

   <fjh> i.e. no context, no location-set (point nodes, range set)

   <klanz2> lost the call

   <fjh> full xpointer, now is scheme based xpointer (equivalent

   <jcc> q

   fjh: intent of the changes to do what was done before, but not refer to
   ... select portion of text? ...
   ... change implementations that relied on that? ...

   tlr: well, that's OPTIONAL. Also, step 2 suggests that a partially
   selected text node would be fully referenced in the old model, no?

   jcc: same question, q-

   <fjh> not conformance affecting

   phb: it's ok


   <EdSimon> I think we need time to review the changes before the next
   call in two weeks.

   <EdSimon> I'm good with merging.

   <fjh> ok with merging

   <scribe> ACTION: tlr to merge into main editor's draft [recorded in

   <trackbot-ng> Created ACTION-64 - Merge into main editor's draft [on
   Thomas Roessler - due 2007-07-24].

   fjh: sense of group -- pretty close, no major rework?

   klanz2: ok

   <fjh> tlr: do we have test cases for C4N with comments?

   jcc: can take an action

   <scribe> ACTION: juan carlos to develop/retrieve test cases for C14N
   with comments, scheme-based xpointers [recorded in

   <trackbot-ng> Created ACTION-65 - Carlos to develop/retrieve test cases
   for C14N with comments, scheme-based xpointers [on Juan Carlos Cruellas
   - due 2007-07-24].

   <fjh> tlr: inform coordination group of this approach regarding
   XPointer behaviour

   <scribe> ACTION: thomas to inform xml cg of intent to squat on
   xpointer(/) and xpointer(id(ID)) [recorded in

   <trackbot-ng> Created ACTION-66 - Inform xml cg of intent to squat on
   xpointer(/) and xpointer(id(ID)) [on Thomas Roessler - due 2007-07-24].

identifiers for xpath 2.0 and xslt 2.0


   <hal> +1

   fjh: defer to XML Signature vNext

   ed: agree

   <scribe> ACTION: Ed Simon to update wiki to list XPath 2.0 and XSLT 2.0
   identifiers [recorded in

   <trackbot-ng> Created ACTION-67 - Simon to update wiki to list XPath
   2.0 and XSLT 2.0 identifiers [on Ed Simon - due 2007-07-24].

   <fjh> tlr: for items we defer to v.next, if urgent issue we can write
   note or members can do member submissions

RFC 4514 and 2253


   fjh: thanks for doing that; very helpful

   sean: went through the grammars, looked at changes section in 4514
   ... three possible places with incompatibilities ...
   ... but they're (a) obscure, and (b) fix obvious bugs in 2253 ...
   ... first one, 2253 if you look at grammar doesn't allow attribute type
   keywords of length 1 ...
   ... highly unlikely that's enforced ...
   ... would forbid C='US' ...
   ... used widely ...
   ... second one, RFC 2253 didn't allow '\ ' to escape a space ...
   ... another bug in the grammar ..
   ... doubt there are any implementations that enforce this one ...
   ... last one, RFC 4514 requires null characters to be escaped ...
   ... 2253 doesn't say anything about them ...
   ... worth writing a test case for each ...
   ... to make sure implementations aren't broken ...

   fjh: write test cases, what else do we need to do?

   sean: umh

   fjh: I'm asking the wrong question. We've narrowed down the issues.
   These are reasonable changes, we'll look if we have any issues -- not
   sure that's really needed.

   sean: I'm just suggesting that test cases are final action. If we do
   find problems, that's better fixed in the implementation than in the

   <fjh> Summary, agree that ok to change normative reference, to 4514, if
   these issues arise, then implementation has serious issue, an
   implementation issue

   tlr: to summarize, we're fine changing the reference. If the
   differential use cases demonstrate strict RFC 2253 compliance, then
   that suggests insane implementation.

   fjh: sounds reasonable

   sean: would like to hear from Konrad

   klanz: read e-mail; think that's fine

   fjh: what else do we need to do?

   tlr: umh?

   fjh: where do we record this?

   <fjh> record this in transition request as annotation to changes

   <fjh> record in readme for test case

   tlr: annotation to changes; transition request

   sean: readme for test cases

   fjh: track on wiki, not as separate action item

   tlr: let's keep them in tracker

   fjh: yeah... might indeed make it easier

   <scribe> ACTION: sean to develop RFC 4514 / RFC 2253 test cases
   [recorded in

   <trackbot-ng> Created ACTION-68 - Develop RFC 4514 / RFC 2253 test
   cases [on Sean Mullan - due 2007-07-24].

misc wrap-up

   fjh: XML escaping and well-formedness. Agreed there's no need to do
   more on this.

   klanz2: early e-mail exchange; moot
   ... agree there's no open issue ...

   EdSimon: yep, there was also an exchange with Sean around CDATA etc;
   not an issue

   fjh: encoding of leading space in dname work -- anything needed?
   ... thought we had deferred to vNext ...
   ... is that an issue any more with all the changes? ...

   klanz2: it's recommended to escape first space character...

   <fjh> [29]http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/

   tlr: RFC 4514 takes care of that

   klanz2: "augment" takes care of that

   <fjh> tlr: 4514 requires space at beginning to be escaped

   klanz2: on the xmldsig-core side ...

   fjh: ok, issue closed
   ... adding a warning similar to what was in the RFC

   sean: record as best practice item

   fjh: who would like to do this?

   ed: ok, will do that along with other wiki stuff
   ... would like review from Sean, Konrad ...

   <fjh> warning similar to that of section 7.2 of RFC 2253:

   <scribe> ACTION: ed to draft warning similar to that of section 7.2 of
   RFC 2253 as possible best practice item [recorded in

   <trackbot-ng> Created ACTION-69 - Draft warning similar to that of
   section 7.2 of RFC 2253 as possible best practice item [on Ed Simon -
   due 2007-07-24].

   fjh: reversibility of string to DER encoding ... another warning?

   jcc: yeah, that's what I was thinking

   tlr: either this is the same issue as above, or the last action is

   fjh: ooops, yes. Juan Carlos, please review what Ed does.

   <fjh> 5c and 5d same item (in agenda)


ACTION-60; mime types vs URIs

   jcc: that was the message sent concerning the two attributes ...
   ... one appearing in ds:Reference, one appearing in ds:Object ...
   ... conclusion after reading in spec was ...
   ... ??? ...
   ... type attribute in ds:Reference always pointed to Object, Manifest,
   whatever ...
   ... Type attribute in ds:Object element is MIME type ...
   ... which deals with media type ...
   ... they look a bit orthogonal ...
   ... but no guidance at all ...
   ... some kind of guidance should be given which interpretation is the
   right one ...
   ... MIME type is string, Type is URI ...
   ... but we could put a MIME type into Type (??) ...
   ... clarify and agree what purposes of each attribute are ...

   fjh: let me summarize... not an issue with the rec, but maybe some
   interpretation advice in best practice document?

   jcc: exactly

   klanz2: is there shared view that these are orthogonal -- schema type
   vs. media type of encoded object?
   ... I agree to that interpretation ...

   fjh: konrad, please send list to message, errrm, ..

   <klanz2> ;-)



   <klanz2> I'll list a send to the message ;-)

   jcc: tried to clarify proposed way to build infrastructure for
   ... proposal is that last table have links to details of test cases ...
   ... and test cases themselves ....
   ... especially relevant for test cases dealing with c14n and inheritanc
   ... first, XML document, then list of links to different signatures ...
   ... that participants would compute ...
   ... in the end, would have document reference with tables and
   references to each test case ...

   fjh: some c14n tests might just have input/output?

   jcc: ??

   fjh: maybe just look at same canonicalized output?

   jcc: not at level of signature, only i/o of c14n?
   ... would work for some test cases, but maybe would also like to have
   negative test cases?

   klanz2: enveloping signatures?

   jcc: need to think more about that
   ... for identifying false positives, would need actual signatures ...

   klanz2: doesn't prevent us from having unit tests for c14n

   fjh: want to focus next call on (a) agreeing on redline as merged

next meeting

   fjh: also, go through Juan-Carlos' document, test document, update,
   make progress on that
   ... please review ahead of time ...

   klanz2: is there some howto for the CVS?

   <fjh> tlr: test data goes into test subdirectory for interop

   <fjh> tlr: try to use valid HTML instead of word etc

   <fjh> ... avoid plain UTF-8 encoding

   <fjh> ... general cvs instructions available on W3C

   <fjh> next call - agree dsig redline (merged), decrypt to last call,
   normative reference to URI spec (RFC obsoleted) same doc RFC reference
   (Thomas to send more detailed message to list), review Juan Carlos docs

   fjh: adjourned

Summary of Action Items

   [NEW] ACTION: ed to draft warning similar to that of section 7.2 of RFC
   2253 as possible best practice item [recorded in
   [NEW] ACTION: Ed Simon to update wiki to list XPath 2.0 and XSLT 2.0
   identifiers [recorded in
   [NEW] ACTION: juan carlos to develop/retrieve test cases for C14N with
   comments, scheme-based xpointers [recorded in
   [NEW] ACTION: sean to develop RFC 4514 / RFC 2253 test cases [recorded
   in [37]http://www.w3.org/2007/07/17-xmlsec-minutes.html#action06]
   [NEW] ACTION: thomas to inform xml cg of intent to squat on xpointer(/)
   and xpointer(id(ID)) [recorded in
   [NEW] ACTION: tlr to merge into main editor's draft [recorded in

   [End of minutes]

    Minutes formatted by David Booth's [40]scribe.perl version 1.128
    ([41]CVS log)
    $Date: 2007/07/17 14:46:24 $


   1. http://www.w3.org/
   2. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0027.html
   3. http://www.w3.org/2007/07/17-xmlsec-irc
   4. http://www.w3.org/2007/07/17-xmlsec-minutes#agenda
   5. http://www.w3.org/2007/07/17-xmlsec-minutes#item01
   6. http://www.w3.org/2007/07/17-xmlsec-minutes#item02
   7. http://www.w3.org/2007/07/17-xmlsec-minutes#item03
   8. http://www.w3.org/2007/07/17-xmlsec-minutes#item04
   9. http://www.w3.org/2007/07/17-xmlsec-minutes#item05
  10. http://www.w3.org/2007/07/17-xmlsec-minutes#item06
  11. http://www.w3.org/2007/07/17-xmlsec-minutes#item07
  12. http://www.w3.org/2007/07/17-xmlsec-minutes#item08
  13. http://www.w3.org/2007/07/17-xmlsec-minutes#item09
  14. http://www.w3.org/2007/07/17-xmlsec-minutes#ActionSummary
  15. http://www.w3.org/2007/07/10-xmlsec-minutes
  16. http://www.w3.org/2007/07/10-xmlsec-minutes.html
  17. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0018.html
  18. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/xmldsig-core-xpointer.html#sec-ReferenceProcessingModel
  19. http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
  20. http://www.w3.org/TR/2003/REC-xptr-element-20030325/
  21. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/xmldsig-core-xpointer.html#sec-ReferenceProcessingModel
  22. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action01
  23. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action02
  24. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action03
  25. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0012.html
  26. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action05
  27. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0024.html
  28. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action06
  29. http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/
  30. http://www.ietf.org/rfc/rfc2253.txt
  31. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action07
  32. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0005.html
  33. http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jul/0026.html
  34. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action07
  35. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action04
  36. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action02
  37. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action06
  38. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action03
  39. http://www.w3.org/2007/07/17-xmlsec-minutes.html#action01
  40. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
  41. http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 17 July 2007 14:47:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:40 UTC