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

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 1 Nov 2016 07:05:13 +0000

Randall,

so, what does "attach" mean if it does not meant Content-Disposition: attachment?

Kind regards

Ivo

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Monday, October 31, 2016 4:52 PM
To: Ivo Sedlacek <[email-masked]>
Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7

At 7:04 AM +0000 10/31/16, Ivo Sedlacek wrote:

>  Hello,
>
>
>>  >   > >>  >  ISSUE 7
>>  >   > >>  >
>>  >   > >>  >  section 6 - "The IVS then attaches an updated MSD to a SIP
>>  >   > >>  >     INFO request and sends it within the dialog." - 
>> what is meant by
>>  >   > >>  > "attaching MSD to SIP INFO request"?
>>  >   > >>
>>  >   > >>  I think that's made abundantly clear in the multiple earlier
>>  >   > >> instances in the  same section that say "as a MIME body part".
>>  >   > >
>>  >   > >  I do not really know what "attach body to SIP request"  means.
>>  >   > > Likely, other readers will not know it either.
>>  >   > >
>>  >   > >  A reference to a section defining how to "attach body to 
>> SIP request"
>>  >   > > would help.
>>  >   >
>>  >   > It's the same section, just a little bit before.
>>  >
>>  >  I assume you refer -19 text stating: "[RFC7852] establishes a 
>> general  > mechanism for attaching blocks of
>>  >     data to a SIP emergency call."
>>
>>  If you look seven paragraphs above the paragraph in question (same 
>> section),  you'll see:
>>
>>      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].
>>
>>  Then, three paragraphs later (four paragraphs above the paragraph in
>>  question) it uses "attach" again:
>>
>>      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.
>>
>>  The surrounding text makes it clear that these are "attached" as 
>> body parts  in the SIP message.
>
>  The above still talks about "attaching"/"attaches" without explaining 
> what it means.
>
>  It can be easily misunderstood to refer to inclusion of a body part 
> with Content-Disposition "attachment" in a SIP message.

Not so easily misunderstood, since the text repeatedly makes it very clear which Content-Disposition value to use.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- Perhaps the real reason why we have always been able to champion free speech in this country is that we know perfectly well that hardly anybody has got anything to say, and that no one will listen to anyone
that has.       -- Editorial, Daily Mail [British Paper, date unknown]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Nov 2016 08:48:41 -0400

> so, what does "attach" mean if it does not meant Content-Disposition: attachment?

IMO "attach X (to a sip message) means to package X as a mime body part 
and include it in the body of the message. That in turn means either:
- make it the complete body of the message if there are no other
   parts, and if it can validly be done that way;

- include it as a subordinate body part within a multipart/mixed that
   it the outer part of the body of the message.

In any case, it may then be necessary to do something more to ensure 
that the recipient will know what is the intent of the body part. In 
some cases this may be simply tagging it with appropriate content-type 
and content-disposition. In other cases it may also require including 
some sort of reference to it via a header field in the message or 
somewhere in one of the other body parts.

That is a "general" answer. It needs to be defined in detail for each case.

	Thanks,
	Paul

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Tue, 1 Nov 2016 14:01:33 +0000

Hello Paul,

Your interpretation of "attach X to SIP message" makes sense to me.

However, I do not see a statement "attach X to SIP message means ...." in the draft.

Kind regards

Ivo

-----Original Message-----
From: Ecrit [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, November 01, 2016 1:49 PM
To: [email-masked]
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7

> so, what does "attach" mean if it does not meant Content-Disposition: attachment?

IMO "attach X (to a sip message) means to package X as a mime body part and include it in the body of the message. That in turn means either:
- make it the complete body of the message if there are no other
   parts, and if it can validly be done that way;

In any case, it may then be necessary to do something more to ensure that the recipient will know what is the intent of the body part. In some cases this may be simply tagging it with appropriate content-type and content-disposition. In other cases it may also require including some sort of reference to it via a header field in the message or somewhere in one of the other body parts.

	Thanks,
	Paul

>>  The above still talks about "attaching"/"attaches" without 
>> explaining what it means.
>>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 1 Nov 2016 08:49:55 -0700

Hi Ivo,

It is explained in the same section.  A few paragraphs up it says:

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

    [....]

It also makes clear that the body part is in a multipart and which 
Content-Disposition is used:

    An MSD or a metadata/control block is always enclosed in a multipart
    (normally multipart/mixed) body part (even if it would otherwise be
    the only body part in the SIP message), since as of the date of this
    document, the use of Content-ID as a SIP header field is not defined
    (while it is defined for use as a MIME header field).

    A body part containing an MSD or metadata/control object has a
    Content-Disposition header field value containing "By-Reference".

It later uses "attach" as short-hand for the process described above:

--Randy

At 2:01 PM +0000 11/1/16, Ivo Sedlacek wrote:

>  IMO "attach X (to a sip message) means to package X as a mime body 
> part and include it in the body of the message. That in turn means 
> either:
>  In any case, it may then be necessary to do something more to 
> ensure that the recipient will know what is the intent of the body 
> part. In some cases this may be simply tagging it with appropriate 
> content-type and content-disposition. In other cases it may also 
> require including some sort of reference to it via a header field 
> in the message or somewhere in one of the other body parts.
>
>>  Not so easily misunderstood, since the text repeatedly makes it 
>> very clear which Content-Disposition value to use.
>>
>>  --
>>  Randall Gellens
>>  -------------- Randomly selected tag: --------------- Perhaps the 
>> real reason why we have always been able to champion free speech 
>> in this country is that we know perfectly well that hardly anybody 
>> has got anything to say, and that no one will listen to anyone

-------------- Randomly selected tag: ---------------
If the facts don't fit the theory, change the facts.
                                  --Albert Einstein

---

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 2 Nov 2016 08:36:17 +0000

Randall,

None of those statements quoted by you state "attach X to SIP message means  ...."

The statements nearest to stating "attach X to SIP message means  ...." are
---------
   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].
---------
and
---------
    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].
---------
but RFC7852 does not say "attach X to SIP message means  ...." either.

What statements of RFC7852 did you intend to refer to in the statements above?

PS: I have been following this discussion for quite some time. If I do NOT understand what "attach X to SIP message" means, how can a reader who has NOT followed this discussion understand it?

Kind regards

Ivo

-----Original Message-----
From: Randall Gellens [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2016 4:50 PM
To: Ivo Sedlacek <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7

Hi Ivo,

    [....]

It also makes clear that the body part is in a multipart and which Content-Disposition is used:

--Randy

At 2:01 PM +0000 11/1/16, Ivo Sedlacek wrote:

>>  Subject: RE: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - 
>> ISSUE
>>  7
>>
>>>>   If you look seven paragraphs above the paragraph in question 
>>>> (same  section),  you'll see:
>>>>
>>>   It can be easily misunderstood to refer to inclusion of a body 
>>> part  with Content-Disposition "attachment" in a SIP message.
>>
>>  Not so easily misunderstood, since the text repeatedly makes it very 
>> clear which Content-Disposition value to use.
>>
>>  --
>>  Randall Gellens
>> real reason why we have always been able to champion free speech in 
>> this country is that we know perfectly well that hardly anybody has 
>> got anything to say, and that no one will listen to anyone

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: --------------- If the facts don't fit the theory, change the facts.
                                  --Albert Einstein

---

From: Az Mankin <[email-masked]>
Date: Wed, 2 Nov 2016 11:36:02 -0700

Ivo,

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

Allison

On Wed, Nov 2, 2016 at 1:36 AM, Ivo Sedlacek <[email-masked]>
wrote:

> PS: I have been following this discussion for quite some time. If I do NOT
> understand what "attach X to SIP message" means, how can a reader who has
> NOT followed this discussion understand it?
>
> Kind regards
>
> Ivo
>

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 3 Nov 2016 08:48:42 +0000

(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

---

From: Randall Gellens <[email-masked]>
Date: Thu, 3 Nov 2016 09:07:23 -0700

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

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

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:
>  -------------------
>  - 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.
>
>  - "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)

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

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 3 Nov 2016 22:06:48 +0000

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:

> 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.
> >
> > "block transmitted by value" as described in rfc7852 section 6.1 the 
> > last paragraph 1st sentence:
> >  -------------------
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Nov 2016 09:12:09 +0000

Hi,

If something is undefined, we should either define it, or use alternative
terminology. 

I suggested alternative terminology some time ago, but that was not
adopted either.

Regards,

Christer

On 04/11/16 00:06, "Ecrit on behalf of Ivo Sedlacek"
<[email-masked] on behalf of [email-masked]> wrote:

>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.").
>
>>reference 
>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.
>
>"block transmitted by value" is defined in rfc7852. How can it be
>confusing to use that term together with referencing rfc7852???
>