[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Interoperability of CAP 1.0 and 1.1 Systems
Art Botterell wrote: >"'references' values that refer to messages in the CAP 1.0 format MUST > use a value of '2000-01-01T00:00:00' for the 'sent' time, regardless > of the actual 'sent' time of the CAP 1.0 message." It is always a good thing to worry about backwards compatibility, however, I think that in the case of CAP V1.0/V1.1 references it isn't actually necessary to do anything. The reasons are: 1. CAP V1.0 systems should be treating reference ids as opaque strings. As long as they are doing so, they will not be impacted by *any* syntax change defined by CAP V1.1. Thus, changing the syntax in CAP V1.1 has no impact on the ability of CAP V1.1 systems to generate references that are useful to CAP V1.0 systems. Properly implemented CAP V1.0 systems will treat CAP V1.1 reference ids as opaque strings and continue to work flawlessly. (Note: CAP V1.0 references are, by implication, opaque strings since the separator character defined in CAP V1.0 "/" is a permitted character in the "sender" element. Thus, while the "/" character is used as a separator, it *cannot* be recognized as such by a reader. The result is an opaque string whose structure and components cannot be determined within the bounds of the CAP V1.0 specification. If the separator in CAP V1.0 had been defined as the string "/ ", as many people thought, then CAP V1.0 reference ids would, in fact, have been strings that could have been parsed into their components. This is because the space character is not permitted in either the CAP V1.0 sender or identifier elements. Thus, the string "/ " would have defined a unique and recognizable separator. However, it has been said many times that the intent of the CAP V1.0 authors was that the separator should be "/" only and it is too late to revisit this at this point. Additionally, it should be noted that if the CAP V1.0 separator was, in fact, the string "/ ", then the parsing rules for reference ids would have been more complex due to the fact that whitespace, which includes the space character, is an inter-reference-id separator in CAP V1.0.) 2. It is reported that at least some CAP V1.0 implementations do, in fact, treat references as something other than opaque strings. For these systems to work consistently, they must be relying on knowledge about the syntax of "sender" elements that are generated by the specific systems that they are sending to or receiving from. (Specifically, they must "know" that the systems they are receiving from do not use "/" in their sender elements.) Additionally, such CAP V1.0 implementations must be within closed networks since they would have no hope of being able to handle the general CAP V1.0 compliant references that would be received in an open network. Given that these systems must be in closed networks that rely on non-CAP specifications to ensure their interoperation, we can assume that the private network-specific standards setting processes in these closed networks will continue to ensure whatever level of interoperation that they currently enjoy. It is not reasonable to expect the CAP Working Group to modify its standards to address these informal non-compliant uses of CAP. 3. CAP V1.1 systems should be treating reference ids as opaque strings. This rule ensures backwards compatibility with CAP V1.0 and is a reasonable constraint for a dot or minor release. The rule should be revisited with CAP V2.0. This must be the case since one of the CAP V1.1 separator characters "," is permitted as a component of the CAP V1.0 sender field. Thus, a CAP V1.1 system can't tell the difference between a valid V1.1 reference id and a very strange CAP V1.0 reference-id. 4. It is too late to redefine CAP V1.0. Constraints cannot be placed on CAP V1.0 systems other then those that are defined in CAP V1.0 itself. 5. The specific suggestion made in the mail below, that CAP 1.0 systems insert a time of '2000-01-01T00:00:00' when constructing reference ids, violates the intent of the CAP V1.1 reference id design. The intent is that the "time" component of the identifier be a time during which the sender had exclusive administrative control over the string used in the "sender" element. This requirement is necessary to ensure that CAP V1.1 reference ids are unique in both space and time. Thus, no message writer should ever be compelled to use a timestamp during which they were not clearly the sole administrators of the relevant strings. For the reasons given above, I do not believe we should accept Art's suggestion. bob wyman -----Original Message----- From: Art Botterell [mailto:acb@incident.com] Sent: Thursday, March 10, 2005 7:34 PM To: emergency@lists.oasis-open.org Subject: Re: [emergency] Interoperability of CAP 1.0 and 1.1 Systems Seems like the transformation is direct except for the timeDate part. Would it simplify things if we specified a backward-compatibility convention for that? For example: "'references' values that refer to messages in the CAP 1.0 format MUST use a value of '2000-01-01T00:00:00' for the 'sent' time, regardless of the actual 'sent' time of the CAP 1.0 message." That way new references could be derived directly from the old with no additional ambiguity, even if it isn't feasible to refer back to the original message body. - Art --------------------------------------------------------------------- To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org For additional commands, e-mail: emergency-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]