W3C home > Mailing lists > Public > www-xkms@w3.org > April 2005

Re: Additional Part 1 feedback

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Thu, 28 Apr 2005 00:00:02 +0100
Message-ID: <18ec59cc05042716004eb9d8d4@mail.gmail.com>
To: jose.kahan@w3.org
Cc: www-xkms@w3.org

Hi Jose -

> How does this wording sound for that [205] text:
> 
> <quote>
> A request that includes a <KeyBinding> Element may use a <Status> with
> a StatusValue attribute with value indeterminate. A server will ignore
> the Status element in this case.
> </qute>
> 
> And I would remove it from [205] and put it as [206a].
> 
> Comments? If there are no comments, I won't make this change.

The original issue raised by Frederic [1] is surrounding the use of
StatusValue Indeterminate in {Reissue, Revoke, Recover}KeyBinding's -
which are by inheritance also KeyBindingType's.  Requests don't
contain KeyBinding elements but rather {Reissue, Revoke,
Recover}KeyBinding elements; depending on the request of course.

The current phrasing of [205] actually correctly reflects this, but
what makes it confusing is that {Reissue, Revoke, Recover}KeyBinding
is never mentioned in the entire section 5.1.7.

Maybe you could prepare the reader by adjusting [202] to include,
either explicitly or otherwise, the additional element's and then,
like you suggest, move and augment the explanatory text surrounding
status value Indeterminate from [205] to [205a] or [206a].

Assuming an adjusted [202] here's some candidate text:
"In the case of Reissue, Revoke and Recover, servers MAY ignore the
Indeterminate <Status> status value and Clients MAY set Indeterminate
as status value."

I also note that there is mention of AssertionType and AssertionStatus
in section 5.1.7 - this should be KeyBindingEnum.

Do you think it would be worth mentioning that
{Valid,Invalid,Indeterminate} should in fact be pre-appended with
http://www.w3.org/2002/03/xkms#? Can't remember how consistent that is
throughout the spec.

> > [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."
> 
> Changed the last part to read:
> ""... inner request, that inner request is assumed to
>       have failed".
> 
Your wording is a lot better.

Regards
Tommy

[1] http://www.w3.org/2001/XKMS/Drafts/cr-issues/issues.html#331-fdl
Received on Wednesday, 27 April 2005 23:00:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:24 GMT