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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Minutes for March 29, 2005


Hi Everyone,

My apologies again for being so tardy with these minutes, but 
hopefully this will make up for it.

EM-Msg Meeting March 29, 2005 Minutes

Roll:
Voting Members:
Eleanor Robinson
Rob Torchon
Art Botterel
Paul Embley
Kon Wilms
Rex Brooks
Gary Ham
David Ellis
Walid Ramadan

Prospective members
Adam Hocek

Observers
Sylvia Webb
Carl Reed

Due to the recent abuse of our previous teleconference facility, we 
met on the interim line provided by Paul Embley.

There was no specific agenda following upon the previous TC meeting's 
disruption, and the uncertainty as to what our priority in this 
subcommittee ought to be at that point.

We briefly aknowledged Michael Daconta's recent message about slowing 
down the movement toward an EDXL Distribution component and Elysa's 
response noting that we were specifically asked to move the 
standards-writing process forward quickly.

Kon cited issues with EDXL in relation to element names for other 
than SOAP messages, specifically asking if we should consider options 
for requirements outside SOAP-specific messaging channels. It 
appeared that there was some general agreement that this was an idea 
worth pursuing.

Gary noted that DMIS has someone looking into that area.

Art pointed out that there are alternatives to SOAP such as RSS that 
certainly deserve our attention.

Dave asked if we should consider security considerations within the 
scope of this EDXL Distribution component.

Gary explained that we have been considering security a separate 
issue and effort that is being worked on by other groups at a lower 
level or at least a different level scopewise than we are working 
with EDXL.

Art said that we can't put a finger on "the" specific network in 
which EDXL will be deployed, and hence can't, and shouldn't try to 
include specific security processes for inclusion in the scope of 
EDXL Distribution.

Gary extended that to say that we could not even specify the "networks" per se.

So there was general consensus that security was not in scope.

We then explored, again with general consensus, the issue of 
developing a set of specific use-cases upon which to build our work, 
perhaps starting with requirements based on those use-cases.

Art pointed out that DMIS and EPAD were two clear choices and Dave 
discussed SWARM and ASOC in the sensor context as suitable choices as 
well.

Carl said he would, and in fact has, sent a message to the list with 
specific urls for the IETF-GEOPRIV work that is relevant to this 
topic and which address privacy and security issues with use cases, 
and so, can serve as examples from which we can learn how other 
groups approach developing requirements.

Gary noted that we (considering his work in DMIS as part of our work) 
didn't/couldn't take the time to build a query structure for an EDXL 
Interface in the trials held last fall/winter, so those trials can be 
used to identify a set of use cases, as well, that can serve to point 
us in the direction of what Interfaces are likely to be 
needed--providing some guidance as we proceed.

We identified 3 areas of use cases off the top:
	Broadcast
	Pub/Sub
	Directed Push/Pull

We had reasonable consensus that these use cases should provide for 
rules-based governance and role-based access, despite our agreement 
that security per se was not in scope.

In general terms we decided that we need to investigate how much 
human intervention was needed or should be allowed.

We decided to drastically cut down on the enumeration of send and 
recipient types, restricting those to top level categories and that 
we should treat event types in a similar manner.

We also reached  consensus that the Distribution component would be 
the smallest possible set of elements to reduce the chance of error 
and to keep computational performance overhead to a minimum.

My notes boiled down to four main bullet points taking for granted 
the previously agreed overall Message ID components:
	* TargetArea - not Required
	* Audience (RecipientType) - Required
	* ContentType (MimeType) - Required
	* Emergency EventType - Required

I am copying Gary's message with his summary of the consensus on 
cutting down the scope of the EDXL Distribution component:

________________________________________________________
At 1:17 PM -0500 3/29/05, Ham, Gary A wrote:

To all,

If I got our meeting straight today the stripped down version of the
Distribution element would include the following currently defined
elements:

For identification
1. messageID (1)
2. senderID (1)
3. dateTimeSent (1)

For Message content:
4. messageFormat (1 or more)

For Intended Recipient Identification
5. recipient Address (0 or more)

For message Categorization
6. messageStatus (1)
7. messageType (1)
8. eventType (1 or more)
9. icsType (1 or more) Note: ICS command type or interest is a new
element replacing all of the other categories in a fully NIMS complient
way.

For defining a geographic area of interest
10. targetArea  (0 or more) Note: structure to be based on an external
standard.
________________________________________________________

(Note: I included this in order to provide a better overall capture 
of the consensus. I posted a reply to Gary's message and hope we can 
continue the discussion on the email list.)

The meeting adjourned

Ciao,
Rex
-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]