Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7

[Ivo Sedlacek <[e-mail]>]

(resending with ZIPed draft since mail was too long)


Hello Allison,

> Invoking IETF traditions here:  send text.  That is, give us a specific proposed edit to the existing text.

OK, let my try.

First of all, let me explain what I have done:

1) rfc7852 defines "conveying" of data (not "attaching" data):
-------------------

   When an emergency call is sent to a Public Safety Answering Point

   (PSAP), the originating device, the access network provider to which

   the device is connected, and all service providers in the path of the

   call have information about the call, the caller, or the location,

   which is helpful for the PSAP to have in handling the emergency.

   This document describes data structures and mechanisms to **convey such

   data** to the PSAP.  The intent is that every emergency call carry as

   much of the information described here as possible using the

   mechanisms described here.



   The mechanisms permit the data to be **conveyed** by reference (as an

   external resource) or by value (within the body of a SIP message or a

   location object).  This follows the tradition of prior emergency

   services standardization work where data can be conveyed by value

   within the call signaling (i.e., in the body of the SIP message) or

   by reference.
-------------------
so I use "convey" when introducing rfc7852 in eCall draft.

Moreover, given that rfc7852 does not use "attach" data, eCall draft should be able to live without "attach" data too.

2) I *think* the intention of "attach" in the draft is to refer to "block transmitted by value" as described in rfc7852 section 6.1 the last paragraph 1st sentence:
-------------------

   When blocks are transmitted by value, the 'purpose' parameter in a

   Call-Info header field identifies the data, and the CID URL points to

   the data block in the body (which has a matching Content-ID body part

   header field).
-------------------
So I use "block transmitted by value" everywhere in eCall draft with exception identified in 3) below.

3) 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 that rfc7852 is not needed, and eCall draft includes an explicit statement on Call-Info header field inclusion in SIP INFO request:
-------------------

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

Thus:
- when referring to INVITE request / INVITE response, I use "include X to SIP message as a block transmitted by value per RFC7852" instead of "attach X to SIP message"
- when referring to INFO request, I use "include X to SIP message as per RFC6086" instead of "attach X to SIP message".
                NOTE: The Call-Info header field inclusion is already described by the explicit statements above.

Please see attached version of -19, updated as above.

A few more errors is fixed there too:
- "INVITE" is used in some places where "INVITE request" should be.
- "method" is missing is some places.
- "This mechanism permits certain emergency call MIME types to be attached to SIP messages" - I took this out since:
                (a) the preceding sentence "[RFC7852] establishes a general mechanism for conveying blocks of data in a SIP emergency call." says the same thing
                (b) we never include a MIME type in a message (only a message-body of a given MIME type or a MIME body part of a given MIME type)
                (c) this sentence attempts to formulate what [RFC7852] contains and that's not needed - the reader should read [RFC7852] instead.

Kind regards

Ivo