[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] Asynchronous Profile wd01
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]