Re: Misc editorial

Hi Tommy,

On Wed, Apr 06, 2005 at 05:56:35PM +0100, Tommy Lindberg wrote:
> 
> > How does it sound if I do the following changes in Figure 3 [p 154]:
> 
> Looks good to me.  To convey the same information it might not hurt to add
> 
> <Status StatusValue="Valid">
> 
> below the ValidateResult (XKMS URI deliberatly left out for "Valid").

I recreated the figures with XFig and changed the markup and
added the <Status...> you proposed. I'm glad I enjoy using XFig. 
I commited the changes[1].

> > 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>.
> 
> I believe I commented on this some time ago, but I could be wrong and
> I am too lazy to check.  Like you say, it is at least misleading as
> the structure of the notification is unspecified in  XKMS; for both of
> the notification methods mentioned in the spec (smtp & http).  You
> could replace it with text similar to "The XKMS service notifies the
> client about the completion of the request processing using the
> notification mechanism specified in the <PendingNotification> element
> in the initial request".

I like this text. If there are no objections, I'll make the modification
tomorrow.

> > Looking at the table and the use of Receiver and Sender in other cases, ...
> I used the table in [120] for guidance. The description in the Sender
> row states "An error occured that was due to the message sent by the
> sender" which for me provided the closest match.

I still hesitate a bit as I think that if the client sent a valid
message and the server couldn't interpret it, it would be a receiver
error. Otherwise, the client couldn't know that it was his fault to
send something that the server couldn't interpret. Likewise, if 
the client sent either an invalid message or one with invalid parameters, 
it would be a sender error.

From the above, I'd propose the following:

OptionalElementNotSupported	Receiver
ProofOfPossessionRequired	Sender
TimeInstantNotSupported		Receiver
TimeInstantOutOfRange		Sender

However, if this still doesn't make sense to you and no one raises
any objection, then I'll go with your proposal and use sender on the
last three codes. As we have just introduced them
recently, it's just a matter of agreeing which way they make more sense.

> > Thanks! Are these sample message exchanges with your server?
> Yes, but reformatted with human consumption in mind and with
> signature's recomputed.

Thanks.  I received the message. I'll send you a followup one.

Cheers :)

-jose