OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[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]