Re: KeyInfo type URIs

Hi Joseph,

Looks good; I like this structure better.

Minor nitpick on section 4.4:

"The following list summarizes the KeyInfo types defined in
 this section."

The list is a) not an exhaustive list of the KeyInfo types
defined in the section (reading "type" as described in the
first paragraph, and not as "identifier") and b) not
exclusively composed of KeyInfo types (if "KeyInfo types"
refers just to elements of the KeyInfoType choice).

Perhaps you'd consider a reordering:

===

4.4 The KeyInfo Element

Existing paragraph: KeyInfo is an optional element...

Existing paragraph: If KeyInfo is omitted, the recipient...

Existing paragraph: The schema/DTD specifications of these types...

The following list summarizes the types of KeyInfo and KeyValue
that are defined in this section, that may be used within the
Type attribute of RetrievalMethod and Reference elements to
describe the referent key material.

[ list 1 ]

Existing paragraph: In addition to the types above...

[ list 2 ]

===

I don't really like the 4-line paragraph above, and it
forward-references KeyValue and RetrievalMethod; you might
prefer some clearer explication. Also, sticking those three
existing paragraphs together triplicates the articulation
that keying information may be brought in from external
namespaces. But that is really of minor concern.

merlin

r/reagle@w3.org/2001.04.11/21:17:21
>At 10:40 4/10/2001 +0100, merlin wrote:
>>SHA-1. I don't believe that we should use these same URIs
>>to identify the actual public key encoding.
>
>Ok, have a look at the editors' copy now:
>         http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-Key
>Value
>
>
>__
>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/
>
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Thursday, 12 April 2001 12:14:59 UTC