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

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