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

Az Mankin <azmankin@gmail.com> Wed, 02 November 2016 18:36 UTC

Return-Path: <azmankin@gmail.com>
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 13923129517 for <ecrit@ietfa.amsl.com>; Wed, 2 Nov 2016 11:36:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 aVpUOK8vjpkP for <ecrit@ietfa.amsl.com>; Wed, 2 Nov 2016 11:36:06 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1001296B3 for <ecrit@ietf.org>; Wed, 2 Nov 2016 11:36:06 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id v84so30419196oie.3 for <ecrit@ietf.org>; Wed, 02 Nov 2016 11:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N/65/4M5qTg5vkS411+tYRt5Fh3EsG+HQpX4bmurnTY=; b=LMsGFvCS4ZY69wXma6bkf0JX5GQEdWP+ksno+TM0GqnZzklbBnSOAnoUukdaiXlbYQ p0ZDgyPO1fXhvVGWR2lzk/ahFCU2y7peKQnnyn3pC5xZb5oTc0AdPTWNdkXey9u8CQ+s FOuVlcMtjnGayZ5iNt5dWsQ2X5QSP53X99gR6DoG1PoGPm/NQQMtKGGy/FEMutKevPNW sJyM2JByZ/lxFSOzecqJuyfFecMfgbG3wrxQSoWxpi+37/BY3Dum94GmxMSEim9eZHZY R06CPUjfGTSdGZRd0D2bATb5kxYdm2CQp51w43CdAXfhJR3qWhxfvFAEkOvskCVtfYSg F0dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N/65/4M5qTg5vkS411+tYRt5Fh3EsG+HQpX4bmurnTY=; b=dPNAn9an9SYfG1fpLSbaGbzz1Cf6aJ4PZQcdGot7/MaDnDX8FbXCcpiU2qIOeb80G4 EhOfx+Y9Qv4i4QAX6BWAlBtMbZrMhLE/PL4nu2T5+qt/nkx9Q2YY361NdUkqpDMYctVq rzoUFxrKCoSUZN46McWlRzSNz0F+UJJglxc8gwDzy7RWXtMzw0/z6WW7jYq4N6EEwcYG C/Qj58T9KpQePHz74ttY4xGjaP7PULi1Z0dVDcOvgr5mCjkKt6y6zg/XvUmWRYoyDlex gtZfj1z9xjc4TGaBX6DgfMmaRioBuUxqkm39uxKVkwtje4Yx/3uWJIdg/U4hu3wuiRq5 Gpsw==
X-Gm-Message-State: ABUngvdLNPuuYBSZ7/BnSQ525m6NGhUXCDfra0aDfGGvLe58m9jyI8P+02hqBvpso3B6r62WMk5uhUnF6UzUqg==
X-Received: by 10.157.29.72 with SMTP id m66mr3448222otm.152.1478111765138; Wed, 02 Nov 2016 11:36:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.193.136 with HTTP; Wed, 2 Nov 2016 11:36:02 -0700 (PDT)
In-Reply-To: <AM5PR0701MB246842EF0357A9ACED7E60C1E5A00@AM5PR0701MB2468.eurprd07.prod.outlook.com>
References: <p06240600d43d18f64b41@99.111.97.136> <181874aa-8dc1-8cd5-3ced-9965ba071b82@alum.mit.edu> <p06240601d43e60ba377e@99.111.97.136> <AM5PR0701MB246842EF0357A9ACED7E60C1E5A00@AM5PR0701MB2468.eurprd07.prod.outlook.com>
From: Az Mankin <azmankin@gmail.com>
Date: Wed, 2 Nov 2016 11:36:02 -0700
Message-ID: <CAJD5LR2ueMF4DMWARUKBZu7M4w+_Amsc+Kd+TroSggHJN1CGsw@mail.gmail.com>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113ba4c0b312e1054055b62c
Archived-At: <https://mailarchive.ietf.org/arch/msg/ecrit/xV6rgF4Y4HXbH03r31vZyrvya14>
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
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: Wed, 02 Nov 2016 18:36:09 -0000

 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 <ivo.sedlacek@ericsson.com>
wrote:

> 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:rg+ietf@randy.pensive.org]
> Sent: Tuesday, November 01, 2016 4:50 PM
> To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>om>; Paul Kyzivat <
> pkyzivat@alum.mit.edu>gt;; ecrit@ietf.org
> Subject: Re: [Ecrit] Ivo's review of draft-ietf-ecrit-ecall-15 - ISSUE 7
>
> 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
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>