Re: Misc editorial

Hi Jose -

Sorry for late response.  Here are some comments.

>First I have a question. I couldn't find this in the spec. When the client
>gets back a ResultMajor Pending, but didn't propose any
>PendingNotificationMechanism, how does it know what it has to do (which in
>this case seems to be that it needs to poll the server until it
>get backs a reply other than ResultMajor Pending). If this is the case and
>this is not in the spec., maybe we should add it.

The spec says that the service MAY use the notification mechanism
indicated by the
client, it does not have to do it.  Therefore, it may be prudent of a
client implementation to not rely only on notification to indicate
when to issue the PendingRequest but to also to poll using
StatusRequest, after all the notifcation may never arrive.

>   <km:PendingNotification Mechanism="urn:ietf:rfc:2616"
>             Identifier="http://notify.example.com/bob"/>

>(From my understanding, the client tells the server it can contact it
at that URL
>to send its notification).

Yes, the URL is where the client expects to receive notifications.

> we should add a <PendingNotification> element to 2.5.3.1.

Yes, that seems like a good idea. I'd say one example is enough. Using
the SMTP variant
may be easier to relate to, at least this is what was mostly used
during interop, some
people even provided working e-mail addresses :)

   <km:PendingNotification Mechanism="urn:ietf:rfc:822"
             Identifier="mailto:alice@example.com"/>

> I'd like to have your help here for describing, e.g., what you did in your
> own server ...

The structure of the message, in both HTTP and SMTP based
notification, is not defined by
the XKMS spec so I used free text consisting of a polite preamble and
then a statement
indicating that the result corresponding to a specific ResponseId is
ready to be picked up.
I imagine that for some notification mechanisms it may in some cases
be useful to specify
a structure to facilitate integration with other applications; this
would be defined elsewhere.

I took the liberty of identifying potential additional adjustments to the text::

[55] Asynchronous processing consists of a sequence of
request/response pairs; an initial
request which specifies the request values, zero or more status
requests and a pending
request which obtains the result of the operation.  The client may
issue status requests in
order to poll the status of an asynchronous operation independant of
the use of the
notification mechanism indicated [by the client] in the initial request.

Somewhere below [56]:
Register request as pending completion, poll processing status and/or
wait for notification.

[57] The client determines, through notification or polling, that the
requested operation has
completed and requests the return of the result values by issuing a
PendingRequest
message as follows:

2.5.1b Status Request
The client may poll the status of the asynchronous operation as follows:

Requestor generation of the Status Request Message
    The request element is StatusRequest
    OriginalRequestId is set to the value of Id in the initial request message
    ResponseId is set to value of Id in the initial response message
Service processing of the Status Request Message
    Identify pending request using OriginalRequestId and ResponseId.
Service generation of the Status Response Message
    RequestId is set to the value of Id in the Status Request message
    Nonce is not present    
Requestor processing of the Status Response Message
    For non-compound messages, the ResultMajor attribute indicates the
status of the
    operation.
    For compound messages, the Success/Failed/Pending attributes
further indicate the
    number of inner requests that have the respective status.

As a result of searching the rest of spec for occurences of "notif"
you may also consider
the following adjustment
From: [81] After the appropriate notification has taken place, the
client issues ...
To: [81] When the service has completed the processing, as determined
through polling or
notification, the client issues ...

In 2.5.3.5, the ResultMajor seems to be missing the XKMS namespace.

Reasonably close to [54] there is a statement "ResponseMechanism
values Represent
and/or Pending MAY be specified" that I think should not be there as
this advises the
service that the client is prepared to support either two-phase or
asynchronous processing
which is not what that paragragh is trying to describe and would therefore
only potentially confuse the reader.  It is true that those response
mechanisms may be
specified but then the documented processing steps rely on the service
not supporting
either of them or that it for some other reason elects to respond synchronously.

In 2.5.2

Under "Service generation of the Pending Response Message" the
statement "ResponseId
is set to a randomly generated unique value" does not belong there. 
Maybe what is meant
is "The Id of the response ..." in which case it would be valid.

Regards,
Tommy

On 4/8/05, Jose Kahan <jose.kahan@w3.org> wrote:
> Hi Tommy,
> 
> On Thu, Apr 07, 2005 at 04:57:44PM +0100, Tommy Lindberg wrote:
> >
> > >> 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.
> 
> I need some further input from you :) I talked with Shivaram last night
> and he agreed we should change this one. However, he notes that this is an
> example, so we should complete it.
> 
> First I have a question. I couldn't find this in the spec. When the client
> gets back a ResultMajor Pending, but didn't propose any
> PendingNotificationMechanism, how does it know what it has to do (which in
> this case seems to be that it needs to poll the server until it
> get backs a reply other than ResultMajor Pending). If this is the case and
> this is not in the spec., maybe we should add it.
> 
> Now for the example. I think that we either need two examples or a single
> one. Right now, this example is misleading in that there's no
> PendingNotification element, but 2.5.3.3 (regardless of its actual
> content) gives the idea there somehow was a notifcation. If this is the
> case, we should add a <PendingNotification> element to 2.5.3.1.
> And then, we should update the text of 2.5.3.3 so that it reflects
> something accordingly to the Identifier of the PendingNotification,
> element.
> 
> I'd like to have your help here for describing, e.g., what you did in your
> own server, when using:
> 
>     <km:PendingNotification Mechanism="urn:ietf:rfc:2616"
>               Identifier="http://notify.example.com/bob"/>
> 
> This way we can have a real example. This doesn't keep us from updating
> the text to tell again that the content of the notification request and
> how it actually happens is out of scope of this spec. (From my
> understanding, the client tells the server it can contact it at that URL
> to send its notification).
> 
> If we want an example where there's no <PendingNotification> in the
> initial request, we can just substitute the content of 2.5.3.3 by
> "The client waits some instants before polling the server."
> 
> If we want both examples, we can add them. It won't be a problem. We just
> need to agree on what we want :)
> 
> Comments?
> 
> -jose
> 
> 
>

Received on Wednesday, 13 April 2005 21:32:21 UTC