Subject: Re: [Ecrit] Whither data-only

From: Randall Gellens <[email-masked]>
Date: Mon, 11 Feb 2013 14:37:32 -0800

Excuse my top-posting.

The suggested new name, "Citizen to Authority Alerts," gets to the 
heart of the issue, I think: is this functionality for autonomous 
devices sending alerts to an aggregator or a PSAP, or is this a 
"conventional" emergency call on behalf of a person?

The use cases that were described for all sorts of autonomous systems 
seemed both compelling and numerous (e.g., building fire alarms, 
building burglar alarms, flood alerts, earthquake sensors, chemical 
leak sensors, etc.)

If those use cases still exist and still need to be solved, then I 
suggest advancing the document as originally conceived, focused on 
autonomous alerts.  When the concept of updates was first introduced, 
it was described as a rare edge case.  If that is still true, then 
publish a simple document that simply handles one-shot data-only 
alerts, and add subscribe/notify as an extension later.

In contrast, an emergency call where there is a human involved, even 
if the call is initiated by a device and not the person, should be 
handled as a normal emergency call with a media path.  Even if the 
person is unconscious, a voice path is desirable for many reasons 
(including allowing the PSAP call taker to hear background noise).

At 1:11 PM -0500 1/29/13, Brian Rosen wrote:

>  We ran a WGLC on data-only, and got some comments.  The discussion 
> raises some fundamental issues that authors have been discussing. 
> Here is our current thinking, which we would like discussion on 
> before we rev the draft.
>
>  "Data Only" was intended, originally, for a sensor equipped 
> automaton to send an alarm to a PSAP when there was no media.  It 
> uses a CAP message in the body of a MESSAGE to do that.
>
>  It's been observed that there are cases where you have exactly the 
> same kind of thing, with the same data, but you ALSO have media. 
> In such a case, we would like to have the data sent the same way 
> (CAP message in a body)
>
>  It's also been asked how updates to the alarm are sent.  At one 
> point there was some discussion of using MSRP to send a series of 
> messages.  Authors don't like this mechanism because it doesn't 
> allow the PSAP to control the rate of updates.  We suggest that 
> updates be handled with a SUB/NOT, with filtering, and the CAP 
> message in the body of the NOTIFY.
>
>  If we were to do this, it would be major surgery to the existing 
> draft, including a name change.  Nevertheless, that seems to be the 
> right way to go.  We would:
>  a)Define the mechanism to carry a CAP message in the body of a SIP 
> transaction, and define it for use in INVITE, MESSAGE and NOTIFY
>  b) Specify that INVITE is appropriate for alarms with media 
> (creates session), and MESSAGE for alarms without media (doesn't 
> create a session), but otherwise are equivalent.
>  c) Define a SUB/NOT package, with filtering, for updates to the alarm data
>  d) Change the name to something like "Citizen to Authority Alerts".
>
>  This would mean re-running WGLC.
>
>  Comments?
>
>  Brian
>
>  _______________________________________________
>  Ecrit mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ecrit

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
I suppose when it gets to that point, we shan't know how it does it.
    --Alan Turing

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 11 Feb 2013 18:00:51 -0500

Thanks for the comments.  See inline
On Feb 11, 2013, at 5:37 PM, Randall Gellens <[email-masked]> wrote:

> Excuse my top-posting.
> 
> The suggested new name, "Citizen to Authority Alerts," gets to the heart of the issue, I think: is this functionality for autonomous devices sending alerts to an aggregator or a PSAP, or is this a "conventional" emergency call on behalf of a person?
Well, the issue here is that we want to have a document that describes the data structure that could be sent with a call (that is, with media), or without a call ("data only").  Citizen to Authority Alerts does get to the heart of the matter, but it might be confusing when sent with a call.

So, if you have a total automaton, say an alarm system in a building, you would send the data without any media.  If you had, say, an elevator distress alarm, that could have media.  The data structure would look the same, and would be carried the same way.   One would be carried with MESSAGE, the other with INVITE.

> 
> The use cases that were described for all sorts of autonomous systems seemed both compelling and numerous (e.g., building fire alarms, building burglar alarms, flood alerts, earthquake sensors, chemical leak sensors, etc.)
Yes, there are a lot of them.  

> 
> If those use cases still exist and still need to be solved, then I suggest advancing the document as originally conceived, focused on autonomous alerts.  When the concept of updates was first introduced, it was described as a rare edge case.  If that is still true, then publish a simple document that simply handles one-shot data-only alerts, and add subscribe/notify as an extension later.
Well, but….

In your list of examples, which is good, updates could happen for nearly any of them.  It's not a corner case. 

I don't really mind having two or three documents, but it seems, at the moment, to be silly to do that when we know what we're trying to accomplish.

> 
> In contrast, an emergency call where there is a human involved, even if the call is initiated by a device and not the person, should be handled as a normal emergency call with a media path.  Even if the person is unconscious, a voice path is desirable for many reasons (including allowing the PSAP call taker to hear background noise).
Yes, of course.  We agree.  But how do you handle the sensor data, with the updates, that might come (elevator) or would never come (general building alarm)?

Let me take another crack at this:

There are various automatons that create data that might be useful to send to a PSAP.  Some of these ALSO may have a media path.  Many of these can provide updates to the sensor data.

With and without media is, of course, an important difference, but the DATA part, we think, ought to look the same - same data definition/XML/CAP Wrapper/...

Updates to the data is a frequently occurring thing, but the PSAP has to be in control.  So just repeating  the initial alert is NOT the right thing to do.

We could:
a) Write a document that describes the data for an alert
b) Write a document that describes carrying the data in an INVITE
c) Write a document that describes carrying the data in a MESSAGE
d) Write a document that describes updates to the data.

The present document is, pretty much, a and c.
We could leave it, then write two more documents (b and d)
But that doesn't make a whole lot of sense, given that we know where we want to go.

But, as I said, it doesn't really matter to me how many documents this takes, and I'll follow the wishes of the work group.  If the path of least resistance is leave it (a and c), I'll restructure it a bit so we can reference the "a" part when we create b and d.

Brian

>> We ran a WGLC on data-only, and got some comments.  The discussion raises some fundamental issues that authors have been discussing. Here is our current thinking, which we would like discussion on before we rev the draft.
>> 
>> "Data Only" was intended, originally, for a sensor equipped automaton to send an alarm to a PSAP when there was no media.  It uses a CAP message in the body of a MESSAGE to do that.
>> 
>> It's been observed that there are cases where you have exactly the same kind of thing, with the same data, but you ALSO have media. In such a case, we would like to have the data sent the same way (CAP message in a body)
>> 
>> It's also been asked how updates to the alarm are sent.  At one point there was some discussion of using MSRP to send a series of messages.  Authors don't like this mechanism because it doesn't allow the PSAP to control the rate of updates.  We suggest that updates be handled with a SUB/NOT, with filtering, and the CAP message in the body of the NOTIFY.
>> 
>> If we were to do this, it would be major surgery to the existing draft, including a name change.  Nevertheless, that seems to be the right way to go.  We would:
>> a)Define the mechanism to carry a CAP message in the body of a SIP transaction, and define it for use in INVITE, MESSAGE and NOTIFY
>> b) Specify that INVITE is appropriate for alarms with media (creates session), and MESSAGE for alarms without media (doesn't create a session), but otherwise are equivalent.