RE: Requirements Comments

Hi Yassir,

Ideally, I would say that any normative statement in the requirements doc is
normative with respect to what should appear in the XKMS and Bulk Operations
documents. The normative statements in the XKMS and Bulk Operations docs
would apply to clients and servers implementing/conforming to those specs.
However, from past meetings and teleconferences where the line between
requirements and what should go in the XKMS spec was a little blurry. Thus,
I think we ended up with normative statements for clients/servers in the
requirements doc as well.  I think that's probably ok though. 

I agree with your comment that the SHOULD indicated below must be a MUST.
I'll have to look at the requirements doc to see the other examples you are
referring to (there may be some that will remain as SHOULDs I suppose).

Mike

-----Original Message-----
From: Yassir Elley [mailto:yassir.elley@sun.com]
Sent: Thursday, February 14, 2002 2:45 PM
To: www-xkms@w3.org
Subject: Requirements Comments


I understand what "SHOULD" means in the context of applications that claim
conformance to XKMS in that we are recommending a certain behavior,
but what does SHOULD mean when applied to the specification itself? Does
this mean
that those items aren't really requirements on the spec but they would be
nice to have?

For example, 2.1.8 states
"The specification SHOULD clearly define the set of responses ..."
It seems strange to include this as a requirement and then say that it
it is only a SHOULD. (In other words, it is not really a requirement)

This use of SHOULD and SHOULD NOT as applied to the spec occurs in several
other
places as well. I would suggest they be replaced by MUST and MUST NOT.

Some minor typos:
2.1.7
Replace "client," with "clients"
"Usability and simplicity are paramount to enable client, to obtain ..."

2.2.3
The second sentence is a fragment
"In particular, the specification MUST define how the use of transport layer
security such
as SSL/TLS."

2.5.4
Replace "PX509" with "X509"
"...if the service claims interoperability with PX509."

-Yassir.

Received on Thursday, 14 February 2002 17:31:49 UTC