See also: IRC log
<scribe> Chair: Frederick Hirsch
<scribe> Scribe: Juan Carlos Cruellas
<jh> Meeting: XML Security Specifications Maintenance WG Conference Call
<jh> Chair: Frederick Hirsch
<scribe> Scribe: Juan Carlos Cruellas
<scribe> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0025.html
TOPIC: 1) Administrative: Scribe confirmation, Attendance, Agenda review (9:00 am Eastern)
<tlr> Scribe for next week: PHB
<fjh> confirming next week scribe Phillp Hallman for the week after, not next week
<tlr> Scribe for 29 May: Giles Hogben
<tlr> s/Hallam/Hallam-Baker/
<tlr> Agenda: http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0025.html
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0012.html
<hal> there were changes to the canonicalization. They were not in the minutes.
<fjh> minutes approved
<fjh> ACTION: Frederick to post red-line link for C14N11 [recorded in http://www.w3.org/2007/05/15-xmlsec-minutes.html#action02]
<trackbot-ng> Created ACTION-25 - Post red-line link for C14N11 [on Frederick Hirsch - due 2007-05-22].
RESOLUTION: minutes of May 2nd 2007 and 3rd face to face meeting were approved
<fjh> Frederick will be out, Thomas will chair the next two meetings
ACTION-3: closed
ACTION-4: closed; fjh updated the homepage.
ACTION-5: open for finishing.
ACTION-6: open. Konrad will complete in the next week
ACTION-8: closed as part of the editorial update.
ACTION-9: closed. Sent email to the list.
<fjh> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0022.html
<tlr> asks Sean to pass the link of the message
ACTION-12: open. fjh has been working on it...almost done
ACTION-13: closed
ACTION-15: closed; done it 2007-05-14 call.
<fjh> the coordination group will take
care of security issues. when a charter is created it should include security
considerations and how they will be managed, and the coordination group would
take care.
<fjh> EdSimons: should have permanent security group to review materials?
<tlr> it should also do errata handling ...
<Hal> seconds the idea, and also to be in the position of receiving errata of security specifications
<Ed> the group should be the place where the policies and processes are reviewed
<tlr> this is a useful proposal and this could be part of the outcome to be produced by the group. Question to Frederick, what documentation should be managed in the group? only minutes or also reports?
<fjh> we should draft a note.
<tlr> we could capture text from minutes and generate the note.
<fjh> the group should start indicating what the issues are and then we will receive indications on what to do.
<tlr> ACTION: thomas to draft CG note draft for submission to XML CG - due 2007-06-20 [recorded in http://www.w3.org/2007/05/15-xmlsec-minutes.html#action03]
<trackbot-ng> Created ACTION-26 - draft CG note draft for submission to XML CG [on Thomas Roessler - due 2007-06-20].
ACTION-16: closed
ACTION-17: open
ACTION-18: open
ACTION-19: open
<klanz2> ongoing
ACTION-20: done
<fjh> we will indicate when we can meet when we kno. Question: When we will know when we will meet in November plenary?
<tlr> in the next few months...
ACTION-21: closed
ACTION-22: open
ACTION-23: proposal for qnames. Frederick was not sure of the action agreed during the f2f meeting on that issue but this is a timing issue ....
<PHB> qnames should not be used as data
qnames are prefixed or unprefixed, this makes that we must make it explicit that we are dealing with prefixed qnames
<PHB> The prefix namespaces do not work within the data space
<PHB> There is an TAG finding on the topic
<tlr> EdSimon: Said qnames are prefixed or unprefixed; didn't talk about ambiguity. The concern is about prefixed qnames in data space. It's an issue I thought about during the last week WRT c14n
<PHB> The point here was that there should be a note in the C14N section to the effect that prefixes will break, and protocols should avoid them per the TAG
<tlr> hal: Don't agree that only prefixed qnames are a problem
<fjh> asks whether this affects canonicalization
<Greg> suggests treat as best practice
<Zakim> tlr, you wanted to ask whether this is considered critical path for C14N 1.1
<tlr> we should advice core group as soon as we can on the issues we identify
<tlr> nah... we can always ask politely.
<Konrad> suggests only formal objection possible now
<fjh> speaking as self: don't think we need to do more, rather do best practice approach
<EdS> proposed changes to c14n would need to be broader; rather thinking of C14N 2.0
<tlr> ... don't expect resolution near-term ...
<fjh> can we agree on that?
... can we agree on the best practice issue?
RESOLUTION: we are not going to bring the qname issue to the core group but be part of the best practices
<phil> sligthly more than best practices: something that has to be noted as property of the algorithm. It is a consequence of the XML and we should provide more information
<EdS> Strongly agrees with Phill.
<fjh> is it possible to provide more text for CN14.1?
<tlr> we need to coordinate with core as they have been waiting for us
<greg> I would think in a note that would be rather simple: using prefixed qnames values in data then you must use the implicit namespace or the prefixes may not be captured, just for pointing what is not obviuos for all the people
<EdS> +1 to greg
<phil> best practices suggest that you have options, and this would not be the case
<hal> there are also other aspects to basic XML semantics, security considerations... do we want to discuss this now? is a lengthy discussion
<fjh> this is an important topic and we have to discuss....maybe in the next call
<klanz2> no syntactical means for distinguighing from other data that may alsoo look like prefixed names...
<<klanz2> eg: urn:somename
<ed> should get broader attention to this as this may not be an issue only on one type of canonicalization algorithm
<phil> when applying transforms, and you use prefixed qnames, then you have to take into account how to deal with them..
<EdS> Ed: qname discussion not likely to be resolved in short order; will likely lead to significant discussion. Suggests capping c14n 1.1, and getting to work on c14n 2.0 ASAP.
<hal> +1
<Zakim> tlr, you wanted to note that c14N 1.1 is actually explicit
<klanz2> +1 to tlr
<fjh> tlr: table qname issues for now, leave C14N11 as now, future work item
<tlr> if this is relevant, then we should include it for future work... leave C14n1 as it is
<hal> agrees moving on.
<tlr> fjh: phill, can you live with this?
<tlr> phill: yeah *sigh*
RESOLUTION: not to feed C14n1 on the qnames issue
<klanz2> shall we distill some thing for the future work now from this discussion
ACTION-23:> closed
<hal> http://www.w3.org/2001/tag/doc/qnameids.html
ACTION-24:> closed
<fjh> asks members to complete the questionnaire on interop.
<fjh> asks to review the editorial material circulated. Not possible to discuss it now
<EdS> I share Phill's sigh. From my review of c14n 1.1, uddi c14n (http://www.uddi.org/pubs/SchemaCentricCanonicalization-20020710.htm), and the qname issue, my strong initial impression is that it will be best to move from c14n 1.1 to c14n 2.0 ASAP.
<fjh> two or three proposals for workshops?... Austria, Spain, California...
<tlr> peterlipp: would be willing to host in Graz
<fjh> how many days? assumed 2 or 3
tlr mentioned typically 2
<tlr> fjh: do we need face-to-face processing time?
<tlr> ... any difference to the folks who would host?
<tlr> hal: no difference to us
<tlr> peter: no problem
<tlr> juanCC: can do 3
<tlr> three months in advance it announces the workshop. Workshop not earlier than September.
<fjh> people must think on time.
... Avoid first week of September.
Asks Konrad if constraints existent
<PeterLipp> only the first week of september is difficult
<fjh> might be an advantage having in Europe for attracting European people. Would producing a questionnaire for getting information be a good idea?
<tlr> Elaborating rationale for supporting one option or the other: if we konw that a big part of XML security community is on West Coast, that would be a good reason for having it there, on the other side if having it in Europe would attract enough European people that would be a reason for having it in Europe.
<fjh> generally agreed not to have 1st week of september
<fjh> Juan Carlos Has to make bookings in advance, has made bookings. Needs to know in advance, October also possible
<tlr> make a poll on the email for the location
<ghogben3> add October?
<tlr> first week of October also possible.
<Zakim> tlr, you wanted to ask for clarification
<Hal> main relevant input coming from people that have implementation?
<tlr> good question, discuss it through email
<tlr> ACTION: thomas to put up WBS for known constraints in SeptembeR/October [recorded in http://www.w3.org/2007/05/15-xmlsec-minutes.html#action04]
<trackbot-ng> Created ACTION-27 - Put up WBS for known constraints in SeptembeR/October [on Thomas Roessler - due 2007-05-22].
<fjh> review the links in the agenda and take a look to the material linked.
<fjh> ajourns the meeting.
<klanz2> thanks bye