Re: xmlenc Call 13:00 EST May 14

Hi,

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.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com



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>
cc:
Subject:  xmlenc Call 13:00 EST May 14



DATE AND TIME

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

BACKGROUND

The Overview URL for this group is at:
         http://www.w3.org/Encryption/2001/

NEWS
- July 20th FTF logistic details.

AGENDA

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
way
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)
http://lists.w3.org/Archives/Public/xml-encryption/2001May/0000.html
- Comments on the 6 Apr Draft (Dillaway)
http://lists.w3.org/Archives/Public/xml-encryption/2001May/0002.html
- Re: Latest Rough Draft (Farrell )
http://lists.w3.org/Archives/Public/xml-encryption/2001Apr/0020.html
- Kudos and Comments on XML Encryption Requirements working draft (Miller)
http://lists.w3.org/Archives/Public/xml-encryption/2001Apr/0028.html

__
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/