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

[Randall Gellens <[e-mail]>]

Hi Christer,

Please see inline.

At 6:37 AM +0000 10/12/16, Christer Holmberg wrote:

>  Hi,
>
>  Please see inline:
>
>
>>>   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.
>>
>>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.
>
>
>  I just want to make it clear that none of the above is something that is
>  covered in THIS document.

OK, I'll make this more clear.


>   >>  Q5:
>>>
>>>   In Section 5, I suggest to re-name the title to "MSD Format", or
>>>  something like that.
>>
>>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.
>
>  I was thinking more about this, and I'm ok with the current title.
>
>
>>>   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.


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

OK, I'll note that.

>
>  I DO agree that, in most cases, MSD will not be the only body part in the
>  INVITE.
>
>
>>>   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.
>>
>>It's just trying to note that there might be multiple levels of
>>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...

OK, I'll delete it.


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

>
>  MSD only means that the receiving SIP stack accepted the INFO.
>
>
>>>   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...")


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

>
>  Perhaps that multipart is within another multipart, but that's a separate
>  issue.
>
>
>>>   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.
>
>  I don't agree. These specific examples are cases where the INFO only
>  contains ecall information, which is the normal case.

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.

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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Justice is incidental to law and order.
                      --J.Edgar Hoover