Comments - IEEE 1512

["Sukumar Dwarkanath" <sdwarkanath@comcare.org>]

I would like to bring this note to the TC's attention. This message was
mentioned in today's messaging meeting, and I think we need to respond
to this some fashion. 

Thanks

Sukumar


-----Original Message-----
From: edxl-admin@incident.com [mailto:edxl-admin@incident.com] On Behalf
Of David Kelley
Sent: Saturday, September 18, 2004 5:40 PM
To: Art Botterell; edxl@incident.com
Cc: Kalhammer, Valerie; Joel Markowitz; Ann R. Lorscheider
Subject: Re: [EDXL] Next Steps Telecon 9/23, 1PM Eastern

Art I have a number of thoughts which I post here to the list as I will
be unable to make the call.

Regarding the FEMA stakeholder requirements work.
Art posted a note from a recent FEMA stakeholder meeting outlining
requirement for information sharing.  I feel compelled to point out that
the vast majority of these (as well as several others) are already well
covered in the work of the IEEE 1512 Incident Management Message set and
I would advise anyone contemplating repeating developing such work to
look there first.  Also, 1512 fully covers NIMS and ICS reporting and
asset management issues.


Specific comments on the EDXL draft

Comments on seven specific elements follow

1) The part of the header I have the most heartburn with is the proposed
<message Reference> which is suggested to be made up of "The messageID
and senderID of the previous message" in the draft.  This is not really
workable if you expect subscribes to the message to come and go and not
track every message issues.  Which is likely to be the case as the
receiving centers interests in message traffic vary.  It would be
better, in my option, and I would propose, to adopt some form of message
count increment value (1,2,3, etc) so that someone receiving a message
could determine how many prior messages were sent and how many it may
have "missed" in the interim (for whatever reason).  For example, in
most of the ITS message work headers a message "verb"  (new, update,
etc) is combined with a count value.  A more complex structure called a
"pedigree" has been used in the Incident Management message set to deal
with the practical reality that different (semi-coordinated) centers are
each issuing sequences of messages about a common event (each encoded in
different way depending on the centers perspective) and that these needs
to be tied together in some fashion.  This may beyond what the scope of
EXDL does, but a deterministic numbering system is not.

2) The event types found in Table Three represent a fairly decent first
start (and this is the hardest part of the whole problem to gain
consensus
on) but needs more work to a wider audience to get basic agreement on
the major category types.  This is vital to achieve a common agreement
or it will not be possible to filter messages are inherently local in
scope and application.  On a more minor note, the solution needs to
allow the creation of useful local codes for the minor types as well.

In event type further...  Speaking for the Transportation ITS industry,
we have a well-established and mature encoding system for event
classification that is already widely in use and has been around in
various forms for nearly 20 years.  These so called "ITIS" codes come
from a transportation background and hence express a transportation view
of things that needs to be widened.  They already have many "post 9/11"
type items due to their use in Europe in the 80's when terrorist
activities were at that time more common.  If you are not familiar with
this encoding system, a summary of the contents and categories can be
found at
<http://serv4.itsware.net/bb/viewtopic.php?t=238>http://serv4.itsware.ne
t/bb/viewtopic.php?t=238
You can also download the XML schema for the complete set. Whatever we
come up with in EXDL will need to allow cross coding with the ITIS
classification system for compatibility with new and existing ITS
deployments.  At the present I do not see that to be overly burdensome
to achieve.  Of the codes Art has proposed, the vast majority (all but
one or
two) are already in ITIS.  [In another effort we are trying to
coordinate between ITIS, NCIC and NIBRS but law enforcement event codes
of this type inevitably involve what statutes were broken and national
agreement on this is not likely.]

3) The recipient type and sender type to be filed out from values found
in Table Four represents an interesting collection but I am not sure
that this is what we need to do.  First, it might bear rethinking the
underlying concept of operations that the header is "directed" to
specific types.  In actual operations most centers would resist the
notion that they should seek out and send informational message to every
possible interested party.  More to their liking would be allowing
certain types of centers to access to a common exchange point and
(presuming they had proper
credentials) be able to request messages fitting certain classes of
events and information.  Thus, this section of the header might be
better structured as a sequence of <recipientTypes> (types as in
categories) to 
which the message is thought to apply or allowed to go to.   I see that 
more than one instance of this element is allowed, but it is not clear
to me if the sequence needs to be bound to some of the other elements in
a more complex structure (type bound with address?). The concept of a
type of center (rather than a specific one) is already implied by some
of the entries in the list (Geophysical, Recreation?).  The values found
in the list need expanding as well.  Add Allied Towing ad Recovery
services, Hazmat Clean up (private or public), Incident Command Post,
others could be suggested but until the class semantics are better
understood the right contents are unclear.

4) The element <reposnseType> seem to me the type of information that is
not needed in the header as it is not needed for routing or for
determining the overall interest in a message.  It is certainly better
handled inside the message body where other messages such as the
tactical forms of 1512 
handle it.   Perhaps more to the point, what the type of response is and

how it is described varies by agency and by area of expertise.  The list
provided (Table five) does not handle this well, mixing the type of
response personnel involved (a resource in ICS terms) with the overall
activity (a tactical objective in ICS terms), and a handful of ICS
terms.  I suggest we drop this element.

5) The element <icsBranch> should allow the enumeration "not applicable"
as not all receivers of this message would be involved in an ICS
structure or do all events of interest involve the use of ICS/NIMS.

6) The element <confidentially> is not well enumerated and I suggest you
seek for a suitable enumeration of values from the Justice XML model
work so that law enforcement finds the values to be useful.

7) The element <targetArea> is has become much improved as effort has
gone into this but there are still some basic types of geographical
reference that need to be supported.  I would not want the EDXL header
to fall into the quagmire that "Location Referencing" (LRMS) has caused
for the ITS industry.  But I do think some rudimentary "cross street"
style location profile (i.e. event on Route 123 between Exits A and B)
is required.



I am sorry to say I cannot make the next meeting due to another
commitment (coordination in Canada) but if conditions allow I will try
to call in.  I understand that several other persons active in the
Transportation ITS standard will be present and it is likely they can
answer any questions that the above raises.

DC Kelley



At 02:05 AM 9/17/2004, Art Botterell wrote:
>Friends -
>
>Our schedules are all busy right now, but I'd like to propose a 
>conference call for next Thursday the 23rd at 1:00 PM Eastern / 10:00 
>AM Pacific time to update our progress so far and to discuss priorities

>for our next efforts.  I realize that this time won't fit everyone's 
>schedule... there are 108 of us now... but I'm hoping it at least 
>doesn't conflict with anything that would keep a large number of us
from participating.
>
>For our agenda I'd propose two topics:
>
>     1)  A brief review of implementations and trials using the EDXL 
> "wrapper" message format.
>
>     2) A discussion of next priorities for evolving the EDXL 
> data-sharing framework.
>
>As stimulus for that second conversation, I'm attaching an excerpt from

>the summary of a stakeholders' meeting conducted earlier this year by 
>the FEMA Disaster Management program at FEMA.  We may also want to 
>consider the ICS forms illustrated in Appendix A, Tab 9 of the NIMS 
>program document 
>(<http://www.dhs.gov/interweb/assetlibrary/NIMS-90-web.pdf>).  And of 
>course any other suggestions that members of our working group may want

>to bring forward.
>
>Call details will be circulated early next week.  I believe we can keep

>this call to an hour, 90 minutes at the outside.  I hope we'll all 
>manage to be represented on the phone next Thursday.
>
>Thanks!
>
>- Art

[demime 1.01a removed an attachment of type application/msword which had
a name of EDXL_comments.doc"; x-mac-type="42494E41";
x-mac-creator="4D535744] _______________________________________________
EDXL mailing list
EDXL@incident.com
http://lists.incident.com/mailman/listinfo/edxl
BEGIN:VCARD
VERSION:2.1
N:Aylward;David
FN:David Aylward
ORG:ComCARE Alliance, The
TITLE:Director
TEL;WORK;VOICE:202-429-0574
TEL;CELL;VOICE:202-255-3215
TEL;WORK;FAX:202-296-2962
ADR;WORK:;;1701 K Street, N.W., Suite 400;Washington;DC;20006;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1701 K Street, N.W., Suite 400=0D=0AWashington, DC 20006=0D=0AUnited States =
of America
URL;WORK:http://www.comcare.org
EMAIL;PREF;INTERNET:daylward@comcare.org
REV:20041201T020801Z
END:VCARD