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

[Randall Gellens <[e-mail]>]

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:

>  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.

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.

>
>
>>>>>    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?

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.


>   >>>>  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.

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Not a shred of evidence exists in favor of the idea that
life is serious.                          --Brendan Gill