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

[Christer Holmberg <[e-mail]>]

Hi,


>>>>   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?
>>
>>
>>  I think it would be good to have a reference on first occurrence,  
>> 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.

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:
>>>>
>>>>   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."
>>>
>>>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?
>>
>>  Some may think that 200 OK means that the ecall application accepted the
>>  MSD.
>
> 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 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. 


>>>>   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.
>>>
>>>I'll reword this text.
>>
>>  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?
>
> 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...")

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


>>>>  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.
>>
>>  The C-D of the multipart which contains the ecall body part(s) shall be
>>  info-package.
>
> 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.

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