Subject: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-additional-data

From: Randall Gellens <[email-masked]>
Date: Tue, 29 Mar 2011 05:07:00 -0700

As discussed in today's meeting, I think it's useful to consider two 
broad categories of additional data: that which is known by a server, 
and that which only the device knows.

If the server knows the data, then the mechanism in the draft 
(inserting an HTTPS URI into a Call-Info header) is fine.  But if 
only the device knows the data, this mechanism requires the device to 
first upload the data to a server and obtain a URL, before attempting 
call setup.  A better approach would be to allow data known by the 
client to be transmitted by the client as a MIME body part.  In 
theory, this can be done either in the call-setup (as a body part in 
the INVITE, similar to how location-by-value is transmitted), or in a 
subsequent SIP method after call setup.  I suggest the latter, using 
SIP MESSAGE method for this.  Especially for telematics data, which 
could grow to be fairly large, this seems useful.

New MIME subtypes can be registered, with whatever granularity we 
want.  For example, under the application subtype (or text, but I'm 
leaning towards application), we can define subtypes for various 
forms of additional-data for emergency calls, such as telematics, 
device-info, etc.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The trouble with the world is not that people know too little, but
that they know so many things that ain't so.
--Mark Twain

---

From: Brian Rosen <[email-masked]>
Date: Tue, 29 Mar 2011 14:17:04 +0200

Subject to what Martin is thinking, I was imagining that in both the Call Info header and the hook where telematics info goes could be a CID, which could be found in the body.

Brian

On Mar 29, 2011, at 2:07 PM, Randall Gellens wrote:

> As discussed in today's meeting, I think it's useful to consider two broad categories of additional data: that which is known by a server, and that which only the device knows.
> 
> If the server knows the data, then the mechanism in the draft (inserting an HTTPS URI into a Call-Info header) is fine.  But if only the device knows the data, this mechanism requires the device to first upload the data to a server and obtain a URL, before attempting call setup.  A better approach would be to allow data known by the client to be transmitted by the client as a MIME body part.  In theory, this can be done either in the call-setup (as a body part in the INVITE, similar to how location-by-value is transmitted), or in a subsequent SIP method after call setup.  I suggest the latter, using SIP MESSAGE method for this.  Especially for telematics data, which could grow to be fairly large, this seems useful.
> 
> New MIME subtypes can be registered, with whatever granularity we want.  For example, under the application subtype (or text, but I'm leaning towards application), we can define subtypes for various forms of additional-data for emergency calls, such as telematics, device-info, etc.
> 
> -- 
> Randall Gellens

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 14:17:47 +0200

I agree that HTTPS access is a pain for device-included information.  But it also seems like using MESSAGE would prevent this information from being used for call routing.

If there's few enough things to include, maybe it could go in a SIP header?  Could be helpful to specify which data items are likely to be sourced from the client?

--Richard

On Mar 29, 2011, at 2:07 PM, Randall Gellens wrote:

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 29 Mar 2011 20:22:56 +0800

I see a couple of problems with the statements below.
Firstly, there are several classification of server that can provide additional data, and not all are directly in the call path or necessarily communicate using SIP, so inserting a URI into a SIP header isn't a ubiquitous solution.

I also think that quite a lot of "device-knows" data as being quite sensitive. If this is sent in a MIME body, we to make sure that nothing that should be able to have it can have it, and that include all the SIP intermediaries along the way to the thing that is finally entitled to have it. This was one of the reasons for using HTTPS and having registries in which this data was placed.

Cheers
James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randall Gellens
> Sent: Tuesday, 29 March 2011 11:07 PM
> To: Brian Rosen; ECRIT
> Subject: [Ecrit] Client-known vs. server-known data in draft-ietf-ecrit-
> additional-data
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Mar 2011 22:53:31 +0800

The statement that the device needs to upload the data is only a problem for the data that is only pertinent/generated at call time.  Some of this data (in fact a goodly portion of it) is fairly static and it can be established ahead of the call, probably LONG ahead.

On 2011-03-29 at 14:22:56, Winterbottom, James wrote:
> Firstly, there are several classification of server that can provide 
> additional data, and not all are directly in the call path or 
> necessarily communicate using SIP, so inserting a URI into a SIP 
> header isn't a ubiquitous solution.
> 
> I also think that quite a lot of "device-knows" data as being quite 
> sensitive. If this is sent in a MIME body, we to make sure that 
> nothing that should be able to have it can have it, and that include 
> all the SIP intermediaries along the way to the thing that is finally 
> entitled to have it. This was one of the reasons for using HTTPS and 
> having registries in which this data was placed.
> 
> Cheers
> James
> 
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> > Of Randall Gellens
> > Subject: [Ecrit] Client-known vs. server-known data in
> > draft-ietf-ecrit- additional-data
> >
> > broad categories of additional data: that which is known by a 
> > server, and that which only the device knows.
> >
> only
> > the device knows the data, this mechanism requires the device to
> first
> > upload the data to a server and obtain a URL, before attempting call 
> > setup.  A better approach would be to allow data known by the client 
> > to be transmitted by the client as a MIME body part.  In theory, 
> > this can be done either in the call-setup (as a body part in the 
> > INVITE, similar to how location-by-value is transmitted), or in a 
> forms
> > of additional-data for emergency calls, such as telematics, 
> > device-info, etc.
> >
> > --
> > Randall Gellens
> > -------------- Randomly selected tag: --------------- The trouble
> with
> > the world is not that people know too little, but that they know so 
> > many things that ain't so.
> > --Mark Twain

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 29 Mar 2011 22:54:46 +0800

Bingo.  Just what I was thinking.  How the information is included will depend on the dynamics of the data.

On 2011-03-29 at 14:17:04, Brian Rosen wrote:
> Subject to what Martin is thinking, I was imagining that in both the 
> Call Info header and the hook where telematics info goes could be a 
> CID, which could be found in the body.
> 
> Brian
> 
> (inserting an HTTPS URI into a Call-Info header) is fine.  But if only 
> the device knows the data, this mechanism requires the device to first 
> to be transmitted by the client as a MIME body part.  In theory, this 
> can be done either in the call-setup (as a body part in the INVITE, 
> similar to how location-by-value is transmitted), or in a subsequent 
> SIP method after call setup.  I suggest the latter, using SIP MESSAGE 
> method for this.  Especially for telematics data, which could grow to 
> be fairly large, this seems useful.
> >
> leaning towards application), we can define subtypes for various forms 
> of additional-data for emergency calls, such as telematics, device- 
> info, etc.
> >
> > --
> > Randall Gellens