Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-26.txt

From: [email-masked]
Date: Fri, 10 Feb 2017 09:55:36 -0800

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 Pan-European eCall
        Authors         : Randall Gellens
                          Hannes Tschofenig
	Filename        : draft-ietf-ecrit-ecall-26.txt
	Pages           : 46
	Date            : 2017-02-10

Abstract:
   This document describes how to use IP-based emergency services
   mechanisms to support the next generation of the pan European in-
   vehicle emergency call service defined under the eSafety initiative
   of the European Commission (generally referred to as "eCall"). eCall
   is a standardized and mandated system for a special form of emergency
   calls placed by vehicles, providing real-time communications and an
   integrated set of related data.

   This document also registers MIME media types and an Emergency Call
   Additional Data Block for the eCall vehicle data and metadata/control
   data, and an INFO package to enable carrying this data in SIP INFO
   requests.

   Although this specification is designed to meet the requirements of
   European next-generation eCall, it is specified generically such that
   the technology can be re-used or extended to suit requirements across
   jurisdictions.

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

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

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

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: Randall Gellens <[email-masked]>
Date: Fri, 10 Feb 2017 11:33:18 -0800

The only change in this update of the eCall draft is to remove the 
"+per" suffix.  This was necessary because the designated expert for 
MIME content type structured content suffix pointed out that ASN.1 
PER encoding can't be understood independently of the content (unlike 
XML, which can be parsed without understanding the content).  As a 
result, the MIME content type has changed from 
application/emergencyCallData.eCall.MSD+per to 
application/emergencyCallData.eCall.MSD.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
2 + 2 = 5 for extremely large values of 2.

---

From: Alissa Cooper <[email-masked]>
Date: Sat, 11 Feb 2017 06:22:31 -0500

Unless there are objections to this by Feb 15, we’ll move forward with the document approval.

Thanks,
Alissa

> On Feb 10, 2017, at 2:33 PM, Randall Gellens <[email-masked]> wrote:
> 
> The only change in this update of the eCall draft is to remove the "+per" suffix.  This was necessary because the designated expert for MIME content type structured content suffix pointed out that ASN.1 PER encoding can't be understood independently of the content (unlike XML, which can be parsed without understanding the content).  As a result, the MIME content type has changed from application/emergencyCallData.eCall.MSD+per to application/emergencyCallData.eCall.MSD.
> 
> -- 
> Randall Gellens
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 12 Feb 2017 10:58:14 +0000

Hi,

One small comment.

Section 6 says:

   "An MSD or a metadata/control block is always enclosed in a multipart
   (normally multipart/mixed) body part (even if it would otherwise be
   the only body part in the SIP message), since as of the date of this
   document, the use of Content-ID as a SIP header field is not defined
   (while it is defined for use as a MIME header field)."

draft-ietf-sipcore-content-id, which defines Content-ID as a SIP header field, has now been adopted by SIPCORE.

So, I wonder whether we could simply remove the second part of this paragraph? I don't think we need to change anything else, because I think we still want to always enclose the stuff in a multipart.

Regards,

Christer

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Alissa Cooper
Sent: 11 February 2017 13:23
To: Randall Gellens <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-26.txt

Thanks,
Alissa

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Feb 2017 14:19:45 -0500

> So, I wonder whether we could simply remove the second part of this paragraph? I don't think we need to change anything else, because I think we still want to always enclose the stuff in a multipar…

Question: is there intent to remove the requirement to wrap the MSD in a 
multipart body once the the work in sipcore completes? Is it your goal 
to future proof this text so it need not be changed to accomplish that?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 12 Feb 2017 19:54:27 +0000

Hi,

>> So, I wonder whether we could simply remove the second part of this paragraph? I don't think we need to change 
>> anything else, because I think we still want to always enclose the stuff in a multipart.
>
> Question: is there intent to remove the requirement to wrap the MSD in a multipart body once the the work in 
> sipcore completes? Is it your goal to future proof this text so it need not be changed to accomplish that?

Before I answer your question, I mixed up things a little. In INFO requests we will always place the stuff in a multipart. But, the main reason for that was so the SIP level Content-Disposition value is always 'info-package' (within the MIME we then always use C-D 'by-refernce').

Regarding your question, my initial suggestion was not to remove the requirement to wrap, only to remove the sentence saying that the Content-ID is not defined as a SIP header field. But, when thinking about it, there really is no need to require wrap in non-INFO requests, so maybe we should consider removing it - unless someone comes up with a reason why we should mandate it? In reality I think INVITE requests will at least carry SDP too, so one will anyway have to use a multipart.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Feb 2017 15:01:05 -0500

> Regarding your question, my initial suggestion was not to remove the requirement to wrap, only to remove the sentence saying that the Content-ID is not defined as a SIP header field. But, when thin…

Do you want to make this draft wait for that work in sipcore? (And for 
implementations to support it.)

It would be cleaner to remove the requirement for wrapping. But if you 
are in a rush it might be better not to be dependent on that further 
work being completed.

	Thanks,
	Paul

---

From: Randall Gellens <[email-masked]>
Date: Sun, 12 Feb 2017 12:14:41 -0800

At 2:19 PM -0500 2/12/17, Paul Kyzivat wrote:

>  Question: is there intent to remove the requirement to wrap the MSD 
> in a multipart body once the the work in sipcore completes? Is it 
> your goal to future proof this text so it need not be changed to 
> accomplish that?

I think there is not much actual benefit to removing the requirement, 
while there is some downside: it would make the draft dependent on 
the content-id draft, and it would require further changes in other 
SDO work (e.g., 3GPP) that includes the requirement.  So I'd suggest 
we leave it is.

-------------- Randomly selected tag: ---------------
The average man does not know what to do with his life, yet wants
another one which will last forever.             --Anatole France

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 12 Feb 2017 21:16:24 +0000

Hi,

>>>> So, I wonder whether we could simply remove the second part of this 
>>>> paragraph? I don't think we need to change anything else, because I think we still want to always enclose the stuff in a multipart.
>>>
>>> in a multipart body once the the work in sipcore completes? Is it your goal to future proof this text so it need not be changed to accomplish that?
>>
>> Before I answer your question, I mixed up things a little. In INFO requests we will always place the stuff in a multipart. But, the 
>> main reason for that was so the SIP level Content-Disposition value is always 'info-package' (within the MIME we then always use C-D 'by-refernce').
>>
>> Regarding your question, my initial suggestion was not to remove the requirement to wrap, only to remove the sentence saying 
>> that the Content-ID is not defined as a SIP header field. But, when thinking about it, there really is no need to require wrap in non-INFO 
>> requests, so maybe we should consider removing it - unless someone comes up with a reason why we should mandate it? In reality I think 
>> INVITE requests will at least carry SDP too, so one will anyway have to use a multipart.
>
> Do you want to make this draft wait for that work in sipcore? (And for implementations to support it.)
>
> It would be cleaner to remove the requirement for wrapping. But if you are in a rush it might be better not to be dependent on that further work being completed.

Even though it would take a little longer before the RFC is published, the ecall draft would still be stable, and I don't see any major issues with the Content-ID draft either. The discussions have been more philosophical than technical.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 12 Feb 2017 21:18:49 +0000

Hi,

>> in a multipart body once the the work in sipcore completes? Is it your 
>> goal to future proof this text so it need not be changed to accomplish 
>> that?
>
> I think there is not much actual benefit to removing the requirement, while there is some downside: it would make the draft dependent 
> on the content-id draft, and it would require further changes in other SDO work (e.g., 3GPP) that includes the requirement.  So I'd suggest we leave it is.

I don't think it would require any major changes in other SDOs, at least not in 3GPP.

I am pretty confident the Content-ID draft will anyway be adopted by 3GPP, no matter whether it's needed by ecall or not.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Sun, 12 Feb 2017 14:42:25 -0800

At 9:18 PM +0000 2/12/17, Christer Holmberg wrote:

>>  I think there is not much actual benefit to removing the 
>> requirement, while there is some downside: it would make the draft 
>> dependent
>>  on the content-id draft, and it would require further changes in 
>> other SDO work (e.g., 3GPP) that includes the requirement.  So I'd 
>> suggest we leave it is.
>

Of course it only requires minor changes, not major ones.

>  I am pretty confident the Content-ID draft will anyway be adopted 
> by 3GPP, no matter whether it's needed by ecall or not.

That's good, of course, although I don't see it as a significant 
reason to change the draft.

-------------- Randomly selected tag: ---------------
Few ideas are really bad.  Most are either pre- or post-mature.
                                                   --Jon Postel

---

From: Randall Gellens <[email-masked]>
Date: Sun, 12 Feb 2017 20:10:27 -0800

At 7:54 PM +0000 2/12/17, Christer Holmberg wrote:

>  In INFO requests we will always place the stuff in a multipart. 
> But, the main reason for that was so the SIP level 
> Content-Disposition value is always 'info-package' (within the MIME 
> we then always use C-D 'by-refernce').
>
>  Regarding your question, my initial suggestion was not to remove 
> the requirement to wrap, only to remove the sentence saying that 
> the Content-ID is not defined as a SIP header field. But, when 
> thinking about it, there really is no need to require wrap in 
> non-INFO requests, so maybe we should consider removing it - unless 
> someone comes up with a reason why we should mandate it? In reality 
> I think INVITE requests will at least carry SDP too, so one will 
> anyway have to use a multipart.

As you say, in reality the initial INVITE will be multipart anyway, 
so we may as well not make the eCall draft depend on the sipcore 
draft.

-------------- Randomly selected tag: ---------------
Idiot:  A member of a large and powerful tribe whose influence in
human affairs has always been dominant and controlling.
                        --Ambrose Bierce, "The Devil's Dictionary"