[emergency] Re: [emergency-comment] FW: [CAP] Unique MessageIdentifiers in CAP

[Rex Brooks <rexb@starbourne.com>]

Hi Art,

You have a good point, too, but the discussion that I was planning to 
put on the agenda was to address how we want to deal with these 
issues, not directly dealing with them. One way to deal with them is 
as you suggest, but I think we should spend a little time on it just 
to hear a few more views, for which we also have this email list and 
the archive it produces.

In other words, the more of the discussion we can have here, the less 
we need to discuss in the meeting.

My own take on these is that they fall within the implementation 
guide/note, not as part of the spec. Or perhaps, these are candidates 
for the FAQ. I don't personally think that these are candidates for 
the the factsheet.

However, that said, I think we should encourage more thinking about 
it, especially as the main examples cited are NWS, which could very 
well benefit by hearing from us. And reviewing the archives, is a 
good place to start, in any event.

You are correct though, IMHO, that we do have more immediately 
important issues to wrestle with, including the ICS 201, to which 
some DHS developments pertain, such as being included in the National 
Incident Management System, NIMS. I would, in that connection, 
appreciate any news that can be forwarded or presented to us.

I am personally looking at developing a voice-controlled application 
of that form within a web services context, but it is definitely an 
overlap issue for WML/HTML, and might very well be combined with 
closed circuit video or Simultaneously Multimedia Integration 
Language, SMIL, apps. Of course, it's important to focus on what can 
be achieved in the short term, in terms of specification work we can 
add for the simplest technologies first, if our work is even needed 
in those areas, or what. It's the OR WHAT that concerns me, so I 
think we should at least start the discussion on IF SC next week as 
well.

I will try to get a tentative agenda out Friday, but more likely over 
the weekend or Monday.


Ciao,
Rex

At 10:28 PM -0800 3/2/04, Art Botterell wrote:
>Rex -
>
>Is this really in order for the TC at this time, while we have a 
>ballot pending?  Seems like it would be more appropriate to wait 
>until we see what feedback we get from the balloting process and 
>then work through all the issues that arise in a systematic fashion.
>
>If we start taking up every individual comment as it's offered I'm 
>afraid we're going to duplicate a lot of effort and get bogged down 
>when we should be moving ahead on other projects.
>
>(I'll also note that this and Mr. Wyman's other comments have been 
>the subject of quite a bit of discussion in the CAP Working Group 
>list.  If we're going to get into this right now, it might save some 
>time for TC members to review the discussion in the archive at 
><http://www.incident.com/pipermail/cap-list/>.  But I still think it 
>would be more proper to hold this in abeyance until the current 
>ballot is complete.)
>
>- Art
>
>
>At 10:34 PM -0800 3/2/04, Rex Brooks wrote:
>>Thanks, Bob,
>>
>>This raises an important issue that we should address. Since I have 
>>been asked to chair that meeting for Allen, the TC chair currently 
>>on vacation, due to the recent resignation of the designated 
>>co-chair, unless other arrangements have been made today while I 
>>was hunkered down in day two of four of the WSRP f2f meetings this 
>>week, I will put this on the agenda, along with the 
>>severity/urgency and the ALL CAPS examples issues, as well.
>>
>>Thanks again,
>>Rex
>>
>>
>>At 10:18 PM -0500 3/2/04, Bob Wyman wrote:
>>>     The CAP specificiation, while saying that message identifiers are
>>>supposed to be unique, doesn't say anything explicit about the scope
>>>of the uniqueness. Normally, specifications for Internet protocols
>>>make this explicit to avoid confusion and diverging implementations.
>>>Is it expected that a message identifier is globally unique? (i.e. no
>>>two senders should ever generate the same message identifier.) Or, are
>>>these identifiers only unique for each sender? If only unique for each
>>>sender, then should we assume that that *actual* identifier is
>>>constructed by concatenating the message identifier with the sender
>>>identifier?
>>>
>>>     In any system that relies on unique identifiers, it is important
>>>to identify the time period during which uniqueness is guaranteed.
>>>However, the CAP spec doesn't do this. Are senders allowed to reuse
>>>identifiers? If so, under what circumstances? Is there, for instance,
>>>an implied period of time during which the uniqueness of identifiers
>>>should be maintained? (Note: NWS seems to reuse the same message
>>>identifiers whenever they generate info for a particular area. Thus,
>>>the message identifier "wwa_California" is reused in *every* CAP
>>>message that they write concerning California. Is this what the
>>>designers of CAP intended? (Note: I realize that NWS is still using
>>>0.9a1, however, the general issue still exists.) Can/Should message
>>>identifiers be reused? I would suggest that this should be strongly
>>>discouraged. If message identifiers are constantly reused in the
>>>manner that NWS does, then they aren't really "message identifiers" --
>>>rather, they are serving the purpose of "subject," "topic," or
>>>"series" codes.
>>>     If it is important to be able to identify a sequence of unique
>>>messages that all address the same subject then support for that
>>>should be provided for in the specification rather than having people
>>>overload a field which should be message-specific.
>>>
>>>     Because CAP message ids are assigned by senders, there are a
>>>number of opportunities for severe confusion. For instance, it appears
>>>to be difficult to take CAP feeds from both the NWS and California
>>>EDIS without getting very confused about what is really happening. The
>>>difficulty is caused by the fact that California repackages NWS
>>>weather alerts as CAP messages which have different message
>>>identifiers than the NWS CAP feed uses. Ideally, it would be possible
>>>for the EDIS messages to at least identify the NWS messages that were
>>>their source so that software could filter out duplicates. (Note: The
>>>current "source" field is inadequate for these purposes.) The current
>>>situation would force anyone who was reading both EDIS and NWS CAP
>>>feeds to simply ignore all data that came from EDIS since it is
>>>probably a duplicate of NWS data. This means that if California ever
>>>issued its own "MET" alerts, not simply copies of NWS data, readers
>>>would probably ignore them. This is not good.
>>>
>>>         bob wyman
>>>
>>>
>>>To unsubscribe from this list, send a post to 
>>>emergency-comment-unsubscribe@lists.oasis-open.org, or visit 
>>>http://www.oasis-open.org/mlmanage/.
>>
>>
>>--
>>Rex Brooks
>>GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>>W3Address: http://www.starbourne.com
>>Email: rexb@starbourne.com
>>Tel: 510-849-2309
>>Fax: By Request
>>
>>To unsubscribe from this list, send a post to 
>>emergency-comment-unsubscribe@lists.oasis-open.org, or visit 
>>http://www.oasis-open.org/mlmanage/.
>
>
>To unsubscribe from this mailing list (and be removed from the 
>roster of the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request