Re: Meeting reminder next Tue 22/Feb/2005 and agenda item

Jose,

We've always punted on wsdl, though I agree that it'd be nice
to have wsdl for xkms. However, I wouldn't want it to become a
blocking factor, or we'll all be here for another year!

If the list you want can be easily constructed, then that's
fine. If not, I'd argue that implementing any protocol requires
more than just reading the spec - that's why we archive the
mailing list etc, and I'd argue further that xkms is actually
quite a good protocol spec - the fact that the implementations
were done and worked is the most significant fact. Lastly we
also produced samples etc, which effectively act as an
additional guide to implementers. So, I don't think that this
wsdl/list is a must-have, but a nice-to-have, and it ought'nt
slow our progress.

Having said that, anyone want to volunteer for this?
Stephen.

Jose Kahan wrote:

> Hi folks,
> 
> Please don't forget we have a meeting next Tuesday. 
> 
> For an agenda item, I'd like to talk about the current status of moving
> to PR and need the WG's feedback.
> 
> I've been working on the implementation report. Right now we have
> a test suite and enough implementation results. What we are missing
> is the developer's opinion, their success story. The story that
> the report has to tell if the XKMS spec is complete enough as it
> is to be useful. And we need to give enough implementation experience
> to prove that it is an usable specification. After announcing the PR,
> the W3C AC members will go thru the spec and this implementation report
> can be a very good point to us, in showing that XKMS can be implemented
> in an interoperable way and that the spec is complete enough. The more
> comprehensive we make the implementation report, the more reasons we are
> giving as to why it is ready to become a recommendation.
> 
> Some of the developers reported that they had to talk between themselves
> in order to get their client and server interoperating. It is important
> we record what were those points and put this in the implementation
> report. Guillermo mentioned me that the spec is quite open in some
> parts. For example, it doesn't say if an X-KRSS  server requires 
> Proof of Possesion (PoP), if it's expecting KeyBindingAuthentication
> or NotBoundAuthentication. 
> 
> My worry here is how can a client know what features does a server
> support and how can the server tell the client why the request failed.
> The XKMS  result codes are quite generic. For example, what should a server
> report if the client didn't send PoP: Sender.Failure, Sender.Refused,
> Sender.NoAuthentication. We should be able to use an XKMS client with
> any XKMS server and there should be a way for the user to know why
> a request failed.
> 
> After talking with Guillermo, we thought that the best way is to have
> a list of all these features that are open and have the server announce
> which ones it is supporting. This can be interesting because then we
> probably don't need to add new result codes. We could put this list in
> the implementation report and recommend that servers publish this...
> 
> However, this sounds like WSDL. So why we don't give the list of open
> features and say that we recommend that servers announce them using WSDL
> and that clients consult them using whatever WSLD mechanisms are
> available? Moreover, if we can add a non-normative appendix to the spec
> giving those features in WSLD, I think we will be in a very good
> position.
> 
> If this idea sounds correct to you, could there be a volunteer to do
> this? I'm not WSDL-savvy myself. The developers are the only ones who
> can give us the list of open features following their implementation
> experience.
> 
> Comments?
> 
> -jose

Received on Monday, 21 February 2005 13:26:48 UTC