Re: Additional Part 1 feedback

Hi Jose -

> [205] and [221]
The <Status> element is not part of part of the UnverifiedKeyBinding
so [221] is strange.  When I look at item 10 in the change log it
seems that the clarifications were intended for KeyBinding and
subtypes.

Some additional typos:
[202] The <status>  -> The <Status>

[78] "... inner request the ResultMajor value failure is assumed for
that inner request."  This should be rephrased as Failure is not part
of the ResultMajor value space, perhaps as "inner request, a
ResultMajor value other than Success is assumed for that inner
request."

Regards
Tommy

On 4/25/05, Jose Kahan <jose.kahan@w3.org> wrote:
> 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
> 
> 
>

Received on Tuesday, 26 April 2005 22:43:36 UTC