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

[Randall Gellens <[e-mail]>]

Hi Ivo,

At 8:43 AM +0000 11/3/16, Ivo Sedlacek wrote:

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

RFC 7852 discusses equally sending data with the call and sending a 
reference to data that is available externally, hence the use of the 
neutral term "conveyance."  I think using "conveyance" in the eCall 
draft would be less well understood by the average reader than using 
"attach."  The term "attach" seems pretty generally well understood, 
and the current language in the draft makes it very clear exactly 
what steps are performed.

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

That seems more confusing to use in the eCall draft, since eCall data 
is not transmitted by reference.

>
>  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
>
>  Content-Type: text/plain; name="draft-ietf-ecrit-ecall-19-ISED.txt"
>  Content-Description: draft-ietf-ecrit-ecall-19-ISED.txt
>  Content-Disposition: attachment;
>  	filename="draft-ietf-ecrit-ecall-19-ISED.txt"; size=100680;
>  	creation-date="Thu, 03 Nov 2016 07:52:03 GMT";
>  	modification-date="Thu, 03 Nov 2016 08:26:07 GMT"
>
>  Attachment converted: TiLand:draft-ietf-ecrit-ec#3AC1B64.txt 
> (TEXT/R*ch) (03AC1B64)


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
In the United States the majority undertakes to supply a multitude of
ready-made opinions for the use of individuals, who are thus relieved
from the necessity of forming opinions of their own
      --Alexis de Tocqueville