Re: Additional Part 1 feedback

That looks good to me, Jose.

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