Subject: [Ecrit] Whither data-only

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 29 Jan 2013 13:11:51 -0500

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

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Jan 2013 11:38:11 -0800

I am somewhat reluctant to do major surgery on the existing draft.  Instead,
my advice would be to define the SUB/NOT package in a separate document.
That would allow this document to be completed expeditiously. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rosen, Brian
Sent: Tuesday, January 29, 2013 10:12 AM
To: [email-masked] Org
Subject: [Ecrit] Whither data-only

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".

Comments?

Brian

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 29 Jan 2013 21:28:09 +0100

I've no major problem with most of this, but I thought one fairly common use case was that you sent a body of data, and after that there was a decision that media might be appropriate. 

So data device is in car, which is in accident - data device automatically fires off emergency accident data, but then there is a decision from either end that this needs to carry voice media to turn this into an emergency call with the driver.

So how would you handle this case with the proposal given. One option would be to assume from the start that the voice would be needed in this use case (even if it was not used), but are there alternatives.

Regards

Keith

> Sent: 29 January 2013 18:12
> To: [email-masked] Org
> 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.
>