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

[Ivo Sedlacek <[e-mail]>]

Randall,

I identified a technical problem ("attach X to SIP message" is not defined) during WGLC. 

You did not solve the technical problem during WGLC.

Paul's mail from 1st Nov somehow confirms that there can be different interpretations and something needs to be done ("It needs to be defined in detail for each case.").

I proposed a possible solution in the updated draft.

You do not like the solution but have not proposed any other solution till now.

The technical problem is still unresolved.

I think I have done my duty and it is time for chairs to settle what to do.



Now in details to your answers:

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

"attach X to SIP message" is NOT defined anywhere and thus the standard is NOT clear.

The nearest interpretation of "attach X to SIP message" is "include a body part containing X with Content-Disposition: attachment in SIP message", which does not work with the 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.
> 
> That seems more confusing to use in the eCall draft, since eCall data is not 
> transmitted by reference.

"block transmitted by value" is defined in rfc7852. How can it be confusing to use that term together with referencing rfc7852???

"attach X to SIP message" is NOT defined anywhere.

Can usage of a defined term be more confusing than usage of an undefined term???

Kind regards

Ivo