See also: IRC log
<fjh> ScribeNick:klanz2
Hello
<scribe> chair: Konrad is the Scribe
fjh: Teleconference 3 July?
... are there regrets
Miller: regrets
Sean: regrets
fjh: prefer not to have the call ...
greg whitehead: leave hp, will dropp of some groups
tlr: will there be a successor
greg whitehead: talk to tlr after the call
fjh: proposes to cancel 3rd of July call
<tlr> seconded
RESOLUTION: 3rd of July call cancelled
<fjh> minutes http://www.w3.org/2007/06/12-xmlsec-minutes
fjh: revised minutes, re attendence
RESOLUTION: Minutes accepted
ACTION-26: continued
ACTION-35: continued
ACTION-36: closed
Close, see http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0046.html
ACTION-37: sean will suggest some things
ACTION-38: closed with no Action ...
nothing to add to JCC analysis
<eastlake> Hi, Sorry but I have to be on another teleconference until 9:30
ACTION-48: closed, comment dropped due to some overseen text
<tlr> http://www.w3.org/2007/xmlsec/Group/track/actions/48
<fjh> http://www.w3.org/2007/xmlsec/Group/track/actions/48
jcc: provide link later in the call
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0046.html
jcc: subject should be ACTION-48
tlr: will reopen action-36
jcc: no, action-36 is also closed
tlr: fixed up links in tracker
ACTION-48: closed
ACTION-49: closed
<scribe> Done see http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.html
ACTION-50: open
ACTION-51: closed
<scribe> Done, see http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0033.html
<fjh> 49 closed with http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0028.htm
<fjh> Announcement on web: http://www.w3.org/2007/xmlsec/ws/
fjh: approved by W3C, updated version availiable
<fjh> cfp http://www.w3.org/2007/xmlsec/ws/cfp.html
fjh: request for position papers
tlr: page not yet public, will be
public until tomorrow
... start propaganda in one or two days
fjh: will there be different uri
tlr: access permissions will be
changed
... will send explicit message to the list to get propaganda
started
fjh: proposed to publish
<fjh> and also go to Last Call
RESOLUTION: WG agrees to bring Decryption Transform to publication and Last Call
tlr: short names need to be
considered ...
... current short name is ...
<tlr> http://www.w3.org/TR/xmlenc-decrypt
<tlr> xmlenc-decrypt11
fjh: should we change the title ...
<fjh> document http://www.w3.org/2007/xmlsec/Drafts/xmlenc-decrypt.html
<fjh> no need to change title, editors draft already updated
tlr: proposed xmlenc-decrypt11 as short name
RESOLUTION: WG agrees to use xmlenc-decrypt11 as short name for Decryption Transform to publication in Last Call
<tlr> tlr: it's actually "ask for permission", but that's ok. ;-)
tlr: is editor, take over from xml core ...
RESOLUTION: WG to ask XML Core to hand over ownership of the dsig-usage note to this working group
<EdS> I agree.
+1
<tlr> ACTION: thomas to ask XML Core chairs for dsig-usage note [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action01]
<trackbot-ng> Created ACTION-52 - Ask XML Core chairs for dsig-usage note [on Thomas Roessler - due 2007-06-26].
<tlr> ACTION: thomas to work toward publication of xmlenc-decrypt11 as Last Call WD [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action02]
<trackbot-ng> Created ACTION-53 - Work toward publication of xmlenc-decrypt11 as Last Call WD [on Thomas Roessler - due 2007-06-26].
fjh: questionnaire: C14N11 - 4 yes, timing - early Q3?
DSig Core - 4 yes, early Q3?
Decrypt Transform - 10 No's. No interop?
fjh: is C14N11 possibile in Q3 ...
<sean> late summer would be better, maybe August
<fjh> klanz2: started work on implementation, test cases
<fjh> ... maybe need repository for test cases
<jcc> late August mid September...
klanz2: test cases rather early, cvs repository would be helpful
fjh: feasible to do interop at the same time workshop
<fjh> ACTION: phil to check whether we can add time to Sept F2F for interop [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action03]
<trackbot-ng> Sorry, couldn't find user - phil
tlr: do we need to change cfp
?
... why would this impact the cfp
... proposed to phrase it as part of the workshop
greg whitehead: I thought we would make this after the workshop
fjh: keep a full workshop, add time for WG interop after, in addition to workshop
check with phb whether we could continue after the workshop at versign with interop
<fjh> not lose workshop time
tlr: one more thing end up doing, put pointers on the home page ...
fjh: we propose additional half day ...
tlr: will have to go to W3C manegerial level ...
<tlr> ACTION: thomas to check with phill whether we can add time to Sept F2F for interop [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action04]
<scribe> ACTION: thomas to ask whether we can add time to workshop [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action05]
<trackbot-ng> Created ACTION-54 - Ask whether we can add time to workshop [on Thomas Roessler - due 2007-06-26].
<fjh> change "add time" to "add an additional 1/2 day after workshop"?
<tlr> ACTION: thomas to create questionnaire to check availability on 27 September [recorded in http://www.w3.org/2007/06/19-xmlsec-minutes.html#action06]
<trackbot-ng> Created ACTION-55 - Create questionnaire to check availability on 27 September [on Thomas Roessler - due 2007-06-26].
<fjh> change 1/2 day to 1 day
tlr: puts up questionnaire
<fjh> everyone please respond to questionnaire
<tlr> hello?
<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-X509Data
<tlr> apologies
fjh: red line corrects the first two bullett items
<fjh> "To encode a distinguished name (X509IssuerSerial,X509SubjectName, and KeyName if approriate), the encoding rules in section 2 of RFC 2253 [LDAP-DN] SHOULD be applied, except that the string encoding rules in section 2.4 of RFC 2253 [LDAP-DN] should be augmented as
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0051.html
EdS: does it make sense to make rules at all as no implementations
tlr: two set of questions
... current text RFCs 2253 4514 put together boils down to
...
<tlr> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0033.html
<fjh> tlr: comply with grammar and rfc rule + addtl constraints in dsig core
tlr: coply with grammar
... are the additional rules useful or not ...
... proposal as in the editors draft
<EdS> I can only catch about half of what Thomas is saying due to audio issues.
<fjh> http://tools.ietf.org/rfc/rfc4515.txt
<tlr> proposal: (1) changes as outlined in message; (2) reference 4514
fjh: tlr says we cannot rip it out at all
<fjh> since already in REC
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0118.html
> 1. The schema will not prevent people from having leading or trailing
> whitespace in the content of KeyName (and it shouldn't!). The spec will
> just say that any leading and trailing whitespace MUST be trimmed to obtain
> the actual KeyName.
>
> 2. The code will look something like this:
>
> Node nodeKeyName = XPathAPI.selectNode(doc, "//KeyName/text()"); // get
> the text content of <KeyName>
> String strNodeKeyName = nodeKeyName.nodeValue();
> String strKeyName = strNodeKeyName.trim();
> KeyResolver.resolveWithKeyName(strKeyName);
>
Tom Gindin
Merlin Hughs
<fjh> is konrad proposal to remove "*Escape any trailing space characters (Unicode \x20) by replacing them with "\20", instead of using the escape sequence "\ ".
<fjh> ?
Why would someone really care to type a DNAME as follows
<DName> CN=foo \20
</DName>
instead of
<DName> CN=foo \ </DName>
<fjh> tlr: reason for \20 is to protect significant whitespace in XML processing
rich: xml layer
... is not necessary
<fjh> Rich: normalizing space was a use case for this that is not being used
tlr: we should record unecessary
feature
... deal with in futire iterations since not simply errata
<fjh> http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-X509Data
fjh: remove in future versions
<EdS> I think the point of this section was robustness -- clearly indicating indicating whether trailing white space that happens to be in a KeyName is significant or not. Some lazy apps may include irrelevant trailing white space that should NOT be treated as relevant by receiving applications.
<fjh> question - is removal of whitespace escaping a conformance issue if this material is lowercase "should"
<fjh> klanz2: corner case nobody uses, why not remove?
<EdS> I shouldn't have said in my statement above "the point" but rather "one of the points".
<EdS> Let's continue to discuss on the list.
<fjh> rich: in favor of removing \20 processing rule for DNames
<fjh> klanz2: no need for unicode bullets, normal XML processing
<fjh> edS: agrees with klanz2 on no need for unicode or std xml processing points
<fjh> tlr: distinguish creation and receiver processing
<fjh> ... removing might impact receivers that rely on it
<fjh> ... not impact conformance requirement, concern
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0118.html: The spec will
just say that any leading and trailing whitespace MUST be trimmed to obtain
the actual KeyName.
but that never seems to have made it into the spec
<fjh> grw: agrees to remove but not in an errata release, should do in next version
<fjh> ... this is more of an enhancement
<fjh> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0118.html
<EdS> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0229.html