Re: Additional Part 1 feedback

Hi Tommy,

Regarding p. [205]...

On Thu, Apr 28, 2005 at 12:00:02AM +0100, Tommy Lindberg wrote:
> 
> 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."

Hmm, rather than changing [202], I added the explanation in [206a] and
put the Indeterminate explanation there:

<quote>
[206a]Note that the X-KRSS {Revoke, Reissue, Recover} KeyBinding elements are all of
type KeyBindingType, which requires a Status element (c.f. Section 7). In
the case of Reissue, Revoke, and Recover requests, servers MAY ignore the
Indeterminate <Status> status value and Clients MAY set Indeterminate as
status value.
</quote>

I would have talked first about clients, then servers (who sets that value
first, who reads it afterwards), but I can live with it.

Could you tell me if the new [206a] and changed [205] convey the correct
meaning?

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

Thanks! I've fixed it and added a change log entry.

> 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.

I think it can stay as it is, as the schema fragment below 5.1.7 quotes
defines the values as such. The examples also have the XKMS ns.

[snip]

Thanks!

-jose