Re: Misc editorial

Hi Tommy,

Thanks for your comments.

On Tue, Apr 05, 2005 at 11:20:58PM +0100, Tommy Lindberg wrote:
> 
> The figures in [154] and [237] contain markup pertaining to the
> initial XKMS submission that is no longer valid - Query, KeyID,
> Prototype and AuthInfo.  This may have been pointed out before.


If it had been pointed out before, I've just discovered it. Thanks!

How does it sound if I do the following changes in Figure 3 [p 154]:

- <Query> to 
   <ValidateRequest>

- Result=Valid to 
  <ValidateResult
   ResultMajor=Success">

I just groan ahead of time as I think I'll have to redo the figure
from scratch.

For Figure [237], how about the following changes:

- <Prototype><AuthInfo> to

  <RegisterRequest>
  <PrototypeKeyBinding>
  <Authentication>
  <ProofOfPossesion>

- <KeyBinding> to

  <RegisterResult>
  <KeyBinding>

> The <Result> fragment in 2.5.3.3 is lacking a Service attribute.

I added it.  I am a bit confused. Isn't it also lacking an Id attribute
or something to relate it to the pending request? Also, is
<Result> the element we need to use in the notification?

From what I know the spec doesn't define how a server notifies the client
that a pending request is processed. That's why I get confused with 
<Result>.

> The table in paragraph [122] has entries for the ResultMinor codes
> ProofOfPossessionRequired, TimeInstantNotSupported and
> TimeInstantOutOfRange that specifies the ResultMajor code Receiver to
> be used.  This is inconsistent with the text in [311], [315] and [213]
> which indicate that a ResultMajor code of Sender must be used.  At the
> time, I thought that Sender would be appropriate for all.

<meditation>
Looking at the table and the use of Receiver and Sender in other cases,
it seems that the rule of thumb is to use Receiver when the receiver
doesn't support something and sender, when the message is missing
something. See for example OptionalElementNotSupported.

We could say that the message was correct, but the server didn't support it.
Following my reasoning, ProofOfPossesion should be sender and the
others can stay Receiver.
</meditation>

But maybe I'm interpreting this incorrectly. Any other ideas are welcome.
I'm happy with one or the other. Let's just choose those that make sense.


> Unrelated to this, I will submit an updated sample set in a day or two.

Thanks! Are these sample message exchanges with your server?

-jose