Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15)

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Oct 2016 18:37:48 +0000

Hi,

Attached is my review of draft-ietf-ecrit-ecall-15. I have not reviewed Section 15.

Note that some of my comments probably apply to draft-ietf-ecrit-car-crash also, so I ask the authors to take that into consideration.

Regards.

Christer

----------

Q1:

In Section 2, I suggest to change the title to "Applicability", because I think that is what is normally used.

Q2:

In Section 2, you should expand "3GPP" and "CEN" on first occurrence. In addition, I think there should be a reference with "3GPP IMS Emergency Calling".

Q3:

In Section 2, the text says:

   "The technical contents of this document also provide a basis for
   reuse and extension for other vehicle-initiated emergency call
   Systems.

   Vehicles designed for multiple regions might need to support eCall
   and other Advanced Automatic Crash Notification (AACN) systems, such
   as described in [I-D.ietf-ecrit-car-crash]."

I don¹t think the text is needed, but if you want to keep it you should explicitly say that it¹s outside the scope of the document.

Q4:

In Section 3, you first describe eCall in general, which is good. But then, in the last paragraph, you suddenly start talking about MIME types. I think you should add another chapter, giving a general overview of what the document does. I guess you can re-use text from the Abstract.

Q5:

In Section 5, I suggest to re-name the title to "MSD Format", or something like that.

Q6:

In Section 6, please add references to the different SIP/MIME header fields (Content-Type, Content-ID etc).

Q7:

In Section 6, the text says:

   "An MSD or a metadata/control block is always enclosed in a multipart
   body part (even if it would otherwise be the only body part in the
   SIP message)."

We did agree on this for INFO, but is there a reason for doing this also in non-INFO requests?

Q8:

In Section 6, the text says:

   "Note that in some cases there might be intermediate
   multipart body parts between the top level multipart and the body
   part containing the MSD or metadata/control object."

I have no idea what that text means.

Q9:

In Section 9, I suggest to remove the bullet list. I don¹t really understand why it is needed, and it¹s unclear what "This mechanism" refers to.
IF you want to list requirements associated with carrying control/metadata I think it should be in a separate section.

Q10:

In Section 9, the text says:

   "if the IVS sends a requested MSD in an INFO request and does not receive a SIP
   status message for the INFO request, it resends it; if the PSAP
   requests an MSD and does not receive a SIP status message for the
   INFO request, it resends it.)"

This is basic SIP,  and can be removed. Earlier you mention SIP re-transmission, and that¹s enough. I think you should add the following, though:

   ³Note that, per RFC6086, a 200 OK response to the INFO request only indicates that the receiver has successfully received and accepted the INFO request."

Q11:

In Section 9, the text says:

   "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here), and 603 (Decline) are used when
   the PSAP wants to reject a call but inform the vehicle occupants that
   it is aware of the situation."

Please add a reference to where this is defined.

Q12:

In Section 10.6, please add explicit text that says that multipart is used even if only a single body part is transported. You may even reference the example in RFC 6086. Also add explicit text saying that ³Per RFC 6086, the content disposition value of the multipart MIME is 'info-package', or something like that.

Q13:

In Section 10.6, similar to my earlier comment, I don¹t understand the text about "intermediary body parts".

Q14:

In Section 11, you should add the Content-Disposition SIP header field (with 'info-package' value) to the INFO requests.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Oct 2016 18:44:09 +0000

Regarding Q4, I mean "add another PARAGRAPH" :)

From: Ecrit [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 11 October 2016 21:38
To: [email-masked]
Subject: [Ecrit] Christer's review of draft-ietf-ecrit-ecall-15 (excluding Section 15)

Hi,

Regards.

Christer

----------

Q1:

Q2:

Q3:

Q4:

Q5:

Q6:

Q7:

Q8:

Q9:

Q10:

Q11:

Q12:

Q13:

Q14:

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Tue, 11 Oct 2016 15:56:24 -0700

Hi Christer,

Thanks for your review.  Please see initial answers (before I've 
edited the draft) below.

--Randy

At 6:44 PM +0000 10/11/16, Christer Holmberg wrote:

>  Note that some of my comments probably apply to 
> draft-ietf-ecrit-car-crash also, so I ask the authors to take that 
> into consideration.
>
>  Regards.
>
>  Christer
>
>  ----------
>
>  Q1:
>
>  In Section 2, I suggest to change the title to "Applicability", 
> because I think that is what is normally used.

I've always used "Document Scope" for this material (e.g., see RFC 7852).

>  Q2:
>
>  In Section 2, you should expand "3GPP" and "CEN" on first 
> occurrence. In addition, I think there should be a reference with 
> "3GPP IMS Emergency Calling".

Good suggestion, thanks, I'll add these.

>  I don't think the text is needed, but if you want to keep it you 
> should explicitly say that it's outside the scope of the document.

I think the first sentence helps explain the expansion items (e.g., 
used by the car-crash draft), and the second was added by request of 
Keith a year or two ago; I'm happy to reword both sentences to make 
it more clear that this is background info.

>  Q4:
>
>  In Section 3, you first describe eCall in general, which is good. 
> But then, in the last paragraph, you suddenly start talking about 
> MIME types. I think you should add another chapter, giving a 
> general overview of what the document does. I guess you can re-use 
> text from the Abstract.

I see your point.  I'll add another paragraph saying what the draft 
does, to provide a smoother transition into the one about the MIME 
types.

>  In Section 5, I suggest to re-name the title to "MSD Format", or 

What is your concern with the current title?  To me, "Vehicle Data" 
is more general and hence easier to understand for someone who 
doesn't know what an MSD is.  The text explains that the data is 
called an MSD.  How about if I add "(MSD)" to the title?  That way, 
someone who knows they are looking for the MSD info can find it, and 
someone who doesn't know what an MSD is will know what the section is 
about.

>  Q6:
>
>  In Section 6, please add references to the different SIP/MIME 
> header fields (Content-Type, Content-ID etc).

We have multiple references to RFC 7852.  Do you think we need to 
also reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 
for Content-ID and RFC 2045 for Content-Type and Content-Disposition?

> also in non-INFO requests?

I suspect so, and it's the same reason: so that Content-ID is valid. 
(In reality, I can't imagine that an MSD would be the only body part 
in an initial INVITE, but I think we need to say so just in case.)

>  I have no idea what that text means.

It's just trying to note that there might be multiple levels of 
multipart.  I'll reword this to make it simpler.

>  Q9:
>
>  In Section 9, I suggest to remove the bullet list. I don't really 
> understand why it is needed, and it's unclear what "This mechanism" 
> refers to.
>  IF you want to list requirements associated with carrying 
> control/metadata I think it should be in a separate section.

I think you're right that the bullet list and some surrounding text 
can be deleted.

>  This is basic SIP,  and can be removed. Earlier you mention SIP 
> re-transmission, and that's enough. I think you should add the 
> following, though:
>
>     "Note that, per RFC6086, a 200 OK response to the INFO request 
> only indicates that the receiver has successfully received and 
> accepted the INFO request."

I'm happy to delete the text after "Normal SIP retransmission handles 
non-receipt of requested data".  I agree it isn't needed.

Is there specific text that you think is potentially confusing and 
hence needs the note about the semantics of a 200 OK?

>  Please add a reference to where this is defined.

I'll reword this text.

>  Q12:
>
>  In Section 10.6, please add explicit text that says that multipart 
> is used even if only a single body part is transported.

I'll add text to make it more explicit.

>   You may even reference the example in RFC 6086. Also add explicit 
> text saying that "Per RFC 6086, the content disposition value of 
> the multipart MIME is 'info-package', or something like that.

We had an email discussion about this some weeks back, and Paul 
pointed out that it wasn't always correct for the top level multipart 
to have a Content-Disposition of INFO-Package.

>
>
>  Q13:
>
>  In Section 10.6, similar to my earlier comment, I don't understand 
> the text about "intermediary body parts".

I'll fix this as above.

>  Q14:
>
>  In Section 11, you should add the Content-Disposition SIP header 
> field (with 'info-package' value) to the INFO requests.

In the email discussion, Paul said it was better to leave it off.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
The Pledge of Allegiance says `liberty and justice for all'.  Which part
of `all' don't you understand?         --Rep. Pat Schroeder (D) Colorado

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Oct 2016 23:25:18 -0400

On 10/11/16 6:56 PM, Randall Gellens wrote:

> I suspect so, and it's the same reason: so that Content-ID is valid. (In
> reality, I can't imagine that an MSD would be the only body part in an
> initial INVITE, but I think we need to say so just in case.)

I wonder how many implementations will break when they get an INVITE 
with a multipart body but no offer included. :-)

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 06:37:24 +0000

Hi,

>it more clear that this is background info.

I just want to make it clear that none of the above is something that is
covered in THIS document.

>someone who doesn't know what an MSD is will know what the section is

I was thinking more about this, and I¹m ok with the current title.

>for Content-ID and RFC 2045 for Content-Type and Content-Disposition?

I think it would be good to have a reference on first occurrence,
especially since some header fields aren¹t SIP header fields.

>in an initial INVITE, but I think we need to say so just in case.)

You are right.

Maybe it would be good to add a note saying that the reason is that, at
the time of writing the document, the usage of Content-ID as a SIP header
field was not defined.

I DO agree that, in most cases, MSD will not be the only body part in the
INVITE.

>multipart.  I'll reword this to make it simpler.

I don¹t think we need to say anything. It¹s basic multipart handling, and
we don¹t define any procedures that mandates multiple levels, so...

>hence needs the note about the semantics of a 200 OK?

Some may think that 200 OK means that the ecall application accepted the
MSD.

MSD only means that the receiving SIP stack accepted the INFO.

>>  Please add a reference to where this is defined.

My question was not about the wording - it was more about where this is
defined.

I.e., is this something you define for ecall, or it is something generic
defined elsewhere?

>to have a Content-Disposition of INFO-Package.

The C-D of the multipart which contains the ecall body part(s) shall be
info-package.

Perhaps that multipart is within another multipart, but that¹s a separate
issue.

>In the email discussion, Paul said it was better to leave it off.

I don¹t agree. These specific examples are cases where the INFO only
contains ecall information, which is the normal case.

If people also want to add an example where the INFO also contains
non-ecall stuff, we can do that, even though I don¹t think it¹s needed.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Wed, 12 Oct 2016 09:14:06 -0700

Hi Christer,

Please see inline.

>  covered in THIS document.

OK, I'll make this more clear.

>  I was thinking more about this, and I'm ok with the current title.
>
>
>>>   Q6:
>>>
>  especially since some header fields aren't SIP header fields.

These are standard MIME header fields, just as multipart handling is 
standard MIME, and we don't need a reference to multipart handling.

>  the time of writing the document, the usage of Content-ID as a SIP header

OK, I'll note that.

>  I don't think we need to say anything. It's basic multipart handling, and
>  we don't define any procedures that mandates multiple levels, so...

OK, I'll delete it.

>  Some may think that 200 OK means that the ecall application accepted the

We already talk about what the MSD ack means.  Let me think about how 
to work something about what a 200 OK doesn't mean in to that text.

>  I.e., is this something you define for ecall, or it is something generic

It's defined here.  I'll reword it to make this more clear (e.g., "a 
PSAP is able to reject a call but inform...")

>  The C-D of the multipart which contains the ecall body part(s) shall be

If a multipart contains only eCall body parts, then maybe so, but as 
Paul pointed out, a multipart within an INFO request can contain body 
parts related to the INFO package and other body parts.  I think Paul 
made a larger point that the C-D of multiparts is not 
straightforward, so it's better not to make a blanket statement about 
it.

>
>  Perhaps that multipart is within another multipart, but that's a separate
>  issue.
>
>
>>>   Q14:
>>>
>  I don't agree. These specific examples are cases where the INFO only

I'm happy either way (to add the "Content-Disposition: INFO-package" 
or leave it off as Paul suggested), but I'd like to hear from Paul 
before making a change.

>  non-ecall stuff, we can do that, even though I don't think it's needed.

-------------- Randomly selected tag: ---------------
Justice is incidental to law and order.
                      --J.Edgar Hoover

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Oct 2016 17:32:38 +0000

Hi,

>>>We have multiple references to RFC 7852.  Do you think we need to also 
>>>reference RFC 3261 for Call-Info and RFC 2045 and/or RFC 2392 for 
>>>Content-ID and RFC 2045 for Content-Type and Content-Disposition?
>>
>>
> These are standard MIME header fields, just as multipart handling is standard MIME, and we don't need a reference to multipart handling.

Ok, I don't want to delay the work because of that, so I withdraw the comment. You may get the same comment from the Gen-ART and/or IESG folks, though.

> to work something about what a 200 OK doesn't mean in to that text.

I think you should say that the 200 OK only means that the receiver accepted the INFO, and that any potential application-level error message will come in a separate INFO request. 

>>>>      "The SIP response codes 600 (Busy Everywhere), 486 (Busy Here),
>>>>        and 603 (Decline) are used when the PSAP wants to reject a call but inform the vehicle occupants
>>>>        that it is aware of the situation."
>>>>

Does it really belong to section 9? Wouldn't e.g., section 7 be more appropriate?

> straightforward, so it's better not to make a blanket statement about 

The Info Package body part(s) always need to be within a Info-Package multipart.

Then, if you also want to include non-Info Package body part(s), you DO need a "multilevel" multipart.

Something like:

C-T: multipart/MIME
   ---boundary
   C-T multipart/MIME
   C-D info package
       ---boundary2
       <ecall content, e.g., MSD>
       ---boundary2---
   ---boundary
   C-T foo
   C-D bar 
   <non ecall content>
   ---boundary---

And, as the examples show INFOs with Info Package body parts only, there shall be a SIP header field C-D:info-package.

Regards,

Christer

---

From: Randall Gellens <[email-masked]>
Date: Wed, 12 Oct 2016 15:41:31 -0700

Hi Christer,

I've made all the edits, except for the Content-Disposition, which as 
I mentioned I'm happy to do either way, but based on the earlier 
discussion with Paul, I'm concerned that the correct C-D value of 
multiparts isn't straightforward, so a blanket statement might be 
incorrect.  I think we can avoid saying how C-D is to be set in 
multiparts since we do say multiple times very plainly that 
everything that is sent in an INFO request is sent per RFC 6086.  So 
I think we can leave that to implementers' interpretation of the 
relevant RFCs.

See below for other resolutions.

At 5:32 PM +0000 10/12/16, Christer Holmberg wrote:

>>  These are standard MIME header fields, just as multipart handling 
>> is standard MIME, and we don't need a reference to multipart 
>> handling.
>
>  Ok, I don't want to delay the work because of that, so I withdraw 
> the comment. You may get the same comment from the Gen-ART and/or 
> IESG folks, though.
>
>>>>>   Q10:
>>>>>
>  I think you should say that the 200 OK only means that the receiver 
> accepted the INFO, and that any potential application-level error 
> message will come in a separate INFO request.

I added text that "per <xref target="RFC6086"/>, a 200 OK response to 
an INFO request indicates only that the receiver has successfully 
received and accepted the INFO request, it says nothing about the 
acceptability of the payload".  I'd rather not add text about 
application-level error messages here, because the specific context 
is a solicited MSD that the PSAP finds unacceptable, and in that case 
the PSAP isn't expected to send a negative acknowledgement because 
(a) the PSAP can request a new MSD if it wants, and (b) the IVS 
wouldn't be expected to take any action if it did, since any resent 
MSD would almost certainly have the same problem, since it's likely a 
bug in either the IVS or PSAP.

>  Does it really belong to section 9? Wouldn't e.g., section 7 be 

It could go in several sections, including 9, because it's mostly 
about the metadata/control object, but I moved it to section 6 
because it seemed to fit best there in the flow of the text.

>  And, as the examples show INFOs with Info Package body parts only, 
> there shall be a SIP header field C-D:info-package.

Since this is different than what Paul said in the earlier exchange, 
I'd like to get confirmation before adding C-D to the examples. 
Especially because I think if there's any ambiguity, we may be better 
off leaving C-D out, since the examples say that not all SIP header 
fields are shown.

-------------- Randomly selected tag: ---------------
Not a shred of evidence exists in favor of the idea that
life is serious.                          --Brendan Gill