Re: Additional Part 1 feedback

Hi Tommy,

Thanks for your new feedback, as usual.

I made all the changes and committed them.

I am wondering if there's a better way to phrase p. [205] and p. [221]
wrt the "Indeterminate" status value.

<quote>
[205] ... Servers may ignore the "Indeterminate" <Status> status value and
Clients MAY set "Indeterminate" as status value.
</quote>

<quote>
[221] ...Servers may ignore <UnverifiedKeyBinding>'s <Status> value of
Indeterminate and Clients MAY set Indeterminate as status value.
</quots>

It just seems' awkward to have a ">'s". I think that this should be turned
around to say that although Clients MAY set Indeterminate as a status value
in their request, Serveys may ignore it.

See my in-line comments for other changes.

Thanks for all your help :)

-jose

On Mon, Apr 25, 2005 at 08:05:01AM +0100, Tommy Lindberg wrote:
> 
> I went through Part 1 [1] once more and made the following notes.
> 
> [25] There is still a QName reference. I think it is enough to remove the last
> sentence of this paragraph and change the preceding one to "This means
> that namespace
> prefixes are omitted for all element names and type names.".

Done.

> [56a] Two lines below "Requestor processing of the Status Response
> Message" Failed should be Failure.

Done.
@@ Say where I changed it too.
 
[151] Paragraph ends with two full stops.

Fixed.

> [134] The attribute name is a Failure not Failed.

Fixed.

> I also wonder if it would not be clearer to replace the three almost
> identical sentences:
> "In the case of a non-compound request, the operation that completed
> has status ..."
> 
> by inserting a single sentence of the form
> 
> "In the case of a non-compound request, the status is indicated in the
> ResultMajor
> attribute."
> 
> immediately preceeding [134].

I removed the duplicate text. I changed [134] and added a 
new [134a] as follows:

<quote>
134]The <StatusResult> element returns the status of a pending request. In
the case of a non-compound request, the status is indicated in the
ResultMajor attribute. For a compound request, the status of each of the
inner compound requests is indicated with three different optional
attributes, defined here below.

[134a]The StatusResultType inherits the element and attributes of
ResultType and contains the following additional attributes for reporting
the status of compound requests:
</quote>

It's a bit redundant, but I think it conveys the sense in a clear way.
It could be improved by saying what's the meaning of the ResultMajor
attribute for compound requests.

> [221] and [226] suggest that there is a <ResultCode> element, which is
> not the case.
> It may be sufficient to say something like "result code NoMatch" instead.

Fixed.

> [231] "complete" -> "completely"

Done.

> [243] Replace colon in "element:" with "."

Done.
 
> [249] Delete semicolon in "Appendix C. 1.3.;"

Done and quoted it correctly as Appendix C.1.3.

> [268] The <xenc:EncryptedData> elements in the spec sample do not have Type nor
> MimeType attributes.  I am not saying they should have them, I am
> simply making you
> aware of this. Personally I don't think it would hurt to examplify
> what is stated in [303].
> If you do decide to make the modification, the affected samples (a
> total of 2 I believe)
> remain valid, as they are not signed.

Added as attributes of xenc:EncryptedData.

> [293] Delete colon in "element:"

Done.

> [303] "return Sender.ProofOfPossessionRequired result" -> "return a
> Sender.ProofOfPossessionRequired result"

Changed, but it was p. [315].

> [350] "Some features as specified as" -> "Some features are specified as"

Fixed.

 
> [373a] "<locate> .... </locate>" -> <LocateRequest> .... </LocateRequest>"

Fixed.

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS-PR-PUB/PR-PUB-xkms-part-1.html