RE: [emergency] Interoperability of CAP 1.0 and 1.1 Systems

[Art Botterell <acb@incident.com>]

Bob -

In CAP 1.1 my understanding was that we'd abandoned the opaque string 
model in favor of a specified, comma-delimited construct.  In which 
case, when referring to a CAP 1.0 message in a CAP 1.1 messages, it 
would seem like we still need to formulate a CAP 1.1 compliant value 
including a timeDate component.

That would be relatively easy if we have access to the original 
message itself... but if all we have is a reference to it in another 
CAP 1.0 message, what would you suggest we do to achieve consistency?

- Art

At 1:02 PM -0500 3/18/05, Bob Wyman wrote:
>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
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: emergency-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: emergency-help@lists.oasis-open.org