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

[Randall Gellens <[e-mail]>]

At 10:39 AM +0000 12/1/16, Ivo Sedlacek wrote:

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

Ok, done.

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

OK, done.

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

OK, done.

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

OK.

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

OK.

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

OK.

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

OK.

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

I changed "attach" to "include".  Note that the paragraph already says:
    Per
    [RFC6086], metadata/control objects and MSDs are sent using the INFO
    package defined in Section 10.  In addition, to align with how an MSD
    or metadata/control block is transmitted in a SIP message other than
    an INFO request, a Call-Info header field is included in the SIP INFO
    request to reference the MSD or metadata/control block per [RFC7852].

I believe this makes it very clear that (a) everything sent within 
INFO is done per RFC6086, and (b) the use of Call-Info is done for 
consistency with non-INFO messages.


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

As above, I changed "attach" to "include" but the reference to RFC 
6086 is within the same paragraph and covers this sentence so doesn't 
need to be repeated.

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

As above.

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

OK.

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

I fixed cases where "request" was missing.  If you point out cases 
where "method" is missing I can fix them as part of IETF LC.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
[C]reativity [requires] the discomfort of confusion, uncertainty,
anxiety and ambiguity.
        --Jeff Mauzy and Richard Harriman, in 'Creativity Inc.'