Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
Randall Gellens <rg+ietf@randy.pensive.org> Tue, 01 November 2016 15:50 UTC
Return-Path: <rg+ietf@randy.pensive.org>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E762D12946B for <ecrit@ietfa.amsl.com>; Tue, 1 Nov 2016 08:50:00 -0700 (PDT)
X-Quarantine-ID: <Gw6pcFHkkmLa>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gw6pcFHkkmLa for <ecrit@ietfa.amsl.com>; Tue, 1 Nov 2016 08:49:59 -0700 (PDT)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5175712941D for <ecrit@ietf.org>; Tue, 1 Nov 2016 08:49:58 -0700 (PDT)
Received: from [99.111.97.136] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Tue, 1 Nov 2016 08:49:57 -0700
Mime-Version: 1.0
Message-Id: <p06240601d43e60ba377e@[99.111.97.136]>
In-Reply-To: <AM5PR0701MB2468C337DF3F94003FB3ABCEE5A10@AM5PR0701MB2468.eurprd07.pro d.outlook.com>
References: <AM5PR0701MB2468010828183D6956A82E66E5AE0@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <p06240600d43d18f64b41@[99.111.97.136]> <AM5PR0701MB2468AC6B5171EC51373DF563E5A10@AM5PR0701MB2468.eurprd07.pro d.outlook.com> <181874aa-8dc1-8cd5-3ced-9965ba071b82@alum.mit.edu> <AM5PR0701MB2468C337DF3F94003FB3ABCEE5A10@AM5PR0701MB2468.eurprd07.pro d.outlook.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 01 Nov 2016 08:49:55 -0700
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, "ecrit@ietf.org" <ecrit@ietf.org>
From: Randall Gellens <rg+ietf@randy.pensive.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/YE6-w64RHkf7FO7_BRkrxMSa7eE>
Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Nov 2016 15:50:01 -0000
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]. [....] 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]. 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: 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. --Randy At 2:01 PM +0000 11/1/16, Ivo Sedlacek wrote: > 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:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, November 01, 2016 1:49 PM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7 > > On 11/1/16 3:05 AM, Ivo Sedlacek wrote: >> Randall, >> >> 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 > >> Kind regards >> >> Ivo >> >> -----Original Message----- >> From: Randall Gellens [mailto:rg+ietf@randy.pensive.org] >> Sent: Monday, October 31, 2016 4:52 PM >> To: Ivo Sedlacek <ivo.sedlacek@ericsson.com> >> 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] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- 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
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Paul Kyzivat
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Az Mankin
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Randall Gellens
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Ivo Sedlacek
- Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecal… Christer Holmberg