Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-10.txt

From: [email-masked]
Date: Wed, 21 Sep 2016 16:17:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Emergency Context Resolution with Internet Technologies of the IETF.

        Title           : Next-Generation Vehicle-Initiated Emergency Calls
        Authors         : Randall Gellens
                          Brian Rosen
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-car-crash-10.txt
	Pages           : 42
	Date            : 2016-09-21

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of emergency calls placed
   by vehicles (automatically in the event of a crash or serious
   incident, or manually invoked by a vehicle occupant) and conveying
   vehicle, sensor, and location data related to the crash or incident.
   Such calls are often referred to as "Automatic Crash Notification"
   (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
   case of manual trigger.  The "Advanced" qualifier refers to the
   ability to carry a richer set of data.

   This document also registers a MIME Content Type and Emergency Call
   Additional Data Block for the vehicle, sensor, and location data
   (often referred to as "crash data" even though there is not
   necessarily a crash).  An external specification for the data format,
   contents, and structure are referenced in this document.

   This document reuses the technical aspects of next-generation pan-
   European eCall (a mandated and standardized system for emergency
   calls by in-vehicle systems within Europe and other regions).
   However, this document specifies a different set of vehicle (crash)
   data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
   the eCall Minimum Set of Data (MSD).  This document is an extension
   of the eCall document, with the primary differences being that this
   document makes the MSD data set optional and VEDS mandatory, and adds
   attribute values to the eCall metadata/control object to permit
   greater functionality.  This document registers a new INFO package
   (identical to that registered for eCall but with the addition of the
   VEDS MIME type).  This document also describes legacy (circuit-
   switched) ACN systems and their migration to next-generation
   emergency calling, to provide background information and context.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Sep 2016 22:04:51 -0400

Some initial comments during my first pass reading the diffs:

* Section 12:

The Content-Disposition of "Info-package" (applying to the 
multipart/mixed) is wrong, since this isn't an INFO message.  I forget 
if there was clear guidance on what C-D to use on a multipart/mixed 
wrapper. I think you can let it default to render.

I also see that the presence body referenced by the geolocation header 
doesn't have a Content-Disposition. It ought to be "by-reference", even 
though RFC6442 fails to specify that.

	Thanks,
	Paul

On 9/21/16 7:17 PM, [email-masked] wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2016 15:08:36 -0400

Randall,

(Including ecrit)

On 9/22/16 12:26 PM, Randall Gellens wrote:
> Hi Paul,
>
> Thanks very much for the quick review and comments.  I'm making other
> changes requested by Christer, and I want to fix the ones you found as
> well.
>
> Section 12 is the Security Considerations.

In the -10 version I am looking at section 12 is Examples.

> Did you mean Section 11, the
> Examples?  Or maybe Figure 10 (one of the examples)?   More to the point
> on correct C-D, there's text in Section 6 that says:
>
>    If the body part
>    containing the MSD or metadata/control block is the only body part,
>    it has a Content-Disposition header field value of "Info-Package;
>    handling=optional".  If it is contained within a multipart body part,
>    it has a Content-Disposition header field value of "By-Reference;
>    handling=optional".
>
> So this is wrong?  What should it say?

That text seems ok, at least for this case.

IIUC it isn't discussing the C-D *on* the multipart/mixed container. It 
is discussing parts *within* the multipart. Those seem to be correctly 
tagged.

The "Info-Package" C-D is only applicable for an INFO message. Since 
this isn't an INFO message it makes no sense to use it.

The authoritative document on this stuff is RFC5621.  However it is 
silent on what C-D used be used for multipart containers. So it is 
necessary to read between the lines to figure that out.

1) Consider an ordinary INFO message. It will have a body with C-D of 
"Info-Package", indicating that it is to be processed as the package for 
this INFO.

2) Next, add a header that needs to reference a body part, such as 
geolocation. Now we have two body parts, and need a multipart wrapper to 
contain them. One body part has C-D of "Info-Package" for the INFO, and 
the other has C-D of "by-reference" because it is referenced by the 
geolocation header. The multipart that wraps them needs *some* C-D. IMO 
it shouldn't be Info-Package because that would imply that the whole 
thing is to be used by the INFO message. It shouldn't be "by-reference" 
because it isn't referenced by anything. It is really processed in a 
special way, and we have no special C-D value to signify this. If 
omitted it will default to C-D:render,handling=required. Having it be 
required is appropriate in this case, since the handling of the info 
package is also required. The "render" value seems as good as any, since 
the contained parts have their own dispositions and "rendering" a 
multipart independent of its contents also seems to have no meaning.

3) A similar situation to (2) holds for INVITE. In this case of an SDP, 
the default C-D is "session".

4) For some message that doesn't require a body part for its own 
processing (e.g., UPDATE) and a single header with a CID reference. Then 
there will be no multipart - just the referenced part. It will still 
have a C-D of by-reference.

5) A message with no body part of its own, but multiple CID references 
from headers to body parts, will need a multipart body containing the 
referenced body parts. It will be much like (2) but without the 
Info-Package part.

> Section 10 (the INFO package registration) says:
>
>    If the body part is the only body
>    part, it has a Content-Disposition header field value of "INFO-
>    Package; handling=optional".  If the body part is contained within a
>    multipart body part, it has a Content-Disposition header field value
>    of "By-Reference; handling=optional" (the top-level multipart body
>    part has "INFO-Package" in its Content-Disposition value).
>
> So this is also wrong, especially the parenthetical statement that the
> top-level has a C-D of INFO-Package?  What should it say?

Hopefully the above is sufficient.

> Also, when you say "let it default to render" you mean just omit the C-D
> header field?

Yes. But that must be done with care, since it implies 
handling=required. If processing of the headers with references isn't 
required then that ought to be changed to handling=optional.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Sep 2016 14:46:34 -0700

>  In the -10 version I am looking at section 12 is Examples.

Sorry, I missed that you were replying to -10; I'd incorrectly 
assumed you were replying to -12.

>  IIUC it isn't discussing the C-D *on* the multipart/mixed 
> container. It is discussing parts *within* the multipart. Those 
> seem to be correctly tagged.
>
>  The "Info-Package" C-D is only applicable for an INFO message. 
> Since this isn't an INFO message it makes no sense to use it.

That was fixed in -12.

I'm about to upload -13, which fixes the C-D issues.  I also added 
text to clarify that "handling=optional" is only used in the initial 
INVITE, to protect the INVITE from being rejected if it is processed 
by a legacy element (such as a gateway between SIP and CS) that does 
not understand an MSD.  I fixed the examples to comply.

>  1) Consider an ordinary INFO message. It will have a body with C-D 
> of "Info-Package", indicating that it is to be processed as the 
> package for this INFO.
>
> geolocation. Now we have two body parts, and need a multipart 
> wrapper to contain them. One body part has C-D of "Info-Package" 
> for the INFO, and the other has C-D of "by-reference" because it is 
> referenced by the geolocation header. The multipart that wraps them 
> needs *some* C-D. IMO it shouldn't be Info-Package because that 
> would imply that the whole thing is to be used by the INFO message. 
> It shouldn't be "by-reference" because it isn't referenced by 
> anything. It is really processed in a special way, and we have no 
> special C-D value to signify this. If omitted it will default to 
> C-D:render,handling=required. Having it be required is appropriate 
> in this case, since the handling of the info package is also 
> required. The "render" value seems as good as any, since the 
> contained parts have their own dispositions and "rendering" a 
>  3) A similar situation to (2) holds for INVITE. In this case of an 
> SDP, the default C-D is "session".
>
> processing (e.g., UPDATE) and a single header with a CID reference. 
> Then there will be no multipart - just the referenced part. It will 
> still have a C-D of by-reference.
>
>  5) A message with no body part of its own, but multiple CID 
> references from headers to body parts, will need a multipart body 
> containing the referenced body parts. It will be much like (2) but 
> without the Info-Package part.
>
> handling=required. If processing of the headers with references 
> isn't required then that ought to be changed to handling=optional.
>
>  	Thanks,
>  	Paul

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
After years of disclosures by government investigations, media accounts,
and reports from human rights organizations, there is no longer any
doubt as to whether the current [George W Bush] administration has
committed war crimes.  The only question that remains to be answered is
whether those who ordered the use of torture will be held to account.
                    -- Major General Anthony Taguba, US Army (ret)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2016 18:25:50 -0400

see end

On 9/22/16 5:46 PM, Randall Gellens wrote:
> Sorry, I missed that you were replying to -10; I'd incorrectly assumed
> you were replying to -12.
>
>>
>>  IIUC it isn't discussing the C-D *on* the multipart/mixed container.
>> It is discussing parts *within* the multipart. Those seem to be
>> correctly tagged.
>>
> I'm about to upload -13, which fixes the C-D issues.  I also added text
> to clarify that "handling=optional" is only used in the initial INVITE,
> to protect the INVITE from being rejected if it is processed by a legacy
> element (such as a gateway between SIP and CS) that does not understand
> an MSD.  I fixed the examples to comply.

handling=optional is probably wrong on the multipart for an INVITE that 
contains an SDP offer. The processing of the SDP isn't optional, and if 
you encounter a UAS that doesn't support multipart then you want it to 
fail, not to be treated as an INVITE with no offer.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Sep 2016 15:32:45 -0700

At 6:25 PM -0400 9/22/16, Paul Kyzivat wrote:

>  handling=optional is probably wrong on the multipart for an INVITE 
> that contains an SDP offer. The processing of the SDP isn't 
> optional, and if you encounter a UAS that doesn't support multipart 
> then you want it to fail, not to be treated as an INVITE with no 
> offer.

Sorry for not being clear in my earlier message; the clarifications 
in the draft say that "handling=optional" in the initial INVITE 
applies to the MSD (in eCall), the VEDS (in car-crash), and the 
metadata/control object (in both) and the PIDF-LO.  It doesn't apply 
to the SDP nor the enclosing multipart, for the reasons you state.

-------------- Randomly selected tag: ---------------
. . . It wasn't until the jet engine came into being and that
engine was coupled with special airplane designs - such as the
swept wing - that airplanes finally achieved a high enough work
capability, efficiency and comfort level to allow air
transportation to really take off.
        --Joseph F. Sutter, Boeing Commercial Airplanes