W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2001

Re: xmlenc Call 13:00 EST May 14

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Fri, 11 May 2001 15:58:19 +0900
To: xml-encryption@w3.org
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>
Message-ID: <OF0027DB75.D1BCB04A-ON49256A49.001E2C79@LocalDomain>


We apologize for not responding to these sooner.

>- Maruyama: update the Encryption/Signature Transform

We just updated our note on this according to the comments in the previous
FTF meeting: (See attached file: dt-note.html)

>- Maruyama: an email exploring the question of our processing model

We believe the spec should be as simple as possible, and our current
processing model, where data is processed as an octet string, is really
simple.  Hence, after a discussion, we reached a thought that we leave our
processing model as it is and implementors are responsible for how to
implement it, though it may be a little difficult to implement because
implementations based on DOM or Infoset (like ours) may not preserve an
octet string when serializing nodes because of reordered attributes,
normalized attribute values, expanded entity references, etc., and it is
unclear how to parse the serialized nodes in a context.  We are now trying
to show some hints for a DOM-based implementation.

Tokyo Research Laboratory
IBM Research

From: "Joseph M. Reagle Jr." <reagle@w3.org>@w3.org on 2001/05/11 06:39 AM

Please respond to "Joseph M. Reagle Jr." <reagle@w3.org>

Sent by:  xml-encryption-request@w3.org

To:   "XML Encryption WG " <xml-encryption@w3.org>
Subject:  xmlenc Call 13:00 EST May 14


Monday, 13:00 EST (1pm) 14-May-01.
Call Tobin bridge (+1-617-252-7000)


The Overview URL for this group is at:

- July 20th FTF logistic details.


Checking in on Action Items

- Eastlake: draft a more complete algorithm section
- Maruyama: update the Encryption/Signature Transform
- Maruyama: an email exploring the question of our processing model
- Dillaway/IMAMURA: send proposed text on clarifying about what kind of
information is carried in KeyInfo

Closing Previously Identified Issues

- Can we move away from KeyRetrievalMethod towards RetrievalMethod with a
particular type? (Not much more discussion on the list, let's decide one
or the other.)
- CipherData needs more structure for a reference or the actual value.
- NameKey: needs a better name. Candidates include "FriendlyKeyName"
(discussed on last call), "CarriedKeyName" (now proposed by Reagle), or
NamedKeySelection" or "KeyIndex" (proposed by Hirsch).  (Not much more
discussion on the list, let's decide one way or the other.)

Recent Issues on the list (I haven't caught up on all of these yet, so I
haven't broken out the issues yet).

- support for signing plaintext and ciphertext (Herzberg)
- Comments on the 6 Apr Draft (Dillaway)
- Re: Latest Rough Draft (Farrell )
- Kudos and Comments on XML Encryption Requirements working draft (Miller)

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

Received on Friday, 11 May 2001 02:58:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:00 UTC