Re: [Ecrit] Objection to draft-ietf-ecrit-ecall progressing to state "Submitted to IESG for Publication"

[Ivo Sedlacek <[e-mail]>]

Hello,



thank you Alissa.



I proposed changes resolving my concerns in a mail sent in 3rd Nov 2016 to ECRIT list. In that mail, I included an updated draft with proposed changes and explained why I did them.



Let me summarize those proposed changes again:



i)

Proposed change: replace "[RFC7852] establishes a general mechanism for attaching blocks of data to a SIP emergency call." with "[RFC7852] establishes a general mechanism for conveying blocks of data in a SIP emergency call.".

Reason: rfc7852 does not define "attaching" data, rfc7852 defines "conveying" of data.



ii)

Proposed change: remove "This mechanism permits certain emergency call MIME types to be attached to SIP messages."

Reason:

- rfc7852 does not define "attaching" data, rfc7852 defines "conveying" of data.

- the preceding sentence "[RFC7852] establishes a general mechanism for conveying blocks of data in a SIP emergency call." says the same thing.

- we never include a MIME type in a message, we can only include a message-body of a given MIME type or a MIME body part of a given MIME type.

- this sentence attempts to formulate what rfc7852 contains and that's not needed - the reader should read rfc7852 instead.



iii)

Proposed change: replace "An In-Vehicle System (IVS) transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [msd] and attaching it to a SIP message as a MIME body part per [RFC7852]." with "An In-Vehicle System (IVS) transmits an MSD (see Section 5) by encoding it per Annex A of EN 15722 [msd] in a MIME body part and by including the MIME body part in a SIP message as a block transmitted by value per [RFC7852]. "

Reason: rfc7852 does not define "attaching" data but rfc7852 defines what to do when blocks are transmitted by value.



iv)

Proposed change: replace "A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document and attaching it to a SIP message as a MIME body part per [RFC7852]." with "A PSAP or IVS transmits a metadata/control object (see Section 9) by encoding it per the description in this document in a MIME body part and including the MIME body part in a SIP message as a block transmitted by value per [RFC7852]."

Reason: same reason as for the previous proposed change.



v)

Proposed change: replace "An In-Vehicle System (IVS) initiating an NG-eCall attaches an MSD to the initial INVITE and optionally attaches a metadata/control object informing the PSAP of its capabilities." with "An In-Vehicle System (IVS) initiating an NG-eCall

   - includes a MIME body part containing an MSD as a block transmitted by value per [RFC7852]; and

  - optionally includes another MIME body part containing a metadata/control object informing the PSAP of its capabilities as a block transmitted by value per [RFC7852];

  in the initial INVITE request."

Reason: same reason as for the previous proposed change.



vi)

Proposed change: replace "The PSAP creates a metadata/control object acknowledging receipt of the MSD and attaches it to the SIP final response to the INVITE." with "The PSAP creates a metadata/control object acknowledging receipt of the MSD and includes it in the SIP final response to the INVITE request as a block transmitted by value per [RFC7852]."

Reason: same reason as for the previous proposed change.



vii)

Proposed change: extend "A PSAP is able to reject a call while indicating that it is aware of the situation by including a metadata/control object acknowledging the MSD and containing "received=true" in a final response using SIP response code 600 (Busy Everywhere), 486 (Busy Here), or 603 (Decline)." with additional text "as a block transmitted by value per [RFC7852]".

Reason: RFC7852 is to be used both when call is accepted and when it is rejected.



viii)

Proposed change: replace "To do so, the PSAP creates a metadata/control object requesting an MSD and attaches it to a SIP INFO request and sends it within the dialog." with "To do so, the PSAP creates a metadata/control object requesting an MSD, includes it to a SIP  INFO request as per [RFC6086] and sends it within the dialog.".

Reason: There has been discussion in past on whether rfc7852 is needed in SIP INFO request or not as sematic of the bodies associated with info package is defined in the info package itself. IIRC, the conclusion was:

- rfc7852 is not needed; and

- to align with how body parts are sent in an INFO request and in messages other than INFO requests, a Call-Info header field inclusion is added in SIP INFO request - see 2nd paragraph of section 10.6.



ix)

Proposed change: replace "The IVS then attaches an updated MSD to a SIP INFO request and sends it within the dialog." with "The IVS then includes an updated MSD to a SIP INFO request as per [RFC6086] and sends it within the dialog.".

Reason: same reason as for the previous proposed change.



x)

Proposed change: extend "If the IVS is unable to send an MSD, it instead sends a metadata/control object acknowledging the request with the 'success' parameter set to 'false' and a 'reason' parameter (and optionally a 'details' parameter) indicating why the request could not be accomplished." with additional text "as per [RFC6086]".

Reason: RFC6086 is to be used both when request to send MSD is accepted and when it is rejected.



xi)

Proposed change: replace "See Section 6 for more information on attaching a metadata/control block to a SIP message." with "See Section 6 for more information on including a metadata/control block to a SIP message.".

Reason: "attaching X to SIP message" is not defined.





It would be also nice to fix the following minor issues:

- "INVITE" is used in some places where "INVITE request" should be.

- "method" is missing is some places.

However, those are nice-to-have and not critical.



Kind regards



Ivo Sedlacek