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

Re: Misc editorial

From: Tommy Lindberg <tommy.lindberg@gmail.com>
Date: Thu, 7 Apr 2005 16:57:44 +0100
Message-ID: <18ec59cc050407085710811ccc@mail.gmail.com>
To: jose.kahan@w3.org
Cc: www-xkms@w3.org

Hi Jose -

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

You may want adjust it to reflect the fact that <PendingNotification>
is optional i.e. it may not be present and that the service therefore
uses an out of band notification mechanism.

> OptionalElementNotSupported     Receiver
> ProofOfPossessionRequired       Sender
> TimeInstantNotSupported         Receiver
> TimeInstantOutOfRange           Sender

> However, if this still doesn't make sense to you 
It makes sense.

Regards,
Tommy

On Apr 7, 2005 3:57 PM, Jose Kahan <jose.kahan@w3.org> wrote:
> 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 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
> 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.
> 

> 
> 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
> 
> 
>
Received on Thursday, 7 April 2005 15:57:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:43 UTC