Minutes of 000217-tele

http://www.w3.org/Signature/Minutes/000217-tele

Participants

     * Donald Eastlake 3rd, Motorola
     * Joseph Reagle, W3C
     * Ed Simon , Entrust Technologies Inc.
     * (regrets) David Solo, Citigroup
     * Mark Bartel, JetForm Corporation
     * John M. Boyer, PureEdge
     * Raghavan "Rags".Srinivas, Sun Microsystems

  Status of documents < 5 minutes

     * Last Call dead-line is fast approaching.
     * Requirements is now in RFC-editors queue.

  Signature Syntax & Processing draft questions:

     * Section 2 re-write as example (10 minutes)
       Bartel, Boyer, Eastlake, Reagle like it. ACTION: Move forward with
       the new organization.
       2.1.1 Uses transforms, using a base64 transform. Change example to
       Canonical XML.
     * Section 6.6.3 XPath re-write (10 minutes)
       Eastlake: question about serialization of line feeds. John
       clarifies ... .
       Reagle: seems like a complex section, might frighten people, but I
       expect if people want to do this, this level of specificity is
       necessary. ACTION: go with this and see if there are further
       comments on the list and at last call.
       Eastlake: Aside, add a sentence in editorial convention say we
       don't rely upon default in DTD/schema.
     * URI/IDREF again (10 minutes)
       Eastlake: Reagle's text MUST understand URI syntax, but not all
       scheme and methods, "XML Signature applications MUST be able to
       dereference (obtain the octets associated with) the resource
       identified by a URI (e.g, DOM, an API, network method). " Must
       understand URI syntax, scheme is application dependent.
       Bartel: and we recommend HTTP.
       Reagle, Eastlake, Boyer, Bartel want to go forward.  Simon and
       Srinivas had not had a chance to read it yet.
       ACTION Reagle: touch bases with all those at last FTF to make sure
       they are comfortable with moving forward.
       Boyer: similar to understanding some of XPath, makes a distinction
       between unverifiable versus invalid.
       Eastlake: if we were doing a more API type specification, we would
       probably have focussed on the processor model a bit more.
       Eastlake: put something in Section 3 that makes it clear there is
       a potential state of unverifiable even if it might be valid.
       Simon: speaking of returning something other than invalid if the
       algorithm isn't available.
       Boyer: in XPath, "throw an exception to show the particular
       function/algorithm is not available."
       Eastlake: write two sentences as proposal for unverifiable.
     * DTD/Schema inline/appendices (8 minutes)
       Stay with what we have.
     * Place for semantics (10 minutes)
       Go with text as it is minimal and clarifying: "While the signing
       application should be very careful about what it signs (it should
       understand what is in the SignatureProperty) a receiving
       application has no obligation to understand that semantic (though
       its parent trust engine may wish to)." More extensive text can be
       proposed, but go with we have and we'll probably get comments and
       arguments.
     * Other topics (7 minutes)
       Boyer: present XPath specified (in DSig) doesn't preserve the DTD
       or declaration. John could change it if necessary, are there any
       requests? Also, preserving order of comments in and around that
       declaration could be done, but seems too complex.
       Boyer: little difficulty with idea that we'd have an XPath
       specified in UTF-8 that operates over a UTF-16 document. The XPath
       application will be comparing a 3 byte sequence for a 16 byte
       sequence. Eastlake: present text seems ok. Reagle: an Xpath
       application could use whatever internal representation it wants
       but should be able to handle this regardless.
       Generate a candidate last call by 21st, move forward with last
       call on the 28th.




_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Thursday, 17 February 2000 14:03:02 UTC