Re: [dss] Asynchronous Profile wd01

[Andreas Kuehne <kuehne@klup.de>]

Trevor !

>> Suprisingly it turned to be a bit more core-protocol-invasive than I 
>> expected :
>> Either we allow profiles to extend the protocol with new requests for 
>> polling or we relax the given requests to accept a call with no input 
>> given except the RequestId attribute. I decided for the latter ... 
>> discussions welcome ...
>
>
> Instead of relaxing Requests to contain no input, and Responses to 
> contain no output, I would suggest adding new protocol messages:
>
> C->S: SignRequest
> C<-S: PendingResponse (or SignResponse)
>
> C->S: PendingRequest
> C<-S: PendingResponse (or SignResponse)
> ...
>
> This stretches the definition of a profile, but loosening the core 
> protocols to allow empty messages seems worse.  This is more similar 
> to XKMS, too.
>
Yes, thought about this approach, too. But iirc we agreed to minimize 
the number of differnt request to the three known ones. And I wasn't 
happy to introduce a completely new protocol in a profile. On the other 
hand, this approach has it's beauty. Especially keeping the schema strict !

I'll put together the different choices/aspects and send a 'request for 
comment' ...

> Minor editorial things:

> [...]

Thank you,  I'll update the profile !

>  - If the client indicates support for this profile, is 
> <ResponseMechanism> necessary?
>
The client indicates its support for async adding the 
<ResponseMechanism> element. The server may decide to accept sync 
request despite implementing the async profile. It smells a bit 
redundant, but it isn't.


Greetings

Andreas