compliancy section / profiles, we need your feedback

Hi folks,

This message is intended for developers who participated in the
interop.

Following a suggestion made by To: Herv? <herve.bodiguel@mustradem.com>
Cc:
From: Jose Kahan <jose.kahan@w3.org>
From: Jose Kahan <jose.kahan@w3.org>
y:Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  ?:Help
    From: Jose Kahan <jose.kahan@w3.org>
      To: Herv? <herve.bodiguel@mustradem.com>
From: Jose Kahan <jose.kahan@w3.org>
To: www-xkms@w3.org
Cc:
Bcc:
Subject: compliancy section / profiles, we need your feedback
Reply-To: jose.kahan@w3.org

Hi folks,

This message is intended for developers who participated in the
interop.

Following a suggestion made by To: Herv? <herve.bodiguel@mustradem.com>
Cc:
From: Jose Kahan <jose.kahan@w3.org>
From: Jose Kahan <jose.kahan@w3.org>
y:Send  q:Abort  t:To  c:CC  s:Subj  a:Attach file  d:Descrip  ?:Help
    From: Jose Kahan <jose.kahan@w3.org>
      To: Herv? <herve.bodiguel@mustradem.com>
From: Jose Kahan <jose.kahan@w3.org>
To: www-xkms@w3.org
Cc:
Bcc:
Subject: compliancy section / profiles, we need your feedback
Reply-To: jose.kahan@w3.org

Hi folks,

This message is intended for developers who participated in the
interop.

I had an AI from the last teleconference to come up with some
ideas for making a better compliancy section.  Following a 
suggestion made by Vamsi Motukuru, what I'd like to have is
a non-normative appendix to the spec that gives different
implementation profiles (or scenarios) that will detail 
assumptions or different protocol interpretations that people
had to take during interop and that required extra communication 
between client and server developers in order to get their
implementations working in an interoperable way. Other developers
will be able to look at this appendix and save time afterwards when
they plan to support a given set of features.

I liked Vamsi's suggestion that we should concentrate only on server
side configuration. Following a server configuration, one should
always be able to build a corresponding client.

Do you think that we should also define "profiles" in this appendix for
things like X-KISS locate service, X-KISS validate service, ... X-KRSS
services, combination of them? For me it makes sense if there
are choices that are more interesting. For example, when 
implementing an X-KRSS service, should one implement all the X-KRSS
operations, support the two-phase protocol, asynchronous mode, ... 
What can be the most essential things to implement a partial XKMS
client or server that will still allow to have an interoperable
and conformant application?

Please send your feedback and comments so that we can have real
"profiles".

I'd also like to ask developers to go thru the conformance section (Section 9)
of the XKMS part-1 spec to see if there are some features that would need 
to change their requirement level, after your interop experience,  
or if they are correct. 

If you have other suggestions about how to word this non-normative
appendix or its context, please feel free to discuss them on the list.
It's must easier to do so from the developer's point of view.

Thanks in advance!

-jose