8271 2009-11-13 00:22:40 +0000 Eventing: misuse of RFC2119 terms 2010-03-17 11:10:28 +0000 1 1 1 Unclassified WS-Resource Access Eventing FPWD All All CLOSED REMIND hasProposal P2 normal --- 1 gilbert.pilz gilbert.pilz dug public-ws-resource-access-notifications oldest_to_newest 29535 0 gilbert.pilz 2009-11-13 00:22:40 +0000 The RFC 2119 terms "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are meant to apply to specific requirements and behaviors within the context of a specification. They are *not* meant to refer to general concepts and actions. For example, a (repeated) incorrect use of the RFC 2119 keyword "MAY" is as follows: "Different security mechanisms MAY be desired depending on the frequency of messages. For example, for infrequent messages, public key technologies MAY be adequate for integrity and confidentiality. However, for high-frequency events, it MAY be more performant to establish a security context for the events using the mechanisms described in WS-Trust [WS-Trust] and WS-SecureConversation [WS-SecureConversation]." None of the above uses of MAY has anything to do with the particulars of WS-Eventing specification. A correct use of the RFC 2119 keyword "MAY" is as follows: "The value of the wse:Expires element as well as those of its @min and @max attributes MAY be either a duration (xs:duration) or a specific time (xs:dateTime)." This tells you something very specific about the value-space of the wse:Expires element and it's @min and @max attributes. Since the RFC 2119 keywords have a direct impact upon implementations, the misuse of these keywords makes the spec more difficult to read and correctly implement. WS-Eventing contains a number of cases where RFC 2119 keywords are misused. A complete list with some suggested changes will be sent to the mailing list and linked in the comments below. 31383 1 bob 2010-02-01 14:30:47 +0000 proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2010Jan/0194.html 31680 2 bob 2010-02-09 20:54:17 +0000 Resolved as proposed in comment #1