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

[Christer Holmberg <[e-mail]>]

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.


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


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

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


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

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?



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

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.

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