Re: Comments on 20030213 Part I

Hi,
 I am unable to get the latest draft copy from ur specified URL
i.e.
http://www.w3c.org/2001/XKMS/Drafts/XKMS20030212/xkms-part-1.html
Can u please tell me, how can I download this latest draft copy.
Thanx.
Yasir Khan

----- Original Message -----
From: "Joseph Reagle" <reagle@w3.org>
To: <pbaker@verisign.com>
Cc: <www-xkms@w3.org>
Sent: Saturday, February 22, 2003 1:29 AM
Subject: Comments on 20030213 Part I


>
> Phill,
>
> Some comments on the latest draft.
>
>    This version:
>    http://www.w3c.org/2001/XKMS/Drafts/XKMS20030212/xkms-part-1.html
>    XML Key Management Specification (XKMS 2.0) Part I: Schema
>    W3C Editors Copy 13th February 2003
>
>   1.2 Definition of Terms
>
>    [16]The following terms are used within this document with the
>    particular meaning indicated below:
>
> I don't think it's ready yet, but the WS glossary might be of use in the
> future. (Or maybe we should point them at our own definitions?)
>   http://www.w3.org/TR/2002/WD-ws-gloss-20021114/#webservice
>
>
>    [39]The means by which the service specifies protocol options which it
>    accepts is outside the scope of this document. If the policy mechanism
>    uses URI based identifiers for this purpose the following identifiers
>    SHOULD be used:
>
> I wouldn't call this a "policy mechanism" but a "service description
> mechanism" since that seems to be the intent (for the URIs to be used with
> WSDL) and avoids the "policy URI" discussion.
>
>
>    [41]XKMS supports two processing modes, synchronous processing and
>    asynchronous processing.
>
> I found these definitions confusing ("channel" is undefined) and proposed
> alternative text that I though you found acceptable but aren't included
> yet:
>   http://lists.w3.org/Archives/Public/www-xkms/2002Dec/0085.html
>
>   2.5 Compound Requests and Responses
>
> I'm glad we have this section and think it is improving but I can't say I
> confidently understand the inter-relationship between the two-phase,
> asynchronous, and compound requests yet on the basis of the prose. Maybe a
> little table/diagram of some sort would be helpful...?
>
>    [66]The <MessageExtension> element is an abstract element of the
>    abstract type MessageExtensionAbstractType. Implementations may define
>    subclasses of the MessageExtensionAbstractType to define message
>    extension elements that may be applied to any XKMS message.
>
> Editorial: in some places element type names are in <code/> elements, in
> others' they are not.
>
>    [78] RespondWith values are specified as QNames, the following
>    identifiers are defined:
>    Identifier <ds:Keyinfo> Element Description
>    xkms:KeyName <ds:KeyName> Key Name
>    ...
>
> The example in 3.1 still doesn't reflect if in fact that things are QNAMEs
> yet.
>
>    [94]The following ResultMinor codes are defined:
>    Code Possible Major Codes Description
>    xkms:NoMatch No match was found for the search prototype provided.
>    Success The result code Success.NoMatch indicates that the service is
>    authoritative for the search prototype specified and that the service
>    positively asserts that no matches exist.
>
> I don't understand, are the ResultMinor Codes, QNAMEs? If so, are they
> expect to be composed with a ResultMajor code? If so, I wouldn't think the
> code is "Success.NoMatch" but a QNAME tuple (xkms:Success,xkms:NoMatch) or
> some composition "xkms:Success.NoMatch".
>
>    [95]The <RequestSignatureValue> element provides a cryptographic
>    linkage between the request and the response.
>
> "RequestSignatureValue" can be mistakenly read as an actual request for a
> Signature from the service, instead of the SignatureValue corresponding to
> the Request. If we can't think of a less confusing name
> (<SignatureValueOfRequest>?) we should at least point out at the start
that
> this is not a request.
>
>    [140]A Key Binding asserts a binding between data elements that relate
>    to a public key including the <ds:KeyName>, <ds:KeyValue> and
>    <ds:X509Data> components contained in a <ds:KeyInfo> element.
>    Furthermore, the Service represents to the client accessing the
>    service and in the absence of specific undertakings to the contrary to
>    that client alone that the binding between the data elements is valid
>    under whatever trust policy the service offers to that client.
>
> I don't know what "the absense of specific undertakings to the contrary"
> means and it sounds like legalize. Could we just remove that term?
>
>    [211]The <UnverifiedKeyBinding> element is derived from the
>    KeyBindingAbstractType. It describes a key binding but makes no
>    assertion regarding the status of the key binding.
>
> This is intended to be use only with Locate, right? If not, what does it
> mean in the context of a Validate request. (If so, perhaps we could add a
> sentence here to that effect.)
>
>    [381]The section describes features and operations that XKMS
>    applications whose support is either required or recommended to ensure
>    interoperability of XKMS services.
>
> "This section".
>
>      * [384] sent by by another
>
> "by"
>
>      * [386]If support for a feature is specified as OPTIONAL, XKMS
>        implementations SHOULD NOT send messages requiring support for a
>        feature.
>
> "support for that feature."
> BTW: This OPTIONAL = SHOULD NOT was counteruntuitive at first but as I
> continue to test it in my reading of the specification it seems to make
> sense...
>
>    [431]Two-Phase Request
>    [433]RECOMMENDED+
>    [434]Clients SHOULD support use of the two phase request protocol.
>
> As you did in Asynchronous response, could you provide a small
explaination
> of the dependency that makes this a '+'?
>

Received on Monday, 3 March 2003 07:47:01 UTC