Re: [Ecrit] WGLC - draft-ietf-ecrit-data-only-ea-01

[Hannes Tschofenig <[e-mail]>]

Hi Brian, 

On Jul 12, 2011, at 4:43 PM, Brian Rosen wrote:

> What if we DID allow a CAP block in Additional Data, and then made Data Only a MESSAGE with a Call Info/Additional Data?  

Let's look at the fields and see what we actually need. Below is the list of elements from the CAP specification. 

As you said in your earlier mail we cover the case where no session is established. 


"alert" Element and Sub-elements
----------------------------------------------

* <identifier>: The identifier of the alert message

[hannes] Having an identifier for the message would be useful but don't we have it already within SIP?

* <sender>: The identifier of the sender of the alert message

[hannes] This is also available via SIP unless we want to differentiate the entity that sends the SIP message vs. the entity that created the additional data. 

* <sent>: The time and date of the origination of the alert message

[hannes] This is also information available in SIP. 

* <status>: The code denoting the appropriate handling of the alert message
Code Values:
“Actual” - Actionable by all targeted recipients
“Exercise”- Actionable only by designated exercise participants; exercise identifier should appear in <note>
“System” - For messages that support alert network internal functions.
“Test” - Technical testing only, all recipients disregard
“Draft” – A preliminary template or draft, not actionable in its current form.

[hannes] We have a mechanism for testing emergency calls and alerts already. The others do not make sense in our context. 

* <msgType>: The code denoting the nature of the alert message
Code Values:
“Alert” - Initial information requiring attention by targeted recipients
“Update” - Updates and supercedes the earlier message(s) identified in <references>
“Cancel” - Cancels the earlier message(s) identified in <references>
“Ack” - Acknowledges receipt and acceptance of the message(s)) identified in <references>
“Error” indicates rejection of the message(s) identified in <references>; explanation SHOULD appear in <note>

[hannes] I am not sure whether we need a protocol mechanism since the alert msg itself. If a device sends data about an emergency then they can always send further alert messages with more info. 
But maybe this is useful where a human is somewhere in the loop. 

* <source>: The text identifying the source of the alert message
The particular source of this alert; e.g., an operator or a specific device.

[hannes] We have much more data as part of our additional data spec. 


* <scope>: The code denoting the intended distribution of the alert message
Code Values:
“Public” - For general dissemination to unrestricted audiences
“Restricted” - For dissemination only to users with a known operational requirement (see <restriction>, below)
“Private” - For dissemination only to specified addresses (see <address>, below)

[hannes] We have better ways in PIDF-LO to restrict the information via the rules. 

* <restriction>: The text describing the rule for limiting distribution of the restricted alert message

[hannes] We have better ways in PIDF-LO to restrict the information via the rules. 

* <addresses>: The group listing of intended recipients of the private alert message

[hannes] The SIP message already indicates the recipient. 

* <code>: The code denoting the special handling of the alert message

[hannes] not further defined and hence underspecified. 

* <note>: The text describing the purpose or significance of the alert message

[hannes] Any clear text field will be less useful for our purpose; who should type the text? 

* <references>: The group listing identifying earlier message(s) referenced by the alert message

[hannes] This is useful in context of the <msgType>

* <incidents>: The group listing naming the referent incident(s) of the alert message

[hannes] An incident identifier is useful although quite difficult to set for the end device.

"info" Element and Sub-elements
---------------------------------------------

* <language>: The code denoting the language of the info sub- element of the alert message

[hannes] This information refers to the text in the alert. Since we would not use clear text it would be less useful. 
A language tag for the user itself is useful but already in SIP. 

* <category>: The code denoting the category of the subject event of the alert message

(1) Code Values:
“Geo” - Geophysical (inc. landslide)
“Met” - Meteorological (inc. flood)
“Safety” - General emergency and public safety
“Security” - Law enforcement, military, homeland and local/private security
“Rescue” - Rescue and recovery
“Fire” - Fire suppression and rescue
“Health” - Medical and public health
“Env” - Pollution and other environmental
“Transport” - Public and private transportation
“Infra” - Utility, telecommunication, other non-transport infrastructure
“CBRNE” – Chemical, Biological, Radiological, Nuclear or High-Yield Explosive threat or attack
“Other” - Other events

[hannes] This may be useful to provide additional information about the alert message, for example in a sensor context.  

* <event>: The text denoting the type of the subject event of the alert message

[hannes] Clear text field again. 

* <responseType>: The code denoting the type of action recommended for the target audience.
(1) Code Values:
“Shelter” – Take shelter in place or per <instruction>
“Evacuate” – Relocate as instructed in the <instruction>
“Prepare” – Make preparations per the <instruction>
“Execute” – Execute a pre-planned activity identified in <instruction>
“Monitor” – Attend to information sources as described in <instruction>
“Assess” – Evaluate the information in this message. (This value SHOULD NOT be used in public warning applications.)
“None” – No action recommended

[hannes] We don't need this field since the end device should not tell the PSAP what to do.

* <urgency>: The code denoting the urgency of the subject event of the alert message
(1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Immediate” - Responsive action SHOULD be taken immediately
“Expected” - Responsive action SHOULD be taken soon (within next hour)
“Future” - Responsive action SHOULD be taken in the near future
“Past” - Responsive action is no longer required
“Unknown” - Urgency not known

[hannes] I cannot come up with useful cases for our deployment context. 

* <severity>: The code denoting the severity of the subject event of the alert message
1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Extreme” - Extraordinary threat to life or property
“Severe” - Significant threat to life or property
“Moderate” - Possible threat to life or property
“Minor” - Minimal threat to life or property “Unknown” - Severity unknown

[hannes] Sounds nice but how are these values set automatically. 

* <certainty>: The code denoting the certainty of the subject event of the alert message
(1) The “urgency”, “severity”, and “certainty” elements collectively distinguish less emphatic from more emphatic messages.
(2) Code Values:
“Observed” – Determined to have occurred or to be ongoing.
“Likely” - Likely (p > ~50%)
“Possible” - Possible but not likely (p <= ~50%)
“Unlikely” - Not expected to occur (p ~ 0)
“Unknown” - Certainty unknown

[hannes] Same as above. 

* <audience>: The text describing the intended audience of the alert message

[hannes] Clear text. 

* <eventCode>: A system- specific code identifying the event type of the alert message

[hannes] underspecified. 

* <effective>: The effective time of the information of the alert message

* <onset>: The expected time of the beginning of the subject event of the alert message

* <expires>: The expiry time of the information of the alert message

[hannes] While these fields may be useful for early warning scenarios they are less obvious for 

* <senderName>: The text naming the originator of the alert message

[hannes] Clear text; we have information about the originator already in other places. 

* <headline>: The text headline of the alert message

[hannes] Not useful 

* <description>: The text describing the subject event of the alert message

[hannes] clear text again.

* <instruction>: The text describing the recommended action to be taken by recipients of the alert message

[hannes] Not useful for the UA-to-PSAP communication. 

* <web>: The identifier of the hyperlink associating additional information with the alert message

[hannes] also in the additional data 

* <contact>: The text describing the contact for follow-up and confirmation of the alert message

[hannes] information in the additional data. 

* <parameter>: A system- specific additional parameter associated with the alert message

[hannes] underspecified.
A small note: Those who want to provide some sensor specific information are better advised to make use of a document like "Media Type for Sensor Markup Language (SENML)" <draft-jennings-senml-06.txt>. The abstract of the document says: 

   This specification defines media types for representing simple sensor
   measurements in JSON.  A simple sensor, such as a temperature sensor,
   could use this media type in protocols such as HTTP to transport the
   values of a sensor.
 
 

"resource" Element and Sub-elements
----------------------------------------------------

[hannes] These fields are useful since we want to attach additional data to the data-only call but we do not need to stuff this into the CAP message. We could instead, as the additional data draft suggests, concatenate MIME types in a SIP msg. 

* <resourceDesc>: The text describing the type and content of the resource file. The human-readable text describing the content and kind, such as “map” or “photo,” of the resource file.

* <mimeType>: The identifier of the MIME content type and sub-type describing the resource file

* <size>: The integer indicating the size of the resource file

* <uri>: The identifier of the hyperlink for the resource file

* <derefUri>: The base-64 encoded data content of the resource file

* <digest>: The code representing the digital digest (“hash”) computed from the resource file



 "area" Element and Sub-elements
-----------------------------------------------

[hannes] We have already noticed earlier that the area elements do not meet our needs. We have a better mechanism with the PIDF-LO. 

* <areaDesc>: The text describing the affected area of the alert message

+ various location shapes: geocode, circle, polygon, altitude, ceiling 




Ciao
Hannes