Publications of the Second xenc Candidate Recs

http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/
   ...
   This version now includes (1) clarifications resulting from current
   implementations, see Interoperability Report, (2) a media type
   registry application, and (3) non-normative changes resulting from
   work on the XML Signature Decryption Transform [XML-DSIG-Decrypt]. In
   particular, informational (non-normative) text for implementing
   decrypt and decrypt-and-replace operations were moved to this
   specification's Encrypting XML (section 4.3).

   The exit criteria for this phase continues to be at least two
   interoperable implementations over every feature, one implementation
   of all features, and one report of satisfaction in an application
   context (e.g., SOAP, SAML, etc.) Present implementations must update
   their implementation of [XML-DSIG-Decrypt]; we will continue to
   solicit new implementations. We expect to meet the exit criteria
   within 6 weeks (closing 13 September 2002). Specific areas where we
   would appreciate further experience are:
     * Do implementations achieve satisfactory performance?
     * Does the specification satisfy application scenario requirements
       for encrypting portions of XML, particularly as they relate to
       document validity?

http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020802
   ...
   This version is a signficiant revision: the processing steps have been
   rewriten, a binary mode has been added, and many more examples and
   explainations have been included. Consequently, this specification
   uses a new namespace/identifier for the transform.
   ... Specific areas where we would appreciate further experience are:
     * Do implementations achieve satisfactory performance?
     * Does the specification satisfy application scenario requirements
       for encrypting and signing portions of XML?
     * Do implementors plan on supporting full XPointer expressions in
       the Except URI, particularly when they identify nodes resulting
       from super-decryption (i.e. the replacement node-set)?
     * Presently the specification states signature processing must fail
       if decryption fails; should this be relaxed such that in some
       cases processing can continue?

Received on Friday, 2 August 2002 12:39:59 UTC