From nobody Mon May 1 00:21:08 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AC7126B6D for ; Mon, 1 May 2017 00:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.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 7yk_ik13zRVW for ; Mon, 1 May 2017 00:21:05 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E556F1293E0 for ; Mon, 1 May 2017 00:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=itlLL0dAXB6fug1vn/714yqkkxIjXzB+BxDWO1zPahY=; b=plTlWd692euV7jXs0Ivxk58FWzl27mAoXO8ybd+YmI8XAL9/UrgaFVcnX20xLithFJ3k3zioGm1mQplrV9A40qzVYRVPSYCL09Wqy7fpRj9w9KtcQbwfILbv+KlxIkk5Uukk3nAg6NhJtZTUFtkHfIPQwMWWE6ieQPJSsU866YU= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-151-jVD9j0QZMueTkhLvjGUZ2A-1; Mon, 01 May 2017 03:18:17 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Mon, 1 May 2017 07:18:15 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.021; Mon, 1 May 2017 07:18:14 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Proposal to revise the dual stack milestone Thread-Index: AQHSwfMkaim5598Vpk+qqnple4/tO6HfELKw Date: Mon, 1 May 2017 07:18:14 +0000 Message-ID: References: <87bmrdmxo0.fsf@hobgoblin.ariadne.com> In-Reply-To: <87bmrdmxo0.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:RWefngCYN39Vcv5IV+aVyuTaR213xIR1LDvQzWFLy5T69DRxBymxaY6XBxItBY8QN+U5WLzfUeKOA0+QW/2x3pF2NL0twS98B6nXgnXZ8WSLguAg14uKAALUpOX4Lg67IO9yKWm0p07t7rkAbPUUAHwCi2/C9E+QVcCTOgdGyaT5MhVMIQYDRt6+Nsf9dZl4+goecHeMz6kUubrXTzLOa+87wd8YgOeEely3Kja8kUzap0STNUd6vKlzpP7om2ukvuj8HnuREHN8R2JVo+Yk9jXSvo3iJn5H9FXNqxhcETOMfIzmks8g4TDINlctKhlqS5pP9BRMUGW7Al60AkccUg==; 20:vbWL+3e40uRiOU+40Wl2gb8kG9zBOvPvjW0/RBRM/G7vpfb67+ZVEYXQeQ5JcWL2G6MOWZVNuI5Ncd9V9gN2QbZMsMRYifsSgr9WS10PgmLQMSEqpmhzPW4oVby7Ky3U+KimbzgQ/fyPQpfrsbhsXkjxtNVJc/cQIp8+C5xmKe4= x-ms-office365-filtering-correlation-id: 3f7ca707-07fa-43bc-6621-08d490623bc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2350; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 02945962BD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39400400002)(39830400002)(13464003)(377454003)(5660300001)(102836003)(3846002)(6116002)(478600001)(2501003)(66066001)(53546009)(25786009)(8676002)(86362001)(305945005)(7736002)(74316002)(81166006)(8936002)(3280700002)(3660700001)(7696004)(33656002)(229853002)(6306002)(55016002)(2906002)(2900100001)(53936002)(9686003)(99286003)(54356999)(76176999)(6436002)(561944003)(189998001)(122556002)(38730400002)(2950100002)(77096006)(6506006)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 May 2017 07:18:14.7725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: jVD9j0QZMueTkhLvjGUZ2A-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Proposal to revise the dual stack milestone X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 07:21:07 -0000 I think that is a good idea with a few caveats: i- Connectionless transports should be covered as well (possibly by making = use of OPTIONS) ii- Use of multiple interfaces/transport protocols should be mentioned as w= ell. I think this can be done just by adding a few sentences along the line= s of: All IP Address Family/Transport Family/Interface triplet combinations shoul= d be tried simultaneously. Some headstart may be provided for certain combi= nations depending on local policy. Otherwise I think it is the right approach not to dive into details of the = algorithm to use.=20 Thanks, Tolga -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Sunday, April 30, 2017 4:46 PM To: sipcore@ietf.org Subject: [sipcore] Proposal to revise the dual stack milestone The Sipcore working group has the following milestone listed (at https://datatracker.ietf.org/wg/sipcore/about/): Dec 2017 Request publication of mechanisms for rapid dual-stack protocol selection in SIP The draft draft-johansson-sip-he-connection is listed for this milestone. = However, that draft covers only a narrow subset of the overall problem. Over the past month or so, I have been canvassing Sipcore members to find o= ut if there is any practical demand for a dual-stack solution for SIP. Wit= h the exception of a particular case, I have found no interest. Because of this, I propose that we narrow the scope of this milestone to th= e one case for which I have found interest: Request publication of a mechanism for rapid dual-stack protocol selection in SIP when the destination has multiple, unprioritized targets for connection-oriented protocols Conveniently, draft-johansson-sip-he-connection describes such a mechanism.= Its mechanism closely parallels that of RFC 6555 ("Happy Eyeballs"), and = the text is essentially complete. Because there are no unresolved technica= l issues, the text is complete, and there are known implementation instance= s where this mechanism is needed, I urge the approval of this draft even if= its scope is narrow. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon May 1 12:25:48 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59733129AB2 for ; Mon, 1 May 2017 12:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 8zeUv4x9VnGq for ; Mon, 1 May 2017 12:25:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5B61D129505 for ; Mon, 1 May 2017 12:22:24 -0700 (PDT) Received: from unescapeable.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v41JMMPp027619 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 May 2017 14:22:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be unescapeable.local To: Yehoshua Gev References: <87mvc3iym3.fsf@hobgoblin.ariadne.com> <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com> Cc: sipcore From: Robert Sparks Message-ID: Date: Mon, 1 May 2017 14:22:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D87F6094A1F083772BE56F53" Archived-At: Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 19:25:47 -0000 This is a multi-part message in MIME format. --------------D87F6094A1F083772BE56F53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Yehoshua - It was that last paragraph of the introduction to section 20 that I was pointing to. The change made by this document doesn't take those sentences away. I still don't agree that new normative text is the necessary (I actually feel it's dangerous - it adds yet another opportunity for misinterpretation). But I re-read the end of the introduction to section 20 with the changes this document specifies applied to it, and I think I see an improvement that might ease the discomfort you're feeling with it. Section 2 currently says this: > 2. Updates to RFC3261 > > This text from the introduction to section 20 of [RFC3261]: > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). > > is replaced with: > > When constructing the value of any SIP header field whose grammar > allows choosing between name-addr and addr-spec, such as those > that use the form '(name-addr / addr-spec)', the "addr-spec" form > MUST NOT be used if its value would contain a comma, semicolon, > or question mark. > > The header fields defined in this specification that allow this > choice are "To", "From", "Contact", and "Reply-To". We could change it to say this (being more explicit with what happens to the rest of the paragraph being operated on). > 2. Updates to RFC3261 > > This text from the introduction to section 20 of [RFC3261]: > > The Contact, From, and To header fields contain a URI. If the URI > contains a comma, question mark or semicolon, the URI MUST be > enclosed in angle brackets (< and >). Any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > > > is replaced with: > > When constructing the value of any SIP header field whose grammar > allows choosing between name-addr and addr-spec, such as those > that use the form '(name-addr / addr-spec)', the "addr-spec" form > MUST NOT be used if its value would contain a comma, semicolon, > or question mark. > When a URI appears in such a header field, any URI parameters are > contained within these brackets. If the URI is not enclosed in angle > brackets, any semicolon-delimited parameters are header-parameters, > not URI parameters. > The header fields defined in this specification that allow this > choice are "To", "From", "Contact", and "Reply-To". Does that ease your concern? RjS On 4/18/17 2:42 AM, Yehoshua Gev wrote: > Hi Robert, > Can you point me to the text on 3261 that has the disambiguation rule? > I could only find it in the last paragraph of section 20, which only > speaks about "Contact, From, and To". > I believe the intention of this draft is to expand this paragraph to > cover all other "problematic" headers, > so it should also expand the disambiguation rule to the other headers. > Thanks, > Yehoshua > On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks > wrote: > > Hi Yehoshua - > > On 3/30/17 5:57 AM, Yehoshua Gev wrote: >> On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley >> > wrote: >> >> Yehoshua Gev > >> writes: >> > The examples of: >> > Refer-To: >> sip:123@host?Replaces=1111 >> > Refer-To: >> sip:123@host;user=phone?Replaces=1111 > So, the interpreting >> the string "sip:123@host" as the addr-spec alone, > renders >> the > header non-parsable by the BNF of 3515. Yes... but if >> you're only considering the BNF, "sip:123@host?Replaces=1111" >> can be parsed as an addr-spec, so the header is valid (by the >> BNF alone). (Actually, even "sip:123@host" can't be parsed >> as a name-addr, because it doesn't have "<...>".) >> >> Ok. I see your point. So when parsing header like "Refer-To: >> sip:123@host;user=phone", the BNF parser will give two possible >> interpretation, and the non-BNF restriction will rule out one of >> them. And for "Refer-To: sip:123@host?Replaces=1111", the BNF >> parser will give one possible interpretation, which will be ruled >> out by the restriction. I believe my first understanding was that >> the restriction is applied to addr-spec, disallowing it from >> having uri-parameters/headers. And if the restriction if applied >> after parsing the add-spec, prior to parsing the rest of the >> Refer-To header, it will make the header syntactically invalid. >> But I guess it's a philosophical question. >> >> > Given so, IMHO the disambiguation rule should be stated as >> a normative text. ... So, yes, the new disambiguation rule is >> stated as a normative text. >> >> The normative text in the draft only considers the "construction" >> of the header, >> it doesn't handle parsing/interpretation of a "constructed" header. >> Specifically, a sentence like "If the URI is not enclosed in >> angle brackets, >> any semicolon-delimited parameters are header-parameters, not URI >> parameters" (from RFC 3261 section 20) is missing. >> I suggest adding a text like: >> "If the URI in such headers is not enclosed in angle brackets, >> any characters >> after a comma, a question mark, or a semicolon SHOULD NOT be >> parsed as >> part of the URI". >> Alternatively: >> "When a URI is part of addr-spec which is not part of name-addr, >> the addr-spec >> SHOULD NOT be parsed to include a comma, a question mark, or a >> semicolon". > 3261 does already say this. and there's no ambiguity to clear up - > we'd be restating it here, and restating things that are required > by a base specification is something we avoid. >> Thanks, >> Yehoshua >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ sipcore mailing > list sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --------------D87F6094A1F083772BE56F53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Yehoshua -

It was that last paragraph of the introduction to section 20 that I was pointing to. The change made by this document doesn't take those sentences away.

I still don't agree that new normative text is the necessary (I actually feel it's dangerous - it adds yet another opportunity for misinterpretation).

But I re-read the end of the introduction to section 20 with the changes this document specifies applied to it, and I think I see an improvement that might ease the discomfort you're feeling with it.

Section 2 currently says this:

2.  Updates to RFC3261

   This text from the introduction to section 20 of [RFC3261]:

     The Contact, From, and To header fields contain a URI.  If the URI
     contains a comma, question mark or semicolon, the URI MUST be
     enclosed in angle brackets (< and >).

   is replaced with:

     When constructing the value of any SIP header field whose grammar
     allows choosing between name-addr and addr-spec, such as those
     that use the form '(name-addr / addr-spec)', the "addr-spec" form
     MUST NOT be used if its value would contain a comma, semicolon,
     or question mark.

     The header fields defined in this specification that allow this
     choice are "To", "From", "Contact",  and "Reply-To".
We could change it to say this (being more explicit with what happens to the rest of the paragraph being operated on).

2.  Updates to RFC3261

   This text from the introduction to section 20 of [RFC3261]:

     The Contact, From, and To header fields contain a URI.  If the URI
     contains a comma, question mark or semicolon, the URI MUST be
     enclosed in angle brackets (< and >).  Any URI parameters are
     contained within these brackets.  If the URI is not enclosed in angle
     brackets, any semicolon-delimited parameters are header-parameters,
     not URI parameters.


   is replaced with:

     When constructing the value of any SIP header field whose grammar
     allows choosing between name-addr and addr-spec, such as those
     that use the form '(name-addr / addr-spec)', the "addr-spec" form
     MUST NOT be used if its value would contain a comma, semicolon,
     or question mark.
     When a URI appears in such a header field, any URI parameters are
     contained within these brackets.  If the URI is not enclosed in angle
     brackets, any semicolon-delimited parameters are header-parameters,
     not URI parameters.
     The header fields defined in this specification that allow this
     choice are "To", "From", "Contact",  and "Reply-To".

Does that ease your concern?
RjS





On 4/18/17 2:42 AM, Yehoshua Gev wrote:

Hi Robert,


Can you point me to the text on 3261 that has the disambiguation rule?
I could only find it in the last paragraph of section 20, which only speaks about "Contact, From, and To".
I believe the intention of this draft is to expand this paragraph to cover all other "problematic" headers,
so it should also expand the disambiguation rule to the other headers.


Thanks,
Yehoshua






On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks <rjsparks@nostrum.com> wrote:


  
    
  
  

    
Hi Yehoshua -

    

    

    
On 3/30/17 5:57 AM, Yehoshua Gev wrote:

    

    

      

        

          
On Thu, Mar 30, 2017 at 12:04 AM,
            Dale R. Worley <worley@ariadne.com> wrote:

            
Yehoshua
                Gev <yoshigev@gmail.com>
                writes:

                >> > The examples of:

                >> >    Refer-To: sip:123@host?Replaces=1111

                >> >    Refer-To: sip:123@host;user=phone?Replaces=1111

                

              > So, the interpreting the
                string "sip:123@host" as the addr-spec alone,

                > renders the

                > header non-parsable by the BNF of 3515.

                

              Yes... but if you're only considering the BNF,

              "sip:123@host?Replaces=1111" can be parsed as an
              addr-spec, so the

              header is valid (by the BNF alone).  (Actually, even
              "sip:123@host"

              can't be parsed as a name-addr, because it doesn't have
              "<...>".)

            


            

            Ok. I see your point.

            So when parsing header like  "Refer-To:
            sip:123@host;user=phone",

            the BNF parser will give two possible interpretation, and
            the

            non-BNF restriction will rule out one of them.

            And for "Refer-To: sip:123@host?Replaces=1111", the BNF
            parser will

            give one possible interpretation, which will be ruled out by
            the restriction.

            

            I believe my first understanding was that the restriction is
            applied to

            addr-spec, disallowing it from having
            uri-parameters/headers.

            And if the restriction if applied after parsing the
            add-spec, prior to parsing

            the rest of the Refer-To header, it will make the header
            syntactically invalid.

            But I guess it's a philosophical question.
            


            

            
 

            

            

                > Given so, IMHO the disambiguation rule should be
                stated as a normative text.

              ...

              So, yes, the new disambiguation rule is stated as a
              normative text. 

            


            

            
The normative text in the draft only considers the
              "construction" of the header,

            
it doesn't handle parsing/interpretation of a
              "constructed" header.

            
Specifically, a sentence like "If the URI is not enclosed in
                angle brackets,

            
any semicolon-delimited
                parameters are header-parameters, not URI

            
parameters" (from RFC 3261 section 20) is
                missing.

            


            

            
I suggest adding a text like:

            

            
"If the URI in such headers is not enclosed in angle
              brackets, any characters

            
after a comma, a question mark, or a semicolon SHOULD
              NOT be parsed as

            
part of the URI".

            
Alternatively:

            
"When a URI is part of addr-spec which is not part of
              name-addr, the addr-spec

            
SHOULD NOT be parsed to include a comma, a question
              mark, or a semicolon".

          

        

      

    

    3261 does already say this. and there's no ambiguity to clear up -
    we'd be restating it here, and restating things that are required by
    a base specification is something we avoid.

    

      

        

          

            


            

            
Thanks,

            
Yehoshua

            


            

          

        

      

      

      

      

      
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


    

    

  



_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org/mailman/listinfo/sipcore












--------------D87F6094A1F083772BE56F53--


From nobody Mon May  1 16:00:12 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E707B129473 for ; Mon,  1 May 2017 16:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 41IHlzDXcZtZ for ; Mon,  1 May 2017 16:00:08 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F1E12EB34 for ; Mon,  1 May 2017 15:57:57 -0700 (PDT)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with SMTP id 5KG7dFY8P61D95KGTdC0xR; Mon, 01 May 2017 22:57:57 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1493679477; bh=WRYD80Fuu+LT5XOLLw2yBWorVn2mo3k+WLKRX21xMAs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=K+0EmFDgVhMR/dDFQISpWeiB08mMFCoWHmEgNrDf7zv+Sfh0nWdp7UME9basl9aBo U1HBI3cdUIEp8pYeoH8Dch49y99MqmVX/sNrswVIbKRWpviGMuwRQz8EXib5ufOIuB 1tJwuZIwDGcekivZRCDiEsKwecUuhDHdJ2xY6k1ani/JoVePp5MlFzYjjAhZIjRZpR KskVjgC4L8bhRocMdIvwcjErfxDrloj8HwkYd5kUGF++5w9FE6pFnnNUifhtn8rneE vmE9yS70nGxxQit8izo8HcQhUw1EeihbTv+M38AFuPhFRZD8Xou5YWQ10Qc0zZrcmI nmrr2tq8AXWwA==
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-18v.sys.comcast.net with SMTP id 5KGSdA4QnStKd5KGSdZEEd; Mon, 01 May 2017 22:57:57 +0000
To: sipcore@ietf.org
References:  <87mvc3iym3.fsf@hobgoblin.ariadne.com>  <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com>  
From: Paul Kyzivat 
Message-ID: 
Date: Mon, 1 May 2017 18:57:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfKgqabdKEG//jNdImdAgpav+5WzjU3zTlIogEV4m5jUUPV7e8/ij2FuQi18cjpzwL356tJHuq8KWrbw1Z0o4Ae+hn3rIyMHjGMnvYGYqhXATbpTjdX4E H+MtMmVcqwK3VpayAqSQJHOdtIkWf8UKENo5osHA84viKlobSYumHrcS+6/EewKmZq55yDdx2uyRoQ==
Archived-At: 
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 01 May 2017 23:00:11 -0000

Robert,

Please see inline.

On 5/1/17 3:22 PM, Robert Sparks wrote:
> Hi Yehoshua -
>
> It was that last paragraph of the introduction to section 20 that I was
> pointing to. The change made by this document doesn't take those
> sentences away.
>
> I still don't agree that new normative text is the necessary (I actually
> feel it's dangerous - it adds yet another opportunity for
> misinterpretation).
>
> But I re-read the end of the introduction to section 20 with the changes
> this document specifies applied to it, and I think I see an improvement
> that might ease the discomfort you're feeling with it.
>
> Section 2 currently says this:
>
>> 2. Updates to RFC3261
>>
>>    This text from the introduction to section 20 of [RFC3261]:
>>
>>      The Contact, From, and To header fields contain a URI.  If the URI
>>      contains a comma, question mark or semicolon, the URI MUST be
>>      enclosed in angle brackets (< and >).
>>
>>    is replaced with:
>>
>>      When constructing the value of any SIP header field whose grammar
>>      allows choosing between name-addr and addr-spec, such as those
>>      that use the form '(name-addr / addr-spec)', the "addr-spec" form
>>      MUST NOT be used if its value would contain a comma, semicolon,
>>      or question mark.
>>
>>      The header fields defined in this specification that allow this
>>      choice are "To", "From", "Contact",  and "Reply-To".
> We could change it to say this (being more explicit with what happens to
> the rest of the paragraph being operated on).
>
>> 2. Updates to RFC3261
>>
>>    This text from the introduction to section 20 of [RFC3261]:
>>
>>      The Contact, From, and To header fields contain a URI.  If the URI
>>      contains a comma, question mark or semicolon, the URI MUST be
>>      enclosed in angle brackets (< and >).  Any URI parameters are
>>      contained within these brackets.  If the URI is not enclosed in angle
>>      brackets, any semicolon-delimited parameters are header-parameters,
>>      not URI parameters.
>>
>>
>>    is replaced with:
>>
>>      When constructing the value of any SIP header field whose grammar
>>      allows choosing between name-addr and addr-spec, such as those
>>      that use the form '(name-addr / addr-spec)', the "addr-spec" form
>>      MUST NOT be used if its value would contain a comma, semicolon,
>>      or question mark.
>>      When a URI appears in such a header field, any URI parameters are
>>      contained within these brackets.  If the URI is not enclosed in angle
>>      brackets, any semicolon-delimited parameters are header-parameters,
>>      not URI parameters.
>>      The header fields defined in this specification that allow this
>>      choice are "To", "From", "Contact",  and "Reply-To".

What you are trying to do seems very good. But there is still trouble 
with the wording. The use of "these brackets" has no referent. How about 
this:

    When a URI appears in such a header field, any URI parameters are
    contained within angle brackets (< and >).  If the URI is not
    enclosed in angle brackets, any semicolon-delimited parameters are
    header-parameters, not URI parameters.

(Or the first "are" above might be replaced by "MUST be".)

	Thanks,
	Paul

> Does that ease your concern?
>
> RjS
>
> On 4/18/17 2:42 AM, Yehoshua Gev wrote:
>> Hi Robert,
>> Can you point me to the text on 3261 that has the disambiguation rule?
>> I could only find it in the last paragraph of section 20, which only
>> speaks about "Contact, From, and To".
>> I believe the intention of this draft is to expand this paragraph to
>> cover all other "problematic" headers,
>> so it should also expand the disambiguation rule to the other headers.
>> Thanks,
>> Yehoshua
>> On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks > > wrote:
>>
>>     Hi Yehoshua -
>>
>>     On 3/30/17 5:57 AM, Yehoshua Gev wrote:
>>>     On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley
>>>     > wrote:
>>>
>>>         Yehoshua Gev >
>>>         writes: >> > The examples of: >> >    Refer-To:
>>>         sip:123@host?Replaces=1111 >> >    Refer-To:
>>>         sip:123@host;user=phone?Replaces=1111 > So, the interpreting
>>>         the string "sip:123@host" as the addr-spec alone, > renders
>>>         the > header non-parsable by the BNF of 3515. Yes... but if
>>>         you're only considering the BNF, "sip:123@host?Replaces=1111"
>>>         can be parsed as an addr-spec, so the header is valid (by the
>>>         BNF alone).  (Actually, even "sip:123@host" can't be parsed
>>>         as a name-addr, because it doesn't have "<...>".)
>>>
>>>     Ok. I see your point. So when parsing header like  "Refer-To:
>>>     sip:123@host;user=phone", the BNF parser will give two possible
>>>     interpretation, and the non-BNF restriction will rule out one of
>>>     them. And for "Refer-To: sip:123@host?Replaces=1111", the BNF
>>>     parser will give one possible interpretation, which will be ruled
>>>     out by the restriction. I believe my first understanding was that
>>>     the restriction is applied to addr-spec, disallowing it from
>>>     having uri-parameters/headers. And if the restriction if applied
>>>     after parsing the add-spec, prior to parsing the rest of the
>>>     Refer-To header, it will make the header syntactically invalid.
>>>     But I guess it's a philosophical question.
>>>
>>>
>>>         > Given so, IMHO the disambiguation rule should be stated as
>>>         a normative text. ... So, yes, the new disambiguation rule is
>>>         stated as a normative text.
>>>
>>>     The normative text in the draft only considers the "construction"
>>>     of the header,
>>>     it doesn't handle parsing/interpretation of a "constructed" header.
>>>     Specifically, a sentence like "If the URI is not enclosed in
>>>     angle brackets,
>>>     any semicolon-delimited parameters are header-parameters, not URI
>>>     parameters" (from RFC 3261 section 20) is missing.
>>>     I suggest adding a text like:
>>>     "If the URI in such headers is not enclosed in angle brackets,
>>>     any characters
>>>     after a comma, a question mark, or a semicolon SHOULD NOT be
>>>     parsed as
>>>     part of the URI".
>>>     Alternatively:
>>>     "When a URI is part of addr-spec which is not part of name-addr,
>>>     the addr-spec
>>>     SHOULD NOT be parsed to include a comma, a question mark, or a
>>>     semicolon".
>>     3261 does already say this. and there's no ambiguity to clear up -
>>     we'd be restating it here, and restating things that are required
>>     by a base specification is something we avoid.
>>>     Thanks,
>>>     Yehoshua
>>>
>>>     _______________________________________________
>>>     sipcore mailing list
>>>     sipcore@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/sipcore
>>>     
>>     _______________________________________________ sipcore mailing
>>     list sipcore@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/sipcore
>>     
>>
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>


From nobody Thu May  4 11:22:18 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5C12940E for ; Thu,  4 May 2017 11:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 H-zq9uVTfJrQ for ; Thu,  4 May 2017 11:22:14 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (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 B72C81293EC for ; Thu,  4 May 2017 11:22:13 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id y190so13188204vkc.1 for ; Thu, 04 May 2017 11:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=7v0gLkl7EJZ48YQnyWZA6EWItyCm5f8+zbWuxskECl4=; b=UkrrPjs1NuPn28xKyrLk1O2X+r4aVWZPqPaLX2VCV4UYSAqBU5veGDdVCpUz59FIgP Hrxaisxv342HDQUWgD2UejnFXR8veD7a9b9Gkm1mWqsHD2p7kPJfmdWV6bEwDcS4TRQh NtQdSy2GUiDjuOhJXl1/Gt3SJ8C7cIfpjmOuHeD/kq563VLgdpzmc6cIQhRSou3POqSk G0WCa6YMb0/06r0lp3bqn5uUVroMdo5kbAFYnosgiIJqC3GwQCTyYNXamRECVJR0I6mR auftAwiyJDxIB23xoNqIUn5fxpsyRPOiZMNDJIufE6TKhbiGjaXcjVKKJ79AtcKd8bq2 SBxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7v0gLkl7EJZ48YQnyWZA6EWItyCm5f8+zbWuxskECl4=; b=n2IUbuqQYCR0pz170g3/1VqHwPMGmJzwtGsCp0E5bqgJGbzU+T7+lTU+pqv8tKWvIN /shQQNPMEf/lUAzjI67cDYfvwMqeaOtp4Mo5RdyQ59nlqUR5DO5M9WzIfxOwAwO4a+M1 yaksRspnAgNO5o4hBIaosZRVSBvjQW+2M5SbUnQn6BiRrAL+hrKJ1PTsckKSk3mA6Eaw oEW0ikg0+weESaag2Ks/Z/AQYnjJwJ4DQsqqmmVozevXWyY8iV7ynOoV/4SDbDIDRDCF 75BA85QtUB3UzeKS7XEj9/NiLA0Beg8dSjUyUXVfqlsiSy05+d1FJoWRBUyPeB+HGCvG dfcg==
X-Gm-Message-State: AN3rC/6IRNhvbCb3QJ39fETG6pTUWN+pD9G9aFtYJexlliPOzpY8fU90 2wX01PqhMMsYQQ2KPfWsG0Hha5hOs2Mx
X-Received: by 10.31.133.135 with SMTP id h129mr17325127vkd.55.1493922132595;  Thu, 04 May 2017 11:22:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.24.204 with HTTP; Thu, 4 May 2017 11:22:12 -0700 (PDT)
In-Reply-To: 
References:  <87mvc3iym3.fsf@hobgoblin.ariadne.com>  <6c99cbac-212e-dbc0-5328-57222e8547b7@nostrum.com>   
From: Yehoshua Gev 
Date: Thu, 4 May 2017 21:22:12 +0300
Message-ID: 
To: sipcore 
Content-Type: multipart/alternative; boundary=001a114123bc091950054eb6da71
Archived-At: 
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-name-addr-guidance
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 18:22:17 -0000

--001a114123bc091950054eb6da71
Content-Type: text/plain; charset=UTF-8

Hi Robert,

Yes, this is exactly what I was looking for.
I think that in my previous mail I tried to propose a text with similar
meaning, but your suggestion is much more strightforward.
One bit (actually not a new problem) - The term "header-parameters" is
never really defined. In other places "XXX header parameter" is used, but
only when referencing specific header. IMHO this term clear enough, but
nevertheless I raise this point.

Thanks,
Yehoshua

On Tue, May 2, 2017 at 1:57 AM, Paul Kyzivat 
wrote:

> Robert,
>
> Please see inline.
>
>
> On 5/1/17 3:22 PM, Robert Sparks wrote:
>
>> Hi Yehoshua -
>>
>> It was that last paragraph of the introduction to section 20 that I was
>> pointing to. The change made by this document doesn't take those
>> sentences away.
>>
>> I still don't agree that new normative text is the necessary (I actually
>> feel it's dangerous - it adds yet another opportunity for
>> misinterpretation).
>>
>> But I re-read the end of the introduction to section 20 with the changes
>> this document specifies applied to it, and I think I see an improvement
>> that might ease the discomfort you're feeling with it.
>>
>> Section 2 currently says this:
>>
>> 2. Updates to RFC3261
>>>
>>>    This text from the introduction to section 20 of [RFC3261]:
>>>
>>>      The Contact, From, and To header fields contain a URI.  If the URI
>>>      contains a comma, question mark or semicolon, the URI MUST be
>>>      enclosed in angle brackets (< and >).
>>>
>>>    is replaced with:
>>>
>>>      When constructing the value of any SIP header field whose grammar
>>>      allows choosing between name-addr and addr-spec, such as those
>>>      that use the form '(name-addr / addr-spec)', the "addr-spec" form
>>>      MUST NOT be used if its value would contain a comma, semicolon,
>>>      or question mark.
>>>
>>>      The header fields defined in this specification that allow this
>>>      choice are "To", "From", "Contact",  and "Reply-To".
>>>
>> We could change it to say this (being more explicit with what happens to
>> the rest of the paragraph being operated on).
>>
>> 2. Updates to RFC3261
>>>
>>>    This text from the introduction to section 20 of [RFC3261]:
>>>
>>>      The Contact, From, and To header fields contain a URI.  If the URI
>>>      contains a comma, question mark or semicolon, the URI MUST be
>>>      enclosed in angle brackets (< and >).  Any URI parameters are
>>>      contained within these brackets.  If the URI is not enclosed in
>>> angle
>>>      brackets, any semicolon-delimited parameters are header-parameters,
>>>      not URI parameters.
>>>
>>>
>>>    is replaced with:
>>>
>>>      When constructing the value of any SIP header field whose grammar
>>>      allows choosing between name-addr and addr-spec, such as those
>>>      that use the form '(name-addr / addr-spec)', the "addr-spec" form
>>>      MUST NOT be used if its value would contain a comma, semicolon,
>>>      or question mark.
>>>      When a URI appears in such a header field, any URI parameters are
>>>      contained within these brackets.  If the URI is not enclosed in
>>> angle
>>>      brackets, any semicolon-delimited parameters are header-parameters,
>>>      not URI parameters.
>>>      The header fields defined in this specification that allow this
>>>      choice are "To", "From", "Contact",  and "Reply-To".
>>>
>>
> What you are trying to do seems very good. But there is still trouble with
> the wording. The use of "these brackets" has no referent. How about this:
>
>    When a URI appears in such a header field, any URI parameters are
>    contained within angle brackets (< and >).  If the URI is not
>    enclosed in angle brackets, any semicolon-delimited parameters are
>    header-parameters, not URI parameters.
>
> (Or the first "are" above might be replaced by "MUST be".)
>
>         Thanks,
>         Paul
>
> Does that ease your concern?
>>
>> RjS
>>
>> On 4/18/17 2:42 AM, Yehoshua Gev wrote:
>>
>>> Hi Robert,
>>> Can you point me to the text on 3261 that has the disambiguation rule?
>>> I could only find it in the last paragraph of section 20, which only
>>> speaks about "Contact, From, and To".
>>> I believe the intention of this draft is to expand this paragraph to
>>> cover all other "problematic" headers,
>>> so it should also expand the disambiguation rule to the other headers.
>>> Thanks,
>>> Yehoshua
>>> On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks >> > wrote:
>>>
>>>     Hi Yehoshua -
>>>
>>>     On 3/30/17 5:57 AM, Yehoshua Gev wrote:
>>>
>>>>     On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley
>>>>     > wrote:
>>>>
>>>>         Yehoshua Gev >
>>>>
>>>>         writes: >> > The examples of: >> >    Refer-To:
>>>>         sip:123@host?Replaces=1111 >> >    Refer-To:
>>>>         sip:123@host;user=phone?Replaces=1111 > So, the interpreting
>>>>         the string "sip:123@host" as the addr-spec alone, > renders
>>>>         the > header non-parsable by the BNF of 3515. Yes... but if
>>>>         you're only considering the BNF, "sip:123@host?Replaces=1111"
>>>>         can be parsed as an addr-spec, so the header is valid (by the
>>>>         BNF alone).  (Actually, even "sip:123@host" can't be parsed
>>>>         as a name-addr, because it doesn't have "<...>".)
>>>>
>>>>     Ok. I see your point. So when parsing header like  "Refer-To:
>>>>     sip:123@host;user=phone", the BNF parser will give two possible
>>>>     interpretation, and the non-BNF restriction will rule out one of
>>>>     them. And for "Refer-To: sip:123@host?Replaces=1111", the BNF
>>>>     parser will give one possible interpretation, which will be ruled
>>>>     out by the restriction. I believe my first understanding was that
>>>>     the restriction is applied to addr-spec, disallowing it from
>>>>     having uri-parameters/headers. And if the restriction if applied
>>>>     after parsing the add-spec, prior to parsing the rest of the
>>>>     Refer-To header, it will make the header syntactically invalid.
>>>>     But I guess it's a philosophical question.
>>>>
>>>>
>>>>         > Given so, IMHO the disambiguation rule should be stated as
>>>>         a normative text. ... So, yes, the new disambiguation rule is
>>>>         stated as a normative text.
>>>>
>>>>     The normative text in the draft only considers the "construction"
>>>>     of the header,
>>>>     it doesn't handle parsing/interpretation of a "constructed" header.
>>>>     Specifically, a sentence like "If the URI is not enclosed in
>>>>     angle brackets,
>>>>     any semicolon-delimited parameters are header-parameters, not URI
>>>>     parameters" (from RFC 3261 section 20) is missing.
>>>>     I suggest adding a text like:
>>>>     "If the URI in such headers is not enclosed in angle brackets,
>>>>     any characters
>>>>     after a comma, a question mark, or a semicolon SHOULD NOT be
>>>>     parsed as
>>>>     part of the URI".
>>>>     Alternatively:
>>>>     "When a URI is part of addr-spec which is not part of name-addr,
>>>>     the addr-spec
>>>>     SHOULD NOT be parsed to include a comma, a question mark, or a
>>>>     semicolon".
>>>>
>>>     3261 does already say this. and there's no ambiguity to clear up -
>>>     we'd be restating it here, and restating things that are required
>>>     by a base specification is something we avoid.
>>>
>>>>     Thanks,
>>>>     Yehoshua
>>>>
>>>>     _______________________________________________
>>>>     sipcore mailing list
>>>>     sipcore@ietf.org 
>>>>     https://www.ietf.org/mailman/listinfo/sipcore
>>>>     
>>>>
>>>     _______________________________________________ sipcore mailing
>>>     list sipcore@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/sipcore
>>>     
>>>
>>>
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--001a114123bc091950054eb6da71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Robert,

Yes, this is exactly what I =
was looking for.
I think that in my previous mail I tried to prop=
ose a text with similar meaning, but your suggestion is much more strightfo=
rward.
One bit (actually not a new problem) - The term "head=
er-parameters" is never really defined. In other places "XXX head=
er parameter" is used, but only when referencing specific header. IMHO=
 this term clear enough, but nevertheless I raise this point.
Thanks,
Yehoshua

On Tue, May 2, 2017 at 1:57 AM, Paul Kyziv=
at <paul.kyzivat@comcast.net> wrote:
Robert,



Please see inline.




On 5/1/17 3:22 PM, Robert Sparks wrote:



Hi Yehoshua -



It was that last paragraph of the introduction to section 20 that I was

pointing to. The change made by this document doesn't take those

sentences away.



I still don't agree that new normative text is the necessary (I actuall=
y

feel it's dangerous - it adds yet another opportunity for

misinterpretation).



But I re-read the end of the introduction to section 20 with the changes
this document specifies applied to it, and I think I see an improvement

that might ease the discomfort you're feeling with it.



Section 2 currently says this:





2. Updates to RFC3261



=C2=A0 =C2=A0This text from the introduction to section 20 of [RFC3261]:


=C2=A0 =C2=A0 =C2=A0The Contact, From, and To header fields contain a URI.=
=C2=A0 If the URI

=C2=A0 =C2=A0 =C2=A0contains a comma, question mark or semicolon, the URI M=
UST be

=C2=A0 =C2=A0 =C2=A0enclosed in angle brackets (< and >).



=C2=A0 =C2=A0is replaced with:



=C2=A0 =C2=A0 =C2=A0When constructing the value of any SIP header field who=
se grammar

=C2=A0 =C2=A0 =C2=A0allows choosing between name-addr and addr-spec, such a=
s those

=C2=A0 =C2=A0 =C2=A0that use the form '(name-addr / addr-spec)', th=
e "addr-spec" form

=C2=A0 =C2=A0 =C2=A0MUST NOT be used if its value would contain a comma, se=
micolon,

=C2=A0 =C2=A0 =C2=A0or question mark.



=C2=A0 =C2=A0 =C2=A0The header fields defined in this specification that al=
low this

=C2=A0 =C2=A0 =C2=A0choice are "To", "From", "Cont=
act",=C2=A0 and "Reply-To".



We could change it to say this (being more explicit with what happens to
the rest of the paragraph being operated on).





2. Updates to RFC3261



=C2=A0 =C2=A0This text from the introduction to section 20 of [RFC3261]:


=C2=A0 =C2=A0 =C2=A0The Contact, From, and To header fields contain a URI.=
=C2=A0 If the URI

=C2=A0 =C2=A0 =C2=A0contains a comma, question mark or semicolon, the URI M=
UST be

=C2=A0 =C2=A0 =C2=A0enclosed in angle brackets (< and >).=C2=A0 Any U=
RI parameters are

=C2=A0 =C2=A0 =C2=A0contained within these brackets.=C2=A0 If the URI is no=
t enclosed in angle

=C2=A0 =C2=A0 =C2=A0brackets, any semicolon-delimited parameters are header=
-parameters,

=C2=A0 =C2=A0 =C2=A0not URI parameters.





=C2=A0 =C2=A0is replaced with:



=C2=A0 =C2=A0 =C2=A0When constructing the value of any SIP header field who=
se grammar

=C2=A0 =C2=A0 =C2=A0allows choosing between name-addr and addr-spec, such a=
s those

=C2=A0 =C2=A0 =C2=A0that use the form '(name-addr / addr-spec)', th=
e "addr-spec" form

=C2=A0 =C2=A0 =C2=A0MUST NOT be used if its value would contain a comma, se=
micolon,

=C2=A0 =C2=A0 =C2=A0or question mark.

=C2=A0 =C2=A0 =C2=A0When a URI appears in such a header field, any URI para=
meters are

=C2=A0 =C2=A0 =C2=A0contained within these brackets.=C2=A0 If the URI is no=
t enclosed in angle

=C2=A0 =C2=A0 =C2=A0brackets, any semicolon-delimited parameters are header=
-parameters,

=C2=A0 =C2=A0 =C2=A0not URI parameters.

=C2=A0 =C2=A0 =C2=A0The header fields defined in this specification that al=
low this

=C2=A0 =C2=A0 =C2=A0choice are "To", "From", "Cont=
act",=C2=A0 and "Reply-To".





What you are trying to do seems very good. But there is still trouble with =
the wording. The use of "these brackets" has no referent. How abo=
ut this:



=C2=A0 =C2=A0When a URI appears in such a header field, any URI parameters =
are

=C2=A0 =C2=A0contained within angle brackets (< and >).=C2=A0 If the =
URI is not

=C2=A0 =C2=A0enclosed in angle brackets, any semicolon-delimited parameters=
 are

=C2=A0 =C2=A0header-parameters, not URI parameters.



(Or the first "are" above might be replaced by "MUST be"=
;.)



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul





Does that ease your concern?



RjS



On 4/18/17 2:42 AM, Yehoshua Gev wrote:



Hi Robert,

Can you point me to the text on 3261 that has the disambiguation rule?

I could only find it in the last paragraph of section 20, which only

speaks about "Contact, From, and To".

I believe the intention of this draft is to expand this paragraph to

cover all other "problematic" headers,

so it should also expand the disambiguation rule to the other headers.

Thanks,

Yehoshua

On Fri, Apr 14, 2017 at 12:43 AM, Robert Sparks <rjsparks@nostrum.com

<mailto:rjspar=
ks@nostrum.com>> wrote:



=C2=A0 =C2=A0 Hi Yehoshua -



=C2=A0 =C2=A0 On 3/30/17 5:57 AM, Yehoshua Gev wrote:



=C2=A0 =C2=A0 On Thu, Mar 30, 2017 at 12:04 AM, Dale R. Worley

=C2=A0 =C2=A0 <w=
orley@ariadne.com <mailto:worley@ariadne.com>> wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yehoshua Gev <yoshigev@gmail.com <mailto:yoshigev@gmail.com>>


=C2=A0 =C2=A0 =C2=A0 =C2=A0 writes: >> > The examples of: >>=
 >=C2=A0 =C2=A0 Refer-To:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 sip:123@host?Replaces=3D1111 >> >=C2=
=A0 =C2=A0 Refer-To:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 sip:123@host;user=3Dphone?Replaces=3D1111 =
> So, the interpreting

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the string "sip:123@host" as the addr=
-spec alone, > renders

=C2=A0 =C2=A0 =C2=A0 =C2=A0 the > header non-parsable by the BNF of 3515=
. Yes... but if

=C2=A0 =C2=A0 =C2=A0 =C2=A0 you're only considering the BNF, "sip:=
123@host?Replaces=3D1111"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 can be parsed as an addr-spec, so the header is=
 valid (by the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 BNF alone).=C2=A0 (Actually, even "sip:123=
@host" can't be parsed

=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a name-addr, because it doesn't have &qu=
ot;<...>".)



=C2=A0 =C2=A0 Ok. I see your point. So when parsing header like=C2=A0 "=
;Refer-To:

=C2=A0 =C2=A0 sip:123@host;user=3Dphone", the BNF parser will give two=
 possible

=C2=A0 =C2=A0 interpretation, and the non-BNF restriction will rule out one=
 of

=C2=A0 =C2=A0 them. And for "Refer-To: sip:123@host?Replaces=3D1111&qu=
ot;, the BNF

=C2=A0 =C2=A0 parser will give one possible interpretation, which will be r=
uled

=C2=A0 =C2=A0 out by the restriction. I believe my first understanding was =
that

=C2=A0 =C2=A0 the restriction is applied to addr-spec, disallowing it from<=
br>
=C2=A0 =C2=A0 having uri-parameters/headers. And if the restriction if appl=
ied

=C2=A0 =C2=A0 after parsing the add-spec, prior to parsing the rest of the<=
br>
=C2=A0 =C2=A0 Refer-To header, it will make the header syntactically invali=
d.

=C2=A0 =C2=A0 But I guess it's a philosophical question.





=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Given so, IMHO the disambiguation rule sho=
uld be stated as

=C2=A0 =C2=A0 =C2=A0 =C2=A0 a normative text. ... So, yes, the new disambig=
uation rule is

=C2=A0 =C2=A0 =C2=A0 =C2=A0 stated as a normative text.



=C2=A0 =C2=A0 The normative text in the draft only considers the "cons=
truction"

=C2=A0 =C2=A0 of the header,

=C2=A0 =C2=A0 it doesn't handle parsing/interpretation of a "const=
ructed" header.

=C2=A0 =C2=A0 Specifically, a sentence like "If the URI is not enclose=
d in

=C2=A0 =C2=A0 angle brackets,

=C2=A0 =C2=A0 any semicolon-delimited parameters are header-parameters, not=
 URI

=C2=A0 =C2=A0 parameters" (from RFC 3261 section 20) is missing.

=C2=A0 =C2=A0 I suggest adding a text like:

=C2=A0 =C2=A0 "If the URI in such headers is not enclosed in angle bra=
ckets,

=C2=A0 =C2=A0 any characters

=C2=A0 =C2=A0 after a comma, a question mark, or a semicolon SHOULD NOT be<=
br>
=C2=A0 =C2=A0 parsed as

=C2=A0 =C2=A0 part of the URI".

=C2=A0 =C2=A0 Alternatively:

=C2=A0 =C2=A0 "When a URI is part of addr-spec which is not part of na=
me-addr,

=C2=A0 =C2=A0 the addr-spec

=C2=A0 =C2=A0 SHOULD NOT be parsed to include a comma, a question mark, or =
a

=C2=A0 =C2=A0 semicolon".



=C2=A0 =C2=A0 3261 does already say this. and there's no ambiguity to c=
lear up -

=C2=A0 =C2=A0 we'd be restating it here, and restating things that are =
required

=C2=A0 =C2=A0 by a base specification is something we avoid.



=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 Yehoshua



=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 sipcore mailing list

=C2=A0 =C2=A0 sipcore=
@ietf.org <mailto:sipcore@ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/sipcore

=C2=A0 =C2=A0 <https://www.ietf.org/mailman/lis=
tinfo/sipcore>



=C2=A0 =C2=A0 _______________________________________________ sipcore =
mailing

=C2=A0 =C2=A0 list si=
pcore@ietf.org <mailto:sipcore@ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf=
o/sipcore

=C2=A0 =C2=A0 <https://www.ietf.org/mailman/lis=
tinfo/sipcore>








_______________________________________________

sipcore mailing list

sipcore@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sipcore<=
br>






_______________________________________________

sipcore mailing list

sipcore@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sipcore<=
br>




--001a114123bc091950054eb6da71--


From nobody Thu May  4 15:47:49 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B271128B38; Thu,  4 May 2017 15:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.819
X-Spam-Level: 
X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 EpGWtmwwMYhe; Thu,  4 May 2017 15:47:46 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 48F8A1294E9; Thu,  4 May 2017 15:47:46 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v44Mljim007665 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 4 May 2017 17:47:45 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: SIPCORE , draft-ietf-sipcore-content-id@ietf.org
From: "A. Jean Mahoney" 
Message-ID: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>
Date: Thu, 4 May 2017 17:47:45 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 04 May 2017 22:47:47 -0000

As I was going through the draft for the doc shepherd writeup, I came 
across the following:

Major issues: None

Minor issues:

3.2: There should be a normative reference for RFC5234 for the ABNF. 
Also the Note should say that HCOLON is defined in 3261.

6.1: The IANA considerations needs a bit more guidance and needs to 
match the sub-registry column headings.

Old:

    [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this
    document when publishing]

       RFC Number:  RFC XXXX

       Header Field Name:  Content-ID

       Compact Form:  none

Suggested:

    The header field described in Section 3 has been registered in the
    "Header Fields" sub-registry of the "Session Initiation Protocol
    (SIP) Parameters" registry by adding a row with these values:

    [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this
    document when publishing]

       Header Name:  Content-ID

       compact:

       Reference:  RFCXXXX


Nits:

1.4.1 and 1.4.2, 1st paragraphs:

Old:                          then the UAC needs to include one
    content only in the INVITE request.  This content can be ...

Suggested:                   then the UAC needs to include only
    one body part in the INVITE request.  This body part can be ...


3.2 1st paragraph: Remove the "s" from "fields"

3.4.1 1st and 2nd paragraphs: s/which/that


Everything else checks out.

Thanks!

Jean


From nobody Fri May  5 00:13:27 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C827E12946E; Fri,  5 May 2017 00:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 0Cry2eWMefQb; Fri,  5 May 2017 00:13:24 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6ED12945A; Fri,  5 May 2017 00:13:22 -0700 (PDT)
X-AuditID: c1b4fb2d-eff839a00000196b-33-590c26104f53
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B7.5D.06507.F062C095; Fri,  5 May 2017 09:13:20 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Fri, 5 May 2017 09:13:18 +0200
From: Christer Holmberg 
To: "A. Jean Mahoney" , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
Thread-Topic: Doc Shepherd review of draft-ietf-sipcore-content-id-03
Thread-Index: AQHSxSh1q98Q1cEUIUSox0v4i3K6ZqHlZgAA
Date: Fri, 5 May 2017 07:13:18 +0000
Message-ID: 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>
In-Reply-To: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.20]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <837221E36FF4104DA66EC347AD74DA33@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyM2K7ma6AGk+kwdm/Ihanv85gsmjoXMlq 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2PFr5SCDt6KO1vPszYw7uDsYuTg kBAwkVhwxb6LkYtDSOAIo8S7m6fZIZzFjBLPWlvYQYrYBCwkuv9pg8RFBOYxSmy9/Zmli5GT Q1jARWLmoQ52EFtEwFXiett9ZgjbSOLdyUlgNSwCKhJ9f3+xgti8AtYSt2/OYgKxhQTsJKY9 X8UIYnMK2Essuj0ZrJ5RQEzi+6k1YDXMAuISt57MB7MlBAQkluw5zwxhi0q8fPwPbKaogJ7E vn9f2SDiihJXpy+H6tWRWLD7ExvI/cxAe38tF4IIa0ssW/iaGeIcQYmTM5+wTGAUm4Vk2ywk 3bMQumch6Z6FpHsBI+sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDYOrjlt+4OxtWvHQ8x CnAwKvHwKuRwRwqxJpYVV+YeYpTgYFYS4eWX4YkU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuuw 70KEkEB6YklqdmpqQWoRTJaJg1OqgbHj8F2TH1sv/snI0CmTWjvlnkDjZ6v7npNO7p11w0tT I3hWx1XXdcpSTdqcHnIsS8KTo65uu+PhdOxVsdBlt7fXt/bs0T+QW/hjasTNjz0hbkG3H6bP 6cutq/zEznAwzaamtX3VmxiB5G3zQyu2za7paLKoiV315m2jjafq7DUxefn3hfxFNyixFGck GmoxFxUnAgA83NDJqQIAAA==
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 07:13:26 -0000

Hi Jean,

Thank You for the review! Please see inline.

Minor issues:

>3.2: There should be a normative reference for RFC5234 for the ABNF.
>Also the Note should say that HCOLON is defined in 3261.

Will fix as suggested.

---

>6.1: The IANA considerations needs a bit more guidance and needs to
>match the sub-registry column headings.
>
>Old:
>
>    [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this
>    document when publishing]
>
>       RFC Number:  RFC XXXX
>
>       Header Field Name:  Content-ID
>
>       Compact Form:  none
>
>Suggested:
>
>    The header field described in Section 3 has been registered in the
>    "Header Fields" sub-registry of the "Session Initiation Protocol
>    (SIP) Parameters" registry by adding a row with these values:
>
>    [RFC EDITOR NOTE: Please replace XXXX with the RFC number of this
>    document when publishing]
>
>       Header Name:  Content-ID
>
>       compact:
>
>       Reference:  RFCXXXX

Will fix as suggested.

---

Nits:

>1.4.1 and 1.4.2, 1st paragraphs:
>
>Old:                          then the UAC needs to include one
>    content only in the INVITE request.  This content can be ...
>
>Suggested:                   then the UAC needs to include only
>    one body part in the INVITE request.  This body part can be ...

Will fix as suggested.

>3.2 1st paragraph: Remove the "s" from "fields"

Will fix as suggested.


>3.4.1 1st and 2nd paragraphs: s/which/that

Will fix as suggested.

I have created a pull request with the changes:

https://github.com/cdh4u/draft-content-id/pull/5


Regards,

Christer


From nobody Fri May  5 00:59:31 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822E9127097; Fri,  5 May 2017 00:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 JQASuC2ZURCV; Fri,  5 May 2017 00:59:26 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3492812943D; Fri,  5 May 2017 00:59:25 -0700 (PDT)
X-AuditID: c1b4fb2d-b25ff7000000196b-10-590c30dab4f9
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C9.F7.06507.AD03C095; Fri,  5 May 2017 09:59:23 +0200 (CEST)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 5 May 2017 09:59:21 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uVjtUNNH6mOHmFOYxxs3vdjtSFLAJoXYuucll1EHnY0=; b=RZSrXDGIPUxYUqt3IsD7xXiUJaU8yYRlj3TxJ+lqYqw8HUrTUn5UFWDa/RExPKKNI0chjlWN2N2lFek0VX0dit3PtNeksaZFTS6uklJFn6zG2yy1XNm4NUNIG86dSb9uFat3ZHPk8fA3np37TwOiKhKJt2b6p569aJzFsKJRyjg=
Received: from DB6PR0701MB2469.eurprd07.prod.outlook.com (10.168.75.150) by DB6PR0701MB2470.eurprd07.prod.outlook.com (10.168.75.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 07:59:20 +0000
Received: from DB6PR0701MB2469.eurprd07.prod.outlook.com ([10.168.75.150]) by DB6PR0701MB2469.eurprd07.prod.outlook.com ([10.168.75.150]) with mapi id 15.01.1084.007; Fri, 5 May 2017 07:59:20 +0000
From: Ivo Sedlacek 
To: Christer Holmberg , "A. Jean Mahoney" , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
Thread-Topic: Doc Shepherd review of draft-ietf-sipcore-content-id-03
Thread-Index: AQHSxW8r8GV/d8lk2023/1L2U7AA76HlXHGQ
Date: Fri, 5 May 2017 07:59:20 +0000
Message-ID: 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [193.179.210.162]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2470; 7:tMQ7p1AMsp63J4rq+ogsErWnPywH9vdLAmIYBjFZxm66haYBQGqWI3JjhWcyVjBga8Nk8SmCbMtMr/On0D4Ysspe16GZH4wmsJfSASMN5MWuC7UDsXa/gYDpYDSz1KzzgcHLJtu1/DJ09qJgqJPCqLRm/1ec9Do/qWqY01uPzDFh7HRBiRAt6eQOWdSwfjD6VXEJHSAVtOAMr/nO3HzFVeywx01VVEUGj5qiveq6vUEyey9XQLh8FpF3UU0TyzvRFvzGjE+Lx/pgMYDq0kVwSxGAG97nxQem3zZLy4ubtkgEOeK5ujWrdjej4zxjP3APDGpdKz2c3/I1jdHRcB8tWA==
x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr
x-ms-office365-filtering-correlation-id: 0819d9a2-d58d-44b0-a33a-08d4938ca32f
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DB6PR0701MB2470; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148); SRVR:DB6PR0701MB2470; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2470; 
x-forefront-prvs: 02981BE340
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39840400002)(39450400003)(39400400002)(39410400002)(39850400002)(39860400002)(66066001)(189998001)(2900100001)(38730400002)(7696004)(86362001)(76176999)(54356999)(6246003)(50986999)(9686003)(8676002)(8936002)(5660300001)(81166006)(33656002)(2501003)(25786009)(122556002)(74316002)(305945005)(7736002)(3846002)(102836003)(6116002)(99286003)(55016002)(77096006)(3660700001)(3280700002)(2906002)(6436002)(2950100002)(6506006)(53936002)(230783001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2470; H:DB6PR0701MB2469.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 07:59:20.6473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2470
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRiGec85W8fp6HVu+rCMYgqJ5TKLGDFCTcGIvvwRzj858qDi3GRn fhYhWZqONE1oCuWk+ZEzBVmopYOpkFqQqKVuVIQrEq3QWqXS19lZ0L/rfe8LnueGhyYl1QI5 nac3MUa9VqcQiqjmjIHkOE98iCZ+uEameuqzEKqKmvsCle9HvzCRTLPZNoi0liEvdYbIFKmz GV1eMWPcfzRLlNv6sp0otGwr7fDYhRWoR1CLgmjAh+DF6hVhLRLREjyOwGpfCDyeIOi1dRCc ReEbJDSsYY4luJmAOy7MS5MI3J11fkmIldDgGBdwgRTPIbj2fmRbLaLpMJwC5rYjnCPFqTBf 9YbkOQFW+yYE/IBomOodQZwuxlnQ3lnOoQQXgtcZwxlBWA2frEv+SQiHw/epHj+TOALc3laC L4PBNvyc5FkGy0u//NsgfAtB/fBdIR9EgaPxc0DaCTOtZsRzHQkzThXParCYbweck+B2ck04 rkCwMJjFswGaBiyB/1i4Pt4SWOIbAfW+Ap4jYajb418C8BYFm13z/r5hWA6v5mrQTRTb8l8J nveB9fG6kOe90NG2QnIsxqEw2eylrIjqRjKWYdmCnISDSsaYd4FlDXqlnjH1o7/n4XJsxQ0i +0rSKMI0UoSId+uCNRKBtpgtKxhFQJMKqXh7ZIhGIs7WlpUzRsN5Y5GOYUfRDppSRIgTndMZ EpyjNTH5DFPIGP+lBB0kr0DayqhLy8emLarXTYfPfSlKycy1v0v97dhMf/TT6ZN+tTijHrIT rpK1UzhRcBxONDuiFzWzUuqi8UPwWXX9RnpCTN/loj2lhrlNZWm1q7JKTrZ3ukzPZuvG8pM2 y6/KxAMPvEONU29DT28tJpeE7HLew2Pr825PX3jEWtdHs01BsbnaA7GkkdX+AQQ7+AsaAwAA
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 07:59:29 -0000

Hello,

regarding:

>1.4.1 and 1.4.2, 1st paragraphs:
>
>Old:                          then the UAC needs to include one
>    content only in the INVITE request.  This content can be ...
>
>Suggested:                   then the UAC needs to include only
>    one body part in the INVITE request.  This body part can be ...

IMO, the above changes the semantic of the sentence.

According to RFC2045, the term "body part" refers to an entity **inside of =
a multipart entity**.

The original text above allowed for the content to be included either using=
 multipart message-body or using non-multipart message-body, in the INVITE =
request .
The new text above indicates that  the content needs to be included using m=
ultipart message-body in the INVITE request.

So, I would rather stick to "content", or perhaps replaces "content" with "=
entity" or "MIME entity".

Kind regards

Ivo



From nobody Fri May  5 06:14:58 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC62126C83; Fri,  5 May 2017 06:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.819
X-Spam-Level: 
X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 lHVqXKHyPvKY; Fri,  5 May 2017 06:14:55 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0E58B126B6E; Fri,  5 May 2017 06:14:55 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v45DEoSR098271 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 5 May 2017 08:14:50 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: Ivo Sedlacek , Christer Holmberg , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>  
From: "A. Jean Mahoney" 
Message-ID: <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com>
Date: Fri, 5 May 2017 08:14:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 13:14:56 -0000

Hi Ivo,

On 5/5/17 2:59 AM, Ivo Sedlacek wrote:
> Hello,
> 
> regarding:
> 
>> 1.4.1 and 1.4.2, 1st paragraphs:
>> 
>> Old:                          then the UAC needs to include one 
>> content only in the INVITE request.  This content can be ...
>> 
>> Suggested:                   then the UAC needs to include only one
>> body part in the INVITE request.  This body part can be ...
> 
> IMO, the above changes the semantic of the sentence.
> 
> According to RFC2045, the term "body part" refers to an entity
> **inside of a multipart entity**.
> 
> The original text above allowed for the content to be included either
> using multipart message-body or using non-multipart message-body, in
> the INVITE request . The new text above indicates that  the content
> needs to be included using multipart message-body in the INVITE
> request.
> 
> So, I would rather stick to "content", or perhaps replaces "content"
> with "entity" or "MIME entity".

I like "MIME entity".

Thanks!

Jean

> 
> Kind regards
> 
> Ivo
> 
> 


From nobody Fri May  5 06:48:20 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3640129420; Fri,  5 May 2017 06:48:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 ek-cN69ORN24; Fri,  5 May 2017 06:48:16 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC87126B6E; Fri,  5 May 2017 06:48:15 -0700 (PDT)
X-AuditID: c1b4fb30-29dff7000000015f-cb-590c829df195
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.52.00351.D928C095; Fri,  5 May 2017 15:48:14 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0339.000; Fri, 5 May 2017 15:48:13 +0200
From: Christer Holmberg 
To: "A. Jean Mahoney" , Ivo Sedlacek , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
Thread-Topic: Doc Shepherd review of draft-ietf-sipcore-content-id-03
Thread-Index: AQHSxSh1q98Q1cEUIUSox0v4i3K6ZqHlZgAA///ZKACAAFglgIAAPQqA
Date: Fri, 5 May 2017 13:48:11 +0000
Message-ID: 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>   <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com>
In-Reply-To: <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.17]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <19BCEDD5AFBB184ABA95D72D5507227B@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7je68Jp5Ig+VPBCxOf53BZNHQuZLV 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8bBNa2sBS1cFW/3L2JqYDzP3sXI wSEhYCKxe69LFyMXh5DAEUaJvtnnWCCcxYwSEzpOMIIUsQlYSHT/0waJiwicYpTYO6OLrYuR k0NYwEVi5qEOdhBbRMBV4nrbfWaQehEBN4mbz+VBTBYBFYnT02pAKngFrCWOL3kENf4Po8S/ G5uYQBKcAvYSf3/8ZQSxGQXEJL6fWgMWZxYQl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wgtqiA nsS+f1/ZIH5RlFjeLwfRqiOxYPcnNgjbWuJl/29GCFtbYtnC18wQ9whKnJz5hGUCo9gsJNtm IWmfhaR9FpL2WUjaFzCyrmIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQIjK6DW34b7GB8+dzx EKMAB6MSD69CDnekEGtiWXFl7iFGCQ5mJRHe1HKeSCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 jvsuRAgJpCeWpGanphakFsFkmTg4pRoY5Xi+uUnM0p1ZIrzq4zbPc5t1FIrWNC89f56F61RO Tji/vfOZlGPqFbMtuA/9zMjbUeGg/rP0kgvHE6eI46dVuPT/pqYve79MM/1s21IPf++vpSv+ TdI7xSEa+Z1pafLe7ydefWoTC1/fmP7vgKn0R98fi4/NllI261uXeDGu68fnwOd2ZdWVSizF GYmGWsxFxYkA36vwiKoCAAA=
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 05 May 2017 13:48:19 -0000

Hi,

Pull request updated, with s/body part/MIME entity

Regards,

Christer


On 05/05/17 16:14, "A. Jean Mahoney"  wrote:

>Hi Ivo,
>
>On 5/5/17 2:59 AM, Ivo Sedlacek wrote:
>> Hello,
>>=20
>> regarding:
>>=20
>>> 1.4.1 and 1.4.2, 1st paragraphs:
>>>=20
>>> Old:                          then the UAC needs to include one
>>> content only in the INVITE request.  This content can be ...
>>>=20
>>> Suggested:                   then the UAC needs to include only one
>>> body part in the INVITE request.  This body part can be ...
>>=20
>> IMO, the above changes the semantic of the sentence.
>>=20
>> According to RFC2045, the term "body part" refers to an entity
>> **inside of a multipart entity**.
>>=20
>> The original text above allowed for the content to be included either
>> using multipart message-body or using non-multipart message-body, in
>> the INVITE request . The new text above indicates that  the content
>> needs to be included using multipart message-body in the INVITE
>> request.
>>=20
>> So, I would rather stick to "content", or perhaps replaces "content"
>> with "entity" or "MIME entity".
>
>I like "MIME entity".
>
>Thanks!
>
>Jean
>
>>=20
>> Kind regards
>>=20
>> Ivo
>>=20
>>=20


From nobody Mon May  8 11:26:36 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF5129568; Mon,  8 May 2017 11:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.819
X-Spam-Level: 
X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 jeQf3keTih6L; Mon,  8 May 2017 11:26:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3C753129564; Mon,  8 May 2017 11:26:33 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v48IQTeP009743 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 May 2017 13:26:29 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: Christer Holmberg , Ivo Sedlacek , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>   <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com> 
From: "A. Jean Mahoney" 
Message-ID: 
Date: Mon, 8 May 2017 13:26:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 18:26:34 -0000

Hi Christer,

Thanks for making the changes!

Jean

On 5/5/17 8:48 AM, Christer Holmberg wrote:
> Hi,
> 
> Pull request updated, with s/body part/MIME entity
> 
> Regards,
> 
> Christer
> 
> 
> On 05/05/17 16:14, "A. Jean Mahoney"  wrote:
> 
>> Hi Ivo,
>>
>> On 5/5/17 2:59 AM, Ivo Sedlacek wrote:
>>> Hello,
>>>
>>> regarding:
>>>
>>>> 1.4.1 and 1.4.2, 1st paragraphs:
>>>>
>>>> Old:                          then the UAC needs to include one
>>>> content only in the INVITE request.  This content can be ...
>>>>
>>>> Suggested:                   then the UAC needs to include only one
>>>> body part in the INVITE request.  This body part can be ...
>>>
>>> IMO, the above changes the semantic of the sentence.
>>>
>>> According to RFC2045, the term "body part" refers to an entity
>>> **inside of a multipart entity**.
>>>
>>> The original text above allowed for the content to be included either
>>> using multipart message-body or using non-multipart message-body, in
>>> the INVITE request . The new text above indicates that  the content
>>> needs to be included using multipart message-body in the INVITE
>>> request.
>>>
>>> So, I would rather stick to "content", or perhaps replaces "content"
>>> with "entity" or "MIME entity".
>>
>> I like "MIME entity".
>>
>> Thanks!
>>
>> Jean
>>
>>>
>>> Kind regards
>>>
>>> Ivo
>>>
>>>
> 


From nobody Mon May  8 11:34:29 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28747129568 for ; Mon,  8 May 2017 11:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 SOwDjqDvqhGC for ; Mon,  8 May 2017 11:34:26 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 AFDD4128B90 for ; Mon,  8 May 2017 11:34:25 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id e55so49877010uaa.2 for ; Mon, 08 May 2017 11:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to;  bh=3GFBulG4LYa1483N356GcbKMuGM7Lw/ee/7YMb3F3FM=; b=nbpYUd/CW9PARdrokRLGUG7KslPnPn9WXK6K12olYA+XRJs7HNLtMcCtDDpEq1WKCL F/OLr6OBG457fceHxGmqqF+IfNZXnGGODoUFa+BFcOTdPJrRIleouJ3qwkue50iAw59I OPaCTCvahC17+7BNVzwqO4GpotaLqjVFk7FlHg2O/C9zOHe8DthdFXmCoEFOexrBfRhu s84DmFZo3S2GVr+BYbj+aRhVXqehQg4/EIJlYXgGgFRXHyXDi8WXU7Q4Sc952Zf28caL a1fqh6VIHyr6bktVMkr9/TgEtuwq9WEjeHm0AXWchSBQTE/UXXu2/LbVn8xKXQwlpAet 4zzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3GFBulG4LYa1483N356GcbKMuGM7Lw/ee/7YMb3F3FM=; b=GZpGAv00HGEGZi7l2xZVUjelp1tKUERhPdpd9cEFDUMecmAVu5+BZ58Ylo6EcqAIgn TQEDZwdG5GvV8UoEUo4RtvzvS5a5L/+VTglWzKO3qDhdQSFs6579KiJ5cr83KB/YYeg1 kbQw6xvR8U5o+K39LGlYxC/UtWJEfG/eRaXb2W2qK2cboeaMBs04DBlqC2QbANTZ52RJ aO25mv0cGj913tErCEuHYe2U2t9bD3KMtz2Cc6T+p+TX7t2QrP1McYBjGfSnuhXbgE5U PTh9DMsaY3YQ8o9ShWXjMMMRd8fw9P/QcZRuw55MYIKX5jBN64j5Zeh5AlwJb3dHnwtH 3nXA==
X-Gm-Message-State: AODbwcD9VwcV8j4fB+9WikLdIk8nf3FVOqx9+R13cGw6szIsjCL7VBLT tABTZ6DzH1l0MgtPkwVfx8ksPiOvcQ==
X-Received: by 10.31.168.137 with SMTP id r131mr189838vke.64.1494268464693; Mon, 08 May 2017 11:34:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.76.91 with HTTP; Mon, 8 May 2017 11:34:24 -0700 (PDT)
In-Reply-To: 
References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com>    
From: Rifaat Shekh-Yusef 
Date: Mon, 8 May 2017 14:34:24 -0400
Message-ID: 
To: SIPCORE 
Content-Type: multipart/alternative; boundary=001a11426c7c0a2184054f077df2
Archived-At: 
Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 18:34:28 -0000

--001a11426c7c0a2184054f077df2
Content-Type: text/plain; charset=UTF-8

Hi Jean,

I did not see any objection by anybody for the WG adopting this document.
What is next?

Regards,


On Fri, Apr 7, 2017 at 5:17 PM, Andrew Allen  wrote:

> I indicated support in Chicago but also add it again here
>
> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren,
> Tolga
> Sent: Friday, April 7, 2017 6:34 AM
> To: SIPCORE 
> Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
>
> I also support adoption of this draft as a WG item and willing to
> review/contribute.
>
> Thanks,
> Tolga
>
> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY,
> MARTIN C
> Sent: Thursday, April 6, 2017 5:24 PM
> To: Ivo Sedlacek ; A. Jean Mahoney <
> mahoney@nostrum.com>; SIPCORE 
> Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
>
> +1
>
> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek
> Sent: Thursday, April 06, 2017 5:22 PM
> To: A. Jean Mahoney ; SIPCORE 
> Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
>
> I support adoption of this draft.
>
> Kind regards
>
> Ivo
>
> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean
> Mahoney
> Sent: Thursday, April 06, 2017 12:09 PM
> To: SIPCORE 
> Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
>
> Hi all,
>
> During the WG session in Chicago, Rifaat presented this draft, and the
> chairs took a hum on whether the WG should take on this draft as a WG item.
>
> There was consensus at the meeting to take this draft on. Now I'm gauging
> interest on the mailing list. Please let the list know if you have any
> objections to taking this work on.
>
> Thanks!
>
> Jean
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=
> G9v8uCSSQhCmpw7ItG0r2g&m=ck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=
> 4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=
> G9v8uCSSQhCmpw7ItG0r2g&m=ck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=
> 4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--001a11426c7c0a2184054f077df2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Jean,

I did not see any objection by=
 anybody for the WG adopting this document.
What is next?

Regards,


On Fri, Apr 7, 2017 at 5:17 PM, Andrew =
Allen <aallen@blackberry.com> wrote:
I indicated support in Chicago but also add it again here



-----Original Message-----

From: sipcore [mailto:sipcore-b=
ounces@ietf.org] On Behalf Of Asveren, Tolga

Sent: Friday, April 7, 2017 6:34 AM

To: SIPCORE <sipcore@ietf.org>=
;

Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?



I also support adoption of this draft as a WG item and willing to review/co=
ntribute.



Thanks,

Tolga



-----Original Message-----

From: sipcore [mailto:sipcore-b=
ounces@ietf.org] On Behalf Of DOLLY, MARTIN C

Sent: Thursday, April 6, 2017 5:24 PM

To: Ivo Sedlacek <ivo.sedla=
cek@ericsson.com>; A. Jean Mahoney <mahoney@nostrum.com>; SIPCORE <sipcore@ietf.org>

Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?



+1



-----Original Message-----

From: sipcore [mailto:sipcore-b=
ounces@ietf.org] On Behalf Of Ivo Sedlacek

Sent: Thursday, April 06, 2017 5:22 PM

To: A. Jean Mahoney <mahoney@nost=
rum.com>; SIPCORE <sipcore@ie=
tf.org>

Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?



I support adoption of this draft.



Kind regards



Ivo



-----Original Message-----

From: sipcore [mailto:sipcore-b=
ounces@ietf.org] On Behalf Of A. Jean Mahoney

Sent: Thursday, April 06, 2017 12:09 PM

To: SIPCORE <sipcore@ietf.org>=
;

Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item?



Hi all,



During the WG session in Chicago, Rifaat presented this draft, and the chai=
rs took a hum on whether the WG should take on this draft as a WG item.



There was consensus at the meeting to take this draft on. Now I'm gaugi=
ng interest on the mailing list. Please let the list know if you have any o=
bjections to taking this work on.



Thanks!



Jean



_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://urldefense.proofpoint.com/v2=
/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_sipcore&d=3D=
DwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0=
r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D<=
wbr>4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=3D



_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://urldefense.proofpoint.com/v2=
/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_sipcore&d=3D=
DwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7ItG0=
r2g&m=3Dck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=3D<=
wbr>4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=3D



_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org/mailman/listinfo/sipcore<=
br>


_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org/mailman/listinfo/sipcore<=
br>


_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org/mailman/listinfo/sipcore<=
br>




--001a11426c7c0a2184054f077df2--


From nobody Mon May  8 12:19:19 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C79291243F6; Mon,  8 May 2017 12:19:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149427115179.31652.18229906332628403907@ietfa.amsl.com>
Date: Mon, 08 May 2017 12:19:11 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-04.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 19:19:12 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : Content-ID header field in Session Initiation Protocol (SIP)
        Authors         : Christer Holmberg
                          Ivo Sedlacek
	Filename        : draft-ietf-sipcore-content-id-04.txt
	Pages           : 9
	Date            : 2017-05-08

Abstract:
   This document specifies the Content-ID header field for usage in the
   Session Initiation Protocol (SIP).  The document also updates RFC
   5621, to enable a Content-ID URL to reference a complete message-body
   and metadata provided by some additional SIP header fields.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-content-id-04
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon May  8 12:20:13 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C7C1296C9; Mon,  8 May 2017 12:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 FHgmy_o1attj; Mon,  8 May 2017 12:20:11 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA491296B3; Mon,  8 May 2017 12:20:10 -0700 (PDT)
X-AuditID: c1b4fb30-663149a00000015f-5f-5910c4e890e3
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9A.95.00351.8E4C0195; Mon,  8 May 2017 21:20:09 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Mon, 8 May 2017 21:20:07 +0200
From: Christer Holmberg 
To: "A. Jean Mahoney" , Ivo Sedlacek , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
Thread-Topic: Doc Shepherd review of draft-ietf-sipcore-content-id-03
Thread-Index: AQHSxSh1q98Q1cEUIUSox0v4i3K6ZqHlZgAA///ZKACAAFglgIAAPQqAgATRBwCAADBw8A==
Date: Mon, 8 May 2017 19:20:07 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB98530@ESESSMB109.ericsson.se>
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>   <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7me7LIwKRBhvOsVic/jqDyaKhcyWr xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsErowff24xF3wSrtg68TBzA+MG4S5G Tg4JAROJ9qmfGLsYuTiEBI4wSmzfvYwJwlnMKLHh03v2LkYODjYBC4nuf9ogcRGBU4wSe2d0 sYHEhQVcJLoXWoEMEhFwlbjedp8Zwg6TeH5lAyOIzSKgIrHsz252EJtXwFfiyJ01LCC2kMBj JolN92NAbE4Be4knVzaB1TMKiEl8P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmEr STQuecIKcg6zgKbE+l36EK2KElO6H0KtFZQ4OfMJywRGkVlIps5C6JiFpGMWko4FjCyrGEWL U4uTctONjPRSizKTi4vz8/TyUks2MQKj4uCW3wY7GF8+dzzEKMDBqMTD+6BSIFKINbGsuDL3 EKMEB7OSCG/ALqAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwc nFINjPnnhLmcpk3mEag+75omtVU8YE/KIYdGpoCFb6TOiW3wf5jBn180ObV/y47e1Od9HnV3 q28lxjudPuYhfq44dqvqjwPyM9rPhPOynV4kcK7uiYKB2VRN09bvSSFCXW/1s7XtXS8F37wl YfdhksL71q2v5KZYnjBKvmRmqLLYQT9O3/2fd0izEktxRqKhFnNRcSIAUDQpJoYCAAA=
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 19:20:13 -0000

SGksDQoNCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gKC0wNCksIHdpdGggdGhlIGNoYW5n
ZXMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQpGcm9tOiBBLiBKZWFuIE1haG9uZXkgW21haWx0bzptYWhvbmV5QG5vc3RydW0uY29tXSANClNl
bnQ6IDA4IE1heSAyMDE3IDIwOjI2DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbT47IEl2byBTZWRsYWNlayA8aXZvLnNlZGxhY2VrQGVyaWNzc29u
LmNvbT47IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLXNpcGNvcmUtY29u
dGVudC1pZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IERvYyBTaGVwaGVyZCByZXZpZXcgb2YgZHJh
ZnQtaWV0Zi1zaXBjb3JlLWNvbnRlbnQtaWQtMDMNCg0KSGkgQ2hyaXN0ZXIsDQoNClRoYW5rcyBm
b3IgbWFraW5nIHRoZSBjaGFuZ2VzIQ0KDQpKZWFuDQoNCk9uIDUvNS8xNyA4OjQ4IEFNLCBDaHJp
c3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGksDQo+IA0KPiBQdWxsIHJlcXVlc3QgdXBkYXRlZCwg
d2l0aCBzL2JvZHkgcGFydC9NSU1FIGVudGl0eQ0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlz
dGVyDQo+IA0KPiANCj4gT24gMDUvMDUvMTcgMTY6MTQsICJBLiBKZWFuIE1haG9uZXkiIDxtYWhv
bmV5QG5vc3RydW0uY29tPiB3cm90ZToNCj4gDQo+PiBIaSBJdm8sDQo+Pg0KPj4gT24gNS81LzE3
IDI6NTkgQU0sIEl2byBTZWRsYWNlayB3cm90ZToNCj4+PiBIZWxsbywNCj4+Pg0KPj4+IHJlZ2Fy
ZGluZzoNCj4+Pg0KPj4+PiAxLjQuMSBhbmQgMS40LjIsIDFzdCBwYXJhZ3JhcGhzOg0KPj4+Pg0K
Pj4+PiBPbGQ6ICAgICAgICAgICAgICAgICAgICAgICAgICB0aGVuIHRoZSBVQUMgbmVlZHMgdG8g
aW5jbHVkZSBvbmUNCj4+Pj4gY29udGVudCBvbmx5IGluIHRoZSBJTlZJVEUgcmVxdWVzdC4gIFRo
aXMgY29udGVudCBjYW4gYmUgLi4uDQo+Pj4+DQo+Pj4+IFN1Z2dlc3RlZDogICAgICAgICAgICAg
ICAgICAgdGhlbiB0aGUgVUFDIG5lZWRzIHRvIGluY2x1ZGUgb25seSBvbmUNCj4+Pj4gYm9keSBw
YXJ0IGluIHRoZSBJTlZJVEUgcmVxdWVzdC4gIFRoaXMgYm9keSBwYXJ0IGNhbiBiZSAuLi4NCj4+
Pg0KPj4+IElNTywgdGhlIGFib3ZlIGNoYW5nZXMgdGhlIHNlbWFudGljIG9mIHRoZSBzZW50ZW5j
ZS4NCj4+Pg0KPj4+IEFjY29yZGluZyB0byBSRkMyMDQ1LCB0aGUgdGVybSAiYm9keSBwYXJ0IiBy
ZWZlcnMgdG8gYW4gZW50aXR5IA0KPj4+ICoqaW5zaWRlIG9mIGEgbXVsdGlwYXJ0IGVudGl0eSoq
Lg0KPj4+DQo+Pj4gVGhlIG9yaWdpbmFsIHRleHQgYWJvdmUgYWxsb3dlZCBmb3IgdGhlIGNvbnRl
bnQgdG8gYmUgaW5jbHVkZWQgDQo+Pj4gZWl0aGVyIHVzaW5nIG11bHRpcGFydCBtZXNzYWdlLWJv
ZHkgb3IgdXNpbmcgbm9uLW11bHRpcGFydCANCj4+PiBtZXNzYWdlLWJvZHksIGluIHRoZSBJTlZJ
VEUgcmVxdWVzdCAuIFRoZSBuZXcgdGV4dCBhYm92ZSBpbmRpY2F0ZXMgDQo+Pj4gdGhhdCAgdGhl
IGNvbnRlbnQgbmVlZHMgdG8gYmUgaW5jbHVkZWQgdXNpbmcgbXVsdGlwYXJ0IG1lc3NhZ2UtYm9k
eSANCj4+PiBpbiB0aGUgSU5WSVRFIHJlcXVlc3QuDQo+Pj4NCj4+PiBTbywgSSB3b3VsZCByYXRo
ZXIgc3RpY2sgdG8gImNvbnRlbnQiLCBvciBwZXJoYXBzIHJlcGxhY2VzICJjb250ZW50Ig0KPj4+
IHdpdGggImVudGl0eSIgb3IgIk1JTUUgZW50aXR5Ii4NCj4+DQo+PiBJIGxpa2UgIk1JTUUgZW50
aXR5Ii4NCj4+DQo+PiBUaGFua3MhDQo+Pg0KPj4gSmVhbg0KPj4NCj4+Pg0KPj4+IEtpbmQgcmVn
YXJkcw0KPj4+DQo+Pj4gSXZvDQo+Pj4NCj4+Pg0KPiANCg==


From nobody Mon May  8 13:10:45 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BD8127698 for ; Mon,  8 May 2017 13:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 MGNk3Y5PfY4A for ; Mon,  8 May 2017 13:10:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2602A1200C5 for ; Mon,  8 May 2017 13:10:42 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v48KAep4020718 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 May 2017 15:10:40 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: Rifaat Shekh-Yusef , SIPCORE 
References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com>     
From: "A. Jean Mahoney" 
Message-ID: <18bd7379-bf41-4835-c1b5-722159705bd9@nostrum.com>
Date: Mon, 8 May 2017 15:10:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 08 May 2017 20:10:44 -0000

Hi Rifaat,

It's in the co-chairs' court. Brian and I need to talk about this and 
the other drafts. You'll hear from us soon.

Thanks!

Jean

On 5/8/17 1:34 PM, Rifaat Shekh-Yusef wrote:
> Hi Jean,
> 
> I did not see any objection by anybody for the WG adopting this document.
> What is next?
> 
> Regards,
> 
> 
> On Fri, Apr 7, 2017 at 5:17 PM, Andrew Allen  > wrote:
> 
>     I indicated support in Chicago but also add it again here
> 
>     -----Original Message-----
>     From: sipcore [mailto:sipcore-bounces@ietf.org
>     ] On Behalf Of Asveren, Tolga
>     Sent: Friday, April 7, 2017 6:34 AM
>     To: SIPCORE >
>     Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
> 
>     I also support adoption of this draft as a WG item and willing to
>     review/contribute.
> 
>     Thanks,
>     Tolga
> 
>     -----Original Message-----
>     From: sipcore [mailto:sipcore-bounces@ietf.org
>     ] On Behalf Of DOLLY, MARTIN C
>     Sent: Thursday, April 6, 2017 5:24 PM
>     To: Ivo Sedlacek      >; A. Jean Mahoney
>     >; SIPCORE
>     >
>     Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
> 
>     +1
> 
>     -----Original Message-----
>     From: sipcore [mailto:sipcore-bounces@ietf.org
>     ] On Behalf Of Ivo Sedlacek
>     Sent: Thursday, April 06, 2017 5:22 PM
>     To: A. Jean Mahoney      >; SIPCORE      >
>     Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
> 
>     I support adoption of this draft.
> 
>     Kind regards
> 
>     Ivo
> 
>     -----Original Message-----
>     From: sipcore [mailto:sipcore-bounces@ietf.org
>     ] On Behalf Of A. Jean Mahoney
>     Sent: Thursday, April 06, 2017 12:09 PM
>     To: SIPCORE >
>     Subject: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
> 
>     Hi all,
> 
>     During the WG session in Chicago, Rifaat presented this draft, and
>     the chairs took a hum on whether the WG should take on this draft as
>     a WG item.
> 
>     There was consensus at the meeting to take this draft on. Now I'm
>     gauging interest on the mailing list. Please let the list know if
>     you have any objections to taking this work on.
> 
>     Thanks!
> 
>     Jean
> 
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org 
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=ck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=
>     
> 
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org 
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=ck-1qeAMpbzYFf5UBvoFKj98k9MTJHJGX_DeD1jDwpg&s=4AZmdhGRJRfSJOYozSWuXz38Zbt9hM7HJlW7s3jSaak&e=
>     
> 
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org 
>     https://www.ietf.org/mailman/listinfo/sipcore
>     
> 
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org 
>     https://www.ietf.org/mailman/listinfo/sipcore
>     
> 
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org 
>     https://www.ietf.org/mailman/listinfo/sipcore
>     
> 
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 


From nobody Mon May  8 23:49:12 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 075A0129B07; Mon,  8 May 2017 23:49:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149431254601.1705.1684364343600981365@ietfa.amsl.com>
Date: Mon, 08 May 2017 23:49:06 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-05.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 06:49:06 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : Content-ID header field in Session Initiation Protocol (SIP)
        Authors         : Christer Holmberg
                          Ivo Sedlacek
	Filename        : draft-ietf-sipcore-content-id-05.txt
	Pages           : 9
	Date            : 2017-05-08

Abstract:
   This document specifies the Content-ID header field for usage in the
   Session Initiation Protocol (SIP).  The document also updates RFC
   5621, to enable a Content-ID URL to reference a complete message-body
   and metadata provided by some additional SIP header fields.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-content-id-05
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-content-id-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-content-id-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon May  8 23:49:27 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B50129B0F; Mon,  8 May 2017 23:49:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Xu96f6N6mSTx; Mon,  8 May 2017 23:49:24 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BCB129B08; Mon,  8 May 2017 23:49:23 -0700 (PDT)
X-AuditID: c1b4fb30-663149a00000015f-e3-5911667117fb
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.16.00351.17661195; Tue,  9 May 2017 08:49:21 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Tue, 9 May 2017 08:48:56 +0200
From: Christer Holmberg 
To: Christer Holmberg , "A. Jean Mahoney" , Ivo Sedlacek , SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
Thread-Topic: Doc Shepherd review of draft-ietf-sipcore-content-id-03
Thread-Index: AQHSxSh1q98Q1cEUIUSox0v4i3K6ZqHlZgAA///ZKACAAFglgIAAPQqAgATRBwCAADBw8IAA0sMA
Date: Tue, 9 May 2017 06:48:56 +0000
Message-ID: 
References: <497fde51-223c-c113-8ad6-8c95ad12c654@nostrum.com>   <7a3451d7-ec00-809b-e4ca-60cbd5e1d385@nostrum.com>   <7594FB04B1934943A5C02806D1A2204B4CB98530@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB98530@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2F6BCEDEBA504545A22CA9EA5F7892B6@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7om5hmmCkwcm3Zhanv85gsmjoXMlq 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+P34s/MBR8EKqbs7mNtYFzJ28XI ySEhYCJx8utK9i5GLg4hgSOMEq/+32CDcBYzSkw6vpu5i5GDg03AQqL7nzZIXETgH6PExbWH mEC6hQVcJGYe6mAHsUUEXCWut90HqxcRiJL4Nk0cJMwioCLRNHsLK4jNK2At0bpyMhuILSSw nFliTZciiM0p4CexeecLsBpGATGJ76fWgI1nFhCXuPVkPhPEoQISS/acZ4awRSVePv4HVi8q oCex799XNoi4osTHV/sYIXp1JBbs/sQGYVtLvD0wmxnC1pZYtvA1M8Q9ghInZz5hmcAoNgvJ ullI2mchaZ+FpH0WkvYFjKyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQIj7OCW3wY7GF8+ dzzEKMDBqMTD+6BSIFKINbGsuDL3EKMEB7OSCO+VAMFIId6UxMqq1KL8+KLSnNTiQ4zSHCxK 4ryO+y5ECAmkJ5akZqemFqQWwWSZODilGhhr5E0eLy2uLpiwft+Djc+7pf5Xu6589H3nq8Xy YVsue+j5zYi6E8PF/+gJ2yHHZqnm292zX+zwcKlQybcNMT7xduLvCVZnTrqIyd+zvLvhU3vI vAihrk/8zFce+XNrfq9fq+J55VPQ4ckasxmOnnZfLuNS8j9+ytuZqRkJ/EdbY58bal58JWKh xFKckWioxVxUnAgAsdNyDqwCAAA=
Archived-At: 
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-content-id-03
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 09 May 2017 06:49:26 -0000

Hi,

I noted that I forgot one instance of the fix, so I did that and submitted
a new version (-05).

Regards,

Christer

On 08/05/17 22:20, "Christer Holmberg" 
wrote:

>Hi,
>
>I've submitted a new version (-04), with the changes.
>
>Regards,
>
>Christer
>
>-----Original Message-----
>From: A. Jean Mahoney [mailto:mahoney@nostrum.com]
>Sent: 08 May 2017 20:26
>To: Christer Holmberg ; Ivo Sedlacek
>; SIPCORE ;
>draft-ietf-sipcore-content-id@ietf.org
>Subject: Re: Doc Shepherd review of draft-ietf-sipcore-content-id-03
>
>Hi Christer,
>
>Thanks for making the changes!
>
>Jean
>
>On 5/5/17 8:48 AM, Christer Holmberg wrote:
>> Hi,
>>=20
>> Pull request updated, with s/body part/MIME entity
>>=20
>> Regards,
>>=20
>> Christer
>>=20
>>=20
>> On 05/05/17 16:14, "A. Jean Mahoney"  wrote:
>>=20
>>> Hi Ivo,
>>>
>>> On 5/5/17 2:59 AM, Ivo Sedlacek wrote:
>>>> Hello,
>>>>
>>>> regarding:
>>>>
>>>>> 1.4.1 and 1.4.2, 1st paragraphs:
>>>>>
>>>>> Old:                          then the UAC needs to include one
>>>>> content only in the INVITE request.  This content can be ...
>>>>>
>>>>> Suggested:                   then the UAC needs to include only one
>>>>> body part in the INVITE request.  This body part can be ...
>>>>
>>>> IMO, the above changes the semantic of the sentence.
>>>>
>>>> According to RFC2045, the term "body part" refers to an entity
>>>> **inside of a multipart entity**.
>>>>
>>>> The original text above allowed for the content to be included
>>>> either using multipart message-body or using non-multipart
>>>> message-body, in the INVITE request . The new text above indicates
>>>> that  the content needs to be included using multipart message-body
>>>> in the INVITE request.
>>>>
>>>> So, I would rather stick to "content", or perhaps replaces "content"
>>>> with "entity" or "MIME entity".
>>>
>>> I like "MIME entity".
>>>
>>> Thanks!
>>>
>>> Jean
>>>
>>>>
>>>> Kind regards
>>>>
>>>> Ivo
>>>>
>>>>
>>=20


From nobody Wed May 10 04:59:14 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD681294B5 for ; Tue,  9 May 2017 23:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 GfsLRf81Zr_i for ; Tue,  9 May 2017 23:14:40 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01251205F0 for ; Tue,  9 May 2017 23:14:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B472BB80E51; Tue,  9 May 2017 23:14:30 -0700 (PDT)
To: mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, br@brianrosen.net, mahoney@nostrum.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: dinoop.p1@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170510061430.B472BB80E51@rfc-editor.org>
Date: Tue,  9 May 2017 23:14:30 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Wed, 10 May 2017 04:59:13 -0700
Subject: [sipcore] [Editorial Errata Reported] RFC7044 (5012)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 06:14:41 -0000

The following errata report has been submitted for RFC7044,
"An Extension to the Session Initiation Protocol (SIP) for Request History Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5012

--------------------------------------
Type: Editorial
Reported by: Dinoop Paloli 

Section: 10.1.2

Original Text
-------------
If there is not a Privacy header field in the message

Corrected Text
--------------
If there is no Privacy header field in the message

Notes
-----
"If there is not a Privacy header" is not a correct sentence. We have to use  "If there is no Privacy header"

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title               : An Extension to the Session Initiation Protocol (SIP) for Request History Information
Publication Date    : February 2014
Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 10 04:59:19 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9A128C82; Tue,  9 May 2017 23:31:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 6URSECC_5ivV; Tue,  9 May 2017 23:31:01 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E9E127735; Tue,  9 May 2017 23:31:01 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 104BFB8101C; Tue,  9 May 2017 23:30:52 -0700 (PDT)
To: dinoop.p1@gmail.com, mary.ietf.barnes@gmail.com, francois.audet@skype.net,  shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: ben@nostrum.com, iesg@ietf.org, sipcore@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170510063052.104BFB8101C@rfc-editor.org>
Date: Tue,  9 May 2017 23:30:52 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Wed, 10 May 2017 04:59:13 -0700
Subject: [sipcore] [Errata Rejected] RFC7044 (5012)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 06:31:02 -0000

The following errata report has been rejected for RFC7044,
"An Extension to the Session Initiation Protocol (SIP) for Request History Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5012

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Dinoop Paloli 
Date Reported: 2017-05-10
Rejected by: Ben Campbell (IESG)

Section: 10.1.2

Original Text
-------------
If there is not a Privacy header field in the message

Corrected Text
--------------
If there is no Privacy header field in the message

Notes
-----
"If there is not a Privacy header" is not a correct sentence. We have to use  "If there is no Privacy header"
 --VERIFIER NOTES-- 
   Either usage is acceptable.

--------------------------------------
RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title               : An Extension to the Session Initiation Protocol (SIP) for Request History Information
Publication Date    : February 2014
Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 10 04:59:23 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44464128D3E for ; Wed, 10 May 2017 00:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 nVwtNwNGPfd3 for ; Wed, 10 May 2017 00:44:58 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA18120227 for ; Wed, 10 May 2017 00:44:58 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id A08C8B817E6; Wed, 10 May 2017 00:44:49 -0700 (PDT)
To: mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, br@brianrosen.net, mahoney@nostrum.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: dinoop.p1@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170510074449.A08C8B817E6@rfc-editor.org>
Date: Wed, 10 May 2017 00:44:49 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Wed, 10 May 2017 04:59:13 -0700
Subject: [sipcore] [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 07:45:00 -0000

The following errata report has been submitted for RFC7044,
"An Extension to the Session Initiation Protocol (SIP) for Request History Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5014

--------------------------------------
Type: Technical
Reported by: Dinoop Paloli 

Section: 9.1 and 10.3

Original Text
-------------


Corrected Text
--------------


Notes
-----
Ambiguity exists regarding the handling of missing history info entry

Section 9.1 says,
	If the Request-URI of the incoming request does not match the hi
   -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
   that sent the request did not include a History-Info header field),
   the SIP entity MUST add an hi-entry to the end of the cache on
   behalf of the previous SIP entity
  
	According to that, for example, if request is received with,
	Request URI : sip:peter@example.com
	and History info :  ;index=1
						;index=1.1
						;index=1.1.1
						;index=1.1.2

	Then processing entity has to add an history info in to cache on behalf of previous entity as,
	History info : ;index=1
               ;index=1.1
			   ;index=1.1.1
			   ;index=1.1.2
			   ;index=1.1.2.1
			   
But in section 10.3 basic rules 6 states,
		If the request clearly has a gap in the hi-entry
       (i.e., the last hi-entry and Request-URI differ), the entity
       adding an hi-entry MUST add a single index with a value of "0"
       (i.e., the non negative integer zero) prior to adding the
       appropriate index for the action to be taken. For example, if
       the index of the last hi-entry in the request received was 1.1.2
       and there was a missing hi-entry and the request was being
       forwarded to the next hop, the resulting index will be 1.1.2.0.1.
	   
	   But as per 9.1 stated above, once an entity receive a request with missing history info
		it has to add an entry to cache on behalf of previous one.
		So referring the previous example the added index would be 1.1.2.1
		And by applying the rule in 10.3, the index for the new request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title               : An Extension to the Session Initiation Protocol (SIP) for Request History Information
Publication Date    : February 2014
Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG


From nobody Wed May 10 07:47:41 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D58C1275C5; Wed, 10 May 2017 07:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 NrLbKM_cWoaM; Wed, 10 May 2017 07:47:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BCF0C127977; Wed, 10 May 2017 07:47:36 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AElXC0082319 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 09:47:34 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
From: Ben Campbell 
Content-Type: multipart/alternative; boundary="Apple-Mail=_2672FBE5-756F-44FB-A7A6-3DBE8133B7D5"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 10 May 2017 09:47:34 -0500
References: <20170510074449.A08C8B817E6@rfc-editor.org>
Cc: Mary Barnes , sipcore-chairs@ietf.org
To: SIPCORE 
Message-Id: 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 14:47:39 -0000

--Apple-Mail=_2672FBE5-756F-44FB-A7A6-3DBE8133B7D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Do people have thoughts on this?

Thanks!

ben.

> Begin forwarded message:
>=20
> From: RFC Errata System 
> Subject: [Technical Errata Reported] RFC7044 (5014)
> Date: May 10, 2017 at 2:44:49 AM CDT
> To: mary.ietf.barnes@gmail.com, francois.audet@skype.net, =
shida@ntt-at.com, ietf.hanserik@gmail.com, =
christer.holmberg@ericsson.com, ben@nostrum.com, alissa@cooperw.in, =
aamelnikov@fastmail.fm, br@brianrosen.net, mahoney@nostrum.com
> Cc: dinoop.p1@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
>=20
> The following errata report has been submitted for RFC7044,
> "An Extension to the Session Initiation Protocol (SIP) for Request =
History Information".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5014
>=20
> --------------------------------------
> Type: Technical
> Reported by: Dinoop Paloli 
>=20
> Section: 9.1 and 10.3
>=20
> Original Text
> -------------
>=20
>=20
> Corrected Text
> --------------
>=20
>=20
> Notes
> -----
> Ambiguity exists regarding the handling of missing history info entry
>=20
> Section 9.1 says,
> 	If the Request-URI of the incoming request does not match the hi
>   -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
>   that sent the request did not include a History-Info header field),
>   the SIP entity MUST add an hi-entry to the end of the cache on
>   behalf of the previous SIP entity
>=20
> 	According to that, for example, if request is received with,
> 	Request URI : sip:peter@example.com
> 	and History info :  ;index=3D1
> 						=
;index=3D1.1
> 						=
;index=3D1.1.1
> 						=
;index=3D1.1.2
>=20
> 	Then processing entity has to add an history info in to cache on =
behalf of previous entity as,
> 	History info : ;index=3D1
>               ;index=3D1.1
> 			   ;index=3D1.1.1
> 			   ;index=3D1.1.2
> 			   ;index=3D1.1.2.1
> 			  =20
> But in section 10.3 basic rules 6 states,
> 		If the request clearly has a gap in the hi-entry
>       (i.e., the last hi-entry and Request-URI differ), the entity
>       adding an hi-entry MUST add a single index with a value of "0"
>       (i.e., the non negative integer zero) prior to adding the
>       appropriate index for the action to be taken. For example, if
>       the index of the last hi-entry in the request received was 1.1.2
>       and there was a missing hi-entry and the request was being
>       forwarded to the next hop, the resulting index will be =
1.1.2.0.1.
> 	  =20
> 	   But as per 9.1 stated above, once an entity receive a request =
with missing history info
> 		it has to add an entry to cache on behalf of previous =
one.
> 		So referring the previous example the added index would =
be 1.1.2.1
> 		And by applying the rule in 10.3, the index for the new =
request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1
>=20
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party =20
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
> --------------------------------------
> Title               : An Extension to the Session Initiation Protocol =
(SIP) for Request History Information
> Publication Date    : February 2014
> Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, =
C. Holmberg
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol Core RAI
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG


--Apple-Mail=_2672FBE5-756F-44FB-A7A6-3DBE8133B7D5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Do people have thoughts on this?

Thanks!

ben.

Begin forwarded =
message:

From: =
RFC Errata System <rfc-editor@rfc-editor.org>
Subject: =
[Technical Errata =
Reported] RFC7044 (5014)
Date: =
May 10, 2017 at 2:44:49 AM =
CDT
To: =
mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com, ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, br@brianrosen.net, mahoney@nostrum.com
Cc: =
dinoop.p1@gmail.com, =
sipcore@ietf.org, rfc-editor@rfc-editor.org

The following errata report =
has been submitted for RFC7044,
"An Extension to the =
Session Initiation Protocol (SIP) for Request History Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5014

--------------------------------------
Type: =
Technical
Reported by: Dinoop Paloli =
<dinoop.p1@gmail.com>

Section: 9.1 =
and 10.3

Original Text
-------------


Corrected Text
--------------


Notes
-----
Ambiguity exists regarding the handling of missing history =
info entry

Section 9.1 says,
	=
If the Request-URI of the incoming request does not match the =
hi
   -targeted-to-uri in the last hi-entry =
(i.e., the previous SIP entity
   that sent the =
request did not include a History-Info header field),
 =
  the SIP entity MUST add an hi-entry to the end of the cache =
on
   behalf of the previous SIP entity

	According to that, for example, =
if request is received with,
	Request URI : =
sip:peter@example.com
	and History info : =
 <sip:bob@example.com>;index=3D1
						=
<sip:alice@example>;index=3D1.1
						=
<sip:jain@example>;index=3D1.1.1
						=
<sip:dave@example>;index=3D1.1.2

	=
Then processing entity has to add an history info in to cache on =
behalf of previous entity as,
	History info : =
<sip:bob@example.com>;index=3D1
 =
            &n=
bsp; <sip:alice@example>;index=3D1.1
			 =
  <sip:jain@example>;index=3D1.1.1
			 =
  <sip:dave@example>;index=3D1.1.2
			 =
  <sip:peter@example.com>;index=3D1.1.2.1
	=
	=
	=
   
But in section 10.3 basic rules 6 =
states,
		If the request clearly has a gap =
in the hi-entry
 =
      (i.e., the last hi-entry and =
Request-URI differ), the entity
 =
      adding an hi-entry MUST add a single =
index with a value of "0"
 =
      (i.e., the non negative integer =
zero) prior to adding the
 =
      appropriate index for the action to =
be taken. For example, if
 =
      the index of the last hi-entry in =
the request received was 1.1.2
 =
      and there was a missing hi-entry and =
the request was being
 =
      forwarded to the next hop, the =
resulting index will be 1.1.2.0.1.
	 =
  
	   But as per 9.1 =
stated above, once an entity receive a request with missing history =
info
		it has to add an entry to cache =
on behalf of previous one.
		So referring the previous example =
the added index would be 1.1.2.1
		And by =
applying the rule in 10.3, the index for the new request created by this =
entity would be 1.1.2.1.0.1 not 1.1.2.0.1

Instructions:
-------------
This =
erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified =
or
rejected. When a decision is reached, the verifying =
party  
can log in to change the status and edit the =
report, if necessary. 

--------------------------------------
RFC7044 =
(draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title =
            &n=
bsp; : An Extension to the Session Initiation Protocol (SIP) for =
Request History Information
Publication Date =
   : February 2014
Author(s) =
          : M. Barnes, =
F. Audet, S. Schubert, J. van Elburg, C. Holmberg
Category =
           : =
PROPOSED STANDARD
Source =
            &n=
bsp;: Session Initiation Protocol Core RAI
Area =
            &n=
bsp;  : Real-time Applications and Infrastructure
Stream =
            &n=
bsp;: IETF
Verifying Party     : =
IESG

=

--Apple-Mail=_2672FBE5-756F-44FB-A7A6-3DBE8133B7D5--


From nobody Wed May 10 09:34:24 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC91212DDD2 for ; Wed, 10 May 2017 09:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.034
X-Spam-Level: 
X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 TNmfq9zVWs6z for ; Wed, 10 May 2017 09:34:13 -0700 (PDT)
Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3AC412E038 for ; Wed, 10 May 2017 09:34:13 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-02v.sys.comcast.net with SMTP id 8UY5dfFjgBHfP8UZ3do0RN; Wed, 10 May 2017 16:34:13 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-16v.sys.comcast.net with SMTP id 8UZ0dWzHQ9isy8UZ1dxWCr; Wed, 10 May 2017 16:34:12 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v4AGY9qR013500; Wed, 10 May 2017 12:34:09 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v4AGY8Pa013493; Wed, 10 May 2017 12:34:08 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Ben Campbell 
Cc: sipcore@ietf.org, sipcore-chairs@ietf.org
In-Reply-To:  (ben@nostrum.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 10 May 2017 12:34:08 -0400
Message-ID: <87o9v0k6wv.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfKAla7c5RU4eOYRf51xgIGG4PNRvW6mDU/jlh5GIx+nGqztEFInEySmp02MaAjVMgJSq37zTbwvpIdfcKFEEizbh1JQEy20AEkLfoUIcPmjH85fPX5tu UlN28qhce7ln+3MsVPs9pBZyMDhTcwxFo7RZKweXVHK69gJtSL41CpQoWbCnnIw/CeJtP6qN39GH41HcbRYVZmbgMt2btjCS0Hkd8m9u7AprUzl7zMWW5sbg
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 16:34:16 -0000

Ben Campbell  writes:
> Do people have thoughts on this?

I haven't dug into this erratum, but there are a number of places in
7044 where the language isn't as exact as we'd like.

Dale


From nobody Wed May 10 10:58:29 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 054BD126C22; Wed, 10 May 2017 10:58:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149443909999.16637.11197197582450340705@ietfa.amsl.com>
Date: Wed, 10 May 2017 10:58:20 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 17:58:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-status-unwanted-06.txt
	Pages           : 8
	Date            : 2017-05-10

Abstract:
   This document defines the 607 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-06
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-status-unwanted-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed May 10 11:00:54 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF012E035 for ; Wed, 10 May 2017 11:00:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.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 MvFtdXUiTyEq for ; Wed, 10 May 2017 11:00:51 -0700 (PDT)
Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327A7128D44 for ; Wed, 10 May 2017 11:00:51 -0700 (PDT)
Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4AHxcF7001253 for ; Wed, 10 May 2017 18:00:49 GMT
Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0a-0024ed01.pphosted.com with ESMTP id 2a97n0bnm2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 10 May 2017 18:00:49 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JWauGh0WAL2srlQvRLjyU20jQN/tkAuNz/W7+Pp30Ts=; b=RiGYfNLtXCm33+MrF7eM5VfEVtD6HQuLv5/CFXZdSKbP7mI/9g9dH6sXNHKb2xM7CDbCFeSzCv3KHGCM7se3CQ4jXAw6drfLfQl1A0hkmhoDBieajKWD+dEyuRCuWwznFQ2mPB1dCoYDT0eWkY67s50bCIlDGhikfNTfqdFwawk=
Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Wed, 10 May 2017 18:00:47 +0000
Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.1075.020; Wed, 10 May 2017 18:00:47 +0000
From: Henning Schulzrinne 
To: "sipcore@ietf.org" 
Thread-Topic: draft-ietf-sipcore-status-unwanted update (06) posted
Thread-Index: AdLJtxsEB+2y4WhfSW+99KKlqmS8Tw==
Date: Wed, 10 May 2017 18:00:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=fcc.gov;
x-originating-ip: [192.104.54.21]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:BQ14zmrZoJ89rAQQunO+R4/2Pev6liRnam/c/Mmb8mwxDQpLFWSTi+JcSCsUDn5dvp8x2Rhpr5jCatZwVA+nNkzFKhNmjAWQSw1RUgijzIopCo5W7HBDF0U4ZIPCLBfTtMRWpM5cwnBqjiv+v0fVy3Rrm/5QE8Ux5jPwlJAvsIa5E6uPvu5wS5yFO9cwF9bn+AM0NznfZSeFPuRQiuLaGPS3lBu7jZ0ijbwHCe0cH/m3b2bRF0BmB0mzoDGuV+dbpZgkhECJvWvBRgsphp/ThjIPY4guuPGMajDTHWpko2BKbmSoqnvCDS488C1YSKNGXcD65F/44wrUS9Ld/DUjpA==
x-ms-office365-filtering-correlation-id: 48509f5c-bfda-468b-74a0-08d497ce7c57
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY1PR09MB0634; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; 
x-forefront-prvs: 03030B9493
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(39450400003)(39410400002)(39400400002)(1730700003)(102836003)(3846002)(8676002)(38730400002)(6916009)(790700001)(6116002)(5630700001)(478600001)(110136004)(189998001)(54356999)(7696004)(230783001)(8936002)(81166006)(7736002)(106356001)(72206003)(33656002)(2906002)(74316002)(2501003)(2351001)(3280700002)(3660700001)(50986999)(19609705001)(6506006)(25786009)(53936002)(99286003)(6306002)(5660300001)(54896002)(77096006)(2900100001)(6436002)(122556002)(9686003)(5640700003)(66066001)(55016002)(86362001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06343C66F35DD7004C64C967EAEC0CY1PR09MB0634namp_"
MIME-Version: 1.0
X-OriginatorOrg: fcc.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2017 18:00:46.8163 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_14:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Subject: [sipcore] draft-ietf-sipcore-status-unwanted update (06) posted
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 18:00:53 -0000

--_000_CY1PR09MB06343C66F35DD7004C64C967EAEC0CY1PR09MB0634namp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have posted -06 of the draft, incorporating all (or so I hope...) IESG ev=
aluation comments and other relevant comments. The changes should be editor=
ial only. Anybody who has provided comments after -05: please double-check,=
 as I had to make some judgement calls on how to incorporate suggestions.

Henning

--_000_CY1PR09MB06343C66F35DD7004C64C967EAEC0CY1PR09MB0634namp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I have posted -06 of the draft, incorporating all (o=
r so I hope…) IESG evaluation comments and other relevant comments. T=
he changes should be editorial only. Anybody who has provided comments afte=
r -05: please double-check, as I had to
 make some judgement calls on how to incorporate suggestions.

 


Henning






--_000_CY1PR09MB06343C66F35DD7004C64C967EAEC0CY1PR09MB0634namp_--


From nobody Wed May 10 15:14:35 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E81292C5; Wed, 10 May 2017 15:14:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149445446927.16592.2204654514356219019@ietfa.amsl.com>
Date: Wed, 10 May 2017 15:14:29 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-name-addr-guidance-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 22:14:29 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : Clarifications for when to use the name-addr production in SIP messages
        Author          : Robert Sparks
	Filename        : draft-ietf-sipcore-name-addr-guidance-01.txt
	Pages           : 6
	Date            : 2017-05-10

Abstract:
   RFC3261 constrained several SIP header fields whose grammar contains
   the "name-addr / addr-spec" alternative to use name-addr when certain
   characters appear.  Unfortunately it expressed the constraints with
   prose copied into each header field definition, and at least one
   header field was missed.  Further, the constraint has not been copied
   into documents defining extension headers whose grammar contains the
   alternative.

   This document updates RFC3261 to state the constraint generically,
   and clarifies that the constraint applies to all SIP header fields
   where there is a choice between using name-addr or addr-spec.  It
   also updates the RFCs that define extension SIP header fields using
   the alternative to clarify that the constraint applies (RFCs 3325,
   3515, 3892, 4508, 5002, 5318, 5360, and 5502).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-name-addr-guidance/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-name-addr-guidance-01
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-name-addr-guidance-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-name-addr-guidance-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed May 10 15:59:59 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CED1270FC; Wed, 10 May 2017 15:59:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.02
X-Spam-Level: 
X-Spam-Status: No, score=0.02 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, TVD_SPACE_RATIO=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 cOwFn_EdHiOc; Wed, 10 May 2017 15:59:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5FFFD12009C; Wed, 10 May 2017 15:59:57 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4AMxuZQ031932 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 May 2017 17:59:57 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: SIPCORE , "draft-ietf-sipcore-content-id@ietf.org" 
From: "A. Jean Mahoney" 
Message-ID: 
Date: Wed, 10 May 2017 17:59:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [sipcore] Doc Shepherd Write-up for draft-ietf-sipcore-content-id
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 10 May 2017 22:59:59 -0000

Is available: 
https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/shepherdwriteup/

Thanks!

Jean


From nobody Thu May 11 13:07:50 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0BD1314A0 for ; Thu, 11 May 2017 13:07:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149453326956.16673.9299351495348659443.idtracker@ietfa.amsl.com>
Date: Thu, 11 May 2017 13:07:49 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [sipcore] Milestones changed for sipcore WG
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 20:07:50 -0000

Changed milestone "Request publication of a SIP response code for
unwanted communications ", resolved as "Done".

Changed milestone "Request publication of a mechanism for labeling the
nature of SIP calls", added draft-ietf-sipcore-callinfo-spam to
milestone, removed draft-schulzrinne-sipcore-callinfo-spam from
milestone.

Changed milestone "Request publication of a clarification of the use
of Content-ID as a SIP header field", resolved as "Done", added
draft-ietf-sipcore-content-id to milestone, removed
draft-holmberg-sipcore-content-id from milestone.

Changed milestone "Request publication of a clarification of the use
of the "name-addr" production in SIP header fields", added
draft-ietf-sipcore-name-addr-guidance to milestone, removed
draft-sparks-sipcore-name-addr-guidance from milestone.

URL: https://datatracker.ietf.org/wg/sipcore/about/


From nobody Thu May 11 14:03:34 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314D12E04F; Thu, 11 May 2017 14:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 DgpDTtGLrjP9; Thu, 11 May 2017 14:03:31 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3E88012F3D6; Thu, 11 May 2017 13:56:56 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BKurlE067480 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 15:56:54 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: sipcore@ietf.org, draft-yusef-sipcore-sip-authn@ietf.org
References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com>
From: "A. Jean Mahoney" 
Message-ID: 
Date: Thu, 11 May 2017 15:56:53 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 21:03:33 -0000

Hi all,

There is consensus for taking this draft on as a WG item.

Authors, please submit a WG -00 draft.

Thanks!

Jean

On 4/6/17 2:08 PM, A. Jean Mahoney wrote:
> Hi all,
> 
> During the WG session in Chicago, Rifaat presented this draft, and the 
> chairs took a hum on whether the WG should take on this draft as a WG item.
> 
> There was consensus at the meeting to take this draft on. Now I'm 
> gauging interest on the mailing list. Please let the list know if you 
> have any objections to taking this work on.
> 
> Thanks!
> 
> Jean
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Thu May 11 14:03:46 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AE912EC80; Thu, 11 May 2017 14:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.481
X-Spam-Level: 
X-Spam-Status: No, score=-0.481 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cnVGJLS_3uiA; Thu, 11 May 2017 14:03:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E1BC5128BA2; Thu, 11 May 2017 13:56:58 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BKuwkb067489 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 15:56:58 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: sipcore@ietf.org, draft-jesske-sipcore-reason-q850-loc@ietf.org
References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com>
From: "A. Jean Mahoney" 
Message-ID: 
Date: Thu, 11 May 2017 15:56:57 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 21:03:40 -0000

Hi all,

There is consensus for taking this draft on as a WG item.

Roland, please submit a WG -00 draft.

Thanks!

Jean


On 4/6/17 2:08 PM, A. Jean Mahoney wrote:
> Hi all,
> 
> During the WG session in Chicago, Roland presented this draft, and the 
> chairs took a hum on whether the WG should take on this draft as a WG item.
> 
> There was consensus at the meeting to take this draft on. Now I'm 
> gauging interest on the mailing list. Please let the list know if you 
> have any objections to taking this work on.
> 
> Thanks!
> 
> Jean
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Thu May 11 14:31:55 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972F512896F; Thu, 11 May 2017 14:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 BQ2rewVF9_fG; Thu, 11 May 2017 14:31:51 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8264212951F; Thu, 11 May 2017 14:25:29 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4BKv1Ln067502 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 May 2017 15:57:02 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: sipcore@ietf.org, draft-mohali-sipcore-originating-cdiv-parameter@ietf.org
References: <25855_1489353730_58C5BC02_25855_10494_1_8B970F90C584EA4E97D5BAAC9172DBB81C935BDC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com>
From: "A. Jean Mahoney" 
Message-ID: <6092a6f9-406e-1309-9bb8-fe596f7303ed@nostrum.com>
Date: Thu, 11 May 2017 15:57:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <58b9213c-1fb1-95f7-6888-60f7a754fc4f@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] Draft new: draft-mohali-sipcore-originating-cdiv-parameter-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 11 May 2017 21:31:54 -0000

Hi all,

There is consensus for taking this draft on as a WG item.

Marianne, please submit a WG -00 draft.

Thanks!

Jean

On 3/30/17 5:21 PM, A. Jean Mahoney wrote:
> Hi all,
> 
> I mentioned this draft during the WG session today. Does anyone have any 
> comments on the draft? Should it become a WG document?
> 
> Thanks!
> 
> Jean
> 
> On 3/12/17 4:22 PM, marianne.mohali@orange.com wrote:
>> Hi all,
>>
>> Please find hereafter a new version of I-D,
>> draft-mohali-sipcore-originating-cdiv-parameter-00 (was
>> draft-mohali-dispatch-originating-cdiv-parameter-03).
>> https://www.ietf.org/internet-drafts/draft-mohali-sipcore-originating-cdiv-parameter-00.txt 
>>
>>
>>  Based on ADs and Chairs guidance, this draft is moved from DISPATCH
>> to SIPCORE following the new charter of sipcore WG.
>>
>> Abstract: This specification defines a new parameter of the
>> P-Served-User header field in the Session Initiation Protocol (SIP).
>> This new "orig-cdiv" parameter defines the session case used by a
>> proxy when handling an originating session after Call Diversion
>> (CDIV) services has been invoked for the served user.  The
>> P-Served-User header field is defined in RFC5502 to convey the
>> identity of the served user and the session case that applies to this
>> particular communication session and application invocation.  This
>> document updates RFC5502 to add the "originating after CDIV" session
>> case and to provide more guidance for using the P-Served-User header
>> field in IP networks that were missing in RFC5502.
>>
>>> From the discussion in DISPATCH, in this version of the draft, the
>>> syntax of the header could be improved as shown below:
>>
>> sessioncase-param        = ("sescase" EQUAL ("orig" / "term")) /
>> "orig-cdiv" registration-state-param = "regstate" EQUAL ("unreg" /
>> "reg")
>>
>> This draft is not in the agenda for IETF 98 but comments are welcomed
>> anyway.
>>
>> Best regards, Marianne
>>
>>
>>
>>
>>
>> _________________________________________________________________________________________________________________________ 
>>
>>
>>  Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites ou copies sans autorisation. Si vous avez recu ce message
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
>> que les pieces jointes. Les messages electroniques etant susceptibles
>> d'alteration, Orange decline toute responsabilite si ce message a ete
>> altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law; they should not
>> be distributed, used or copied without authorisation. If you have
>> received this email in error, please notify the sender and delete
>> this message and its attachments. As emails may be altered, Orange is
>> not liable for messages that have been modified, changed or
>> falsified. Thank you.
>>
>> _______________________________________________ sipcore mailing list
>> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
>>
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Thu May 11 17:55:07 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66FD127077; Thu, 11 May 2017 17:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=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 6wY9e5g9NtfL; Thu, 11 May 2017 17:55:00 -0700 (PDT)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 7CE3612EB03; Thu, 11 May 2017 17:49:53 -0700 (PDT)
Received: by mail-vk0-x234.google.com with SMTP id x71so10454751vkd.0; Thu, 11 May 2017 17:49:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9GgLaebFn/kUkZlTpwHwyjw6r3szehYZF0rIbJJfLH8=; b=YvDBR2mcslaHlWt2Xp7PSQIq+9ZmeVFHEJHHTMU83VXC4VP2Ly6sED2VV+enKCLT1R bTOVDcPnL3K/75wlbjLbXPgldqD/nhEeWDZGf4/c+ma5QaibdOuTWW/0QtG8dyD/7Lzr 4H4PLitRUmfNKlvXPo3ja9EkobjNbH9RdpZz4Ad/5FKLOF79vmT+GhO0EWMjnD6L0bUH 5gGmiwXVkjeG+YVmGY5Dy+CYSUh0EytMvtRJUXF3600jyNgTeuXSOp3aChsednVz71+J dShQqc7/XlZFk0rhwf73FN5X6O2M3Vu1yx/nxMcrcuQakh6shX+u7sRpNfctluoSYBUe tc7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9GgLaebFn/kUkZlTpwHwyjw6r3szehYZF0rIbJJfLH8=; b=dsAUyKrgIpb+/0QnDPzC2HfDY9b0fPO+sUts6LSs+J63rq8OW/1aBRmUiMVlZJYM3z lJbu0BTk6NFdgZ4W8Vp50jSOj7KsfjB0N1J0wqX5QMMnW6tiFUmQEMr/zMXl+ND5uGYo FbpJnoWRS4E694n9rIDjV+hxgz3vyAKm0MlXeWR3HThkxGUAPUgLlRJwEsmMpq9K5R3M iq+jfOzEGurD0TAAfcBO9wG64a4pfNVzkWojO3VTYIWzXKz5/Z8SLdggpYAxT5swmitC qQ6rR7liK5rLg8QFIng+YrcAmTVI5httfdzTLOd6Zj+uium4jt/ppgwW7PR4Nxeea3aT b9BQ==
X-Gm-Message-State: AODbwcDIcY9A5SF2NeechmwOq12LeHblWWPOYbSoky7YsBo9/K1m/IUJ Rymvw3z5SeW40Bp8h6V6ytUrweOCZQ==
X-Received: by 10.31.88.68 with SMTP id m65mr412365vkb.122.1494550192374; Thu, 11 May 2017 17:49:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.76.91 with HTTP; Thu, 11 May 2017 17:49:51 -0700 (PDT)
In-Reply-To: 
References: <01194ff4-c044-0861-6a30-3cc54fc0a455@nostrum.com> 
From: Rifaat Shekh-Yusef 
Date: Thu, 11 May 2017 20:49:51 -0400
Message-ID: 
To: "A. Jean Mahoney" 
Cc: "sipcore@ietf.org" , draft-yusef-sipcore-sip-authn@ietf.org
Content-Type: multipart/alternative; boundary="001a114e568a50cb2f054f49154d"
Archived-At: 
Subject: Re: [sipcore] draft-yusef-sipcore-sip-authn - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 12 May 2017 00:55:06 -0000

--001a114e568a50cb2f054f49154d
Content-Type: text/plain; charset="UTF-8"

Thanks Jean.

On Thu, May 11, 2017 at 4:56 PM, A. Jean Mahoney 
wrote:

> Hi all,
>
> There is consensus for taking this draft on as a WG item.
>
> Authors, please submit a WG -00 draft.
>
> Thanks!
>
> Jean
>
>
> On 4/6/17 2:08 PM, A. Jean Mahoney wrote:
>
>> Hi all,
>>
>> During the WG session in Chicago, Rifaat presented this draft, and the
>> chairs took a hum on whether the WG should take on this draft as a WG item.
>>
>> There was consensus at the meeting to take this draft on. Now I'm gauging
>> interest on the mailing list. Please let the list know if you have any
>> objections to taking this work on.
>>
>> Thanks!
>>
>> Jean
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>

--001a114e568a50cb2f054f49154d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Thanks Jean.

On Thu, May 11, 2017 at 4:56 PM, A. Jean Mahoney <maho=
ney@nostrum.com> wrote:
Hi =
all,



There is consensus for taking this draft on as a WG item.



Authors, please submit a WG -00 draft.



Thanks!



Jean




On 4/6/17 2:08 PM, A. Jean Mahoney wrote:



Hi all,



During the WG session in Chicago, Rifaat presented this draft, and the chai=
rs took a hum on whether the WG should take on this draft as a WG item.



There was consensus at the meeting to take this draft on. Now I'm gaugi=
ng interest on the mailing list. Please let the list know if you have any o=
bjections to taking this work on.



Thanks!



Jean



_______________________________________________

sipcore mailing list

sipcore@ietf.org<=
br>
https://www.ietf.org/mailman/listinfo/sipcore<=
br>






--001a114e568a50cb2f054f49154d--


From nobody Mon May 15 04:05:58 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4702B127873 for ; Mon, 15 May 2017 04:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.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 PIb1Jo9Zc8kF for ; Mon, 15 May 2017 04:05:54 -0700 (PDT)
Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C818A1293F2 for ; Mon, 15 May 2017 04:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cMyxjuRfrAUTLzg2UL96earbvSTq2vG8y6gIoqyyvWo=; b=j6PjX7W7Hh3t7lu+Cu35b7NVUL+1EMJXuNUif50VpveLCqQw9ab68VmckJFLGTydtdE7ok40IGjm8SEeuvk8BER/964vLYD9rSh3YevyA5ExEt7Bdvx2mA7i6U7twudfEAsM5+hFKdv9vjH97CzvW9LR7N6vPtIzbhcvLww4/Pk=
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-140-kBAsat6iOJCHmMqA-C7kkA-1; Mon, 15 May 2017 07:02:22 -0400
Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 15 May 2017 11:02:19 +0000
Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1084.029; Mon, 15 May 2017 11:02:19 +0000
From: "Asveren, Tolga" 
To: "sipcore@ietf.org" 
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
Thread-Index: AQHSybceweZbMlDQ40iYNcpH4crOaqH1P1oA
Date: Mon, 15 May 2017 11:02:19 +0000
Message-ID: 
References: <149443909999.16637.11197197582450340705@ietfa.amsl.com>
In-Reply-To: <149443909999.16637.11197197582450340705@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [73.29.18.75]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:zxSZUqaS9RNV0ZzdjzmGN4MB2f8yQVJ4WbrwRZulivCCYidJm+XsSSg9n9XNT74mWBLk7HEXr3zC3hVLTF0T/Y046JpFpVX3Fn0NXTFrQ9dksjJnU5O94a5DM/ODfHL7PMNJJjGedN2tywHoAwW3Y8orCiMyy4RGPMY79t5RKHOTXmsGbX6WlLeJ7wHgbB+9+OME7MN1v/lWhPRrddGe/k+vtDtoNHAtzEWCiJ3y75BqEsDDD0+pBVKnzyjl0/jO/8rTxUrNMkdGkOuP7VyOk9FuodXp2UnABWU7wxIQSqw/IGUV+ajnTRJR/eQFy1Lb6cokI6Nn1jyf+4j0awQoKQ==; 20:AHgnj6f4JZeh/4tg/XYDQpCDOdOkF+sqThPBp8px138Gtl+akcoESrA1SBNXwu9PokIJzvBpUFN4UvNNpXkmFopRJP6uqAJwuK4wpTzSroicAX6Qbaxj58wFlEGNJO0PqOu7XlRcmcjFko86gJNJeb4B/uWz0dC2MHPBYDSfOxg=
x-ms-office365-filtering-correlation-id: 0debd652-0585-4f8e-8d1f-08d49b81db61
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; 
x-forefront-prvs: 0308EE423E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39450400003)(39830400002)(13464003)(377454003)(377424004)(2900100001)(5640700003)(230783001)(81166006)(53546009)(77096006)(25786009)(74316002)(6506006)(189998001)(86362001)(50986999)(76176999)(54356999)(6436002)(2906002)(110136004)(6246003)(38730400002)(55016002)(9686003)(6306002)(99286003)(3280700002)(8676002)(122556002)(33656002)(3660700001)(53936002)(2501003)(305945005)(2950100002)(6916009)(8936002)(102836003)(3846002)(229853002)(478600001)(5660300001)(2351001)(6116002)(1730700003)(7696004)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 11:02:19.7860 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352
X-MC-Unique: kBAsat6iOJCHmMqA-C7kkA-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 11:05:57 -0000

Looks good to me with just a few comments (or rants, if you will):=20

i- =20
"The user agent of
   the called party, based on input from the called party or some UA-
   internal logic, uses this to indicate that this call is unwanted and
   that future attempts are likely to be similarly rejected."

FWIW, I really feel uneasy about the "or some UA-internal logic" part of th=
e first sentence.

ii-
"As discussed in Section 6, reversing
   the 'unwanted' labeling is beyond the scope of this mechanism, as it
   will likely require a mechanism other than call signaling."

This could be a great place to add a statement that this response code pert=
ains only to a single call and does not mean that the end-user has a desire=
 for blocking the called party permanently. This really would add great val=
ue to prevent misinterpretation of 607 IMHO.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft=
s@ietf.org
Sent: Wednesday, May 10, 2017 1:58 PM
To: i-d-announce@ietf.org
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Session Initiation Protocol Core of the IE=
TF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
=09Filename        : draft-ietf-sipcore-status-unwanted-06.txt
=09Pages           : 8
=09Date            : 2017-05-10

Abstract:
   This document defines the 607 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-06
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-status-unwanted-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-status-unwanted-06


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


From nobody Mon May 15 06:01:52 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A4412EB10; Mon, 15 May 2017 06:01:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149485330510.11932.1674179920254654388@ietfa.amsl.com>
Date: Mon, 15 May 2017 06:01:45 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-originating-cdiv-parameter-00.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 13:01:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : A P-Served-User Header Field Parameter for Originating CDIV session case in Session Initiation Protocol (SIP)
        Author          : Marianne Mohali
	Filename        : draft-ietf-sipcore-originating-cdiv-parameter-00.txt
	Pages           : 9
	Date            : 2017-05-14

Abstract:
   This specification defines a new parameter of the P-Served-User
   header field in the Session Initiation Protocol (SIP).  This new
   "orig-cdiv" parameter defines the session case used by a proxy when
   handling an originating session after Call Diversion (CDIV) services
   has been invoked for the served user.  The P-Served-User header field
   is defined in RFC5502 to convey the identity of the served user and
   the session case that applies to this particular communication
   session and application invocation.  This document updates RFC5502 to
   add the "originating after CDIV" session case and to provide more
   guidance for using the P-Served-User header field in IP networks that
   were missing in RFC5502.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-originating-cdiv-parameter/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-originating-cdiv-parameter-00
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-originating-cdiv-parameter-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon May 15 07:35:49 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102A312EA93; Mon, 15 May 2017 07:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 P837cqeEUz1S; Mon, 15 May 2017 07:35:44 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 35B4912EB06; Mon, 15 May 2017 07:30:57 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4FEUqL1053572 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 May 2017 09:30:54 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <87o9v0k6wv.fsf@hobgoblin.ariadne.com>
Date: Mon, 15 May 2017 09:31:00 -0500
Cc: sipcore@ietf.org, sipcore-chairs@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <580237CE-94F8-439F-922F-5AA981B6F3FA@nostrum.com>
References: <87o9v0k6wv.fsf@hobgoblin.ariadne.com>
To: "Dale R. Worley" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 14:35:46 -0000

Thanks, but does anyone have thoughts on this particular erratum? :-)

Ben.

> On May 10, 2017, at 11:34 AM, Dale R. Worley  wrote:
> 
> Ben Campbell  writes:
>> Do people have thoughts on this?
> 
> I haven't dug into this erratum, but there are a number of places in
> 7044 where the language isn't as exact as we'd like.
> 
> Dale


From nobody Mon May 15 07:42:50 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A45A129584; Mon, 15 May 2017 07:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.4
X-Spam-Level: 
X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 ysYUsIjRw__q; Mon, 15 May 2017 07:42:49 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9980A126B6E; Mon, 15 May 2017 07:39:03 -0700 (PDT)
Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 47E53181F96; Mon, 15 May 2017 16:39:02 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 1266F20066; Mon, 15 May 2017 16:39:02 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0339.000; Mon, 15 May 2017 16:39:01 +0200
From: 
To: Ben Campbell , "Dale R. Worley" 
CC: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" 
Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
Thread-Index: AQHSyas+Sxn8psXz+EOWivhIX9KCV6H1WuEAgAAjMQA=
Date: Mon, 15 May 2017 14:39:01 +0000
Message-ID: <5125_1494859142_5919BD86_5125_6942_1_8B970F90C584EA4E97D5BAAC9172DBB81C9B9775@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <87o9v0k6wv.fsf@hobgoblin.ariadne.com> <580237CE-94F8-439F-922F-5AA981B6F3FA@nostrum.com>
In-Reply-To: <580237CE-94F8-439F-922F-5AA981B6F3FA@nostrum.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 14:42:50 -0000

Hi,

I'm going to have a look and give a feedback today.

BR,
Marianne

> -----Message d'origine-----
> De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de Ben Campbe=
ll
> Envoy=E9=A0: lundi 15 mai 2017 16:31
> =C0=A0: Dale R. Worley
> Cc=A0: sipcore@ietf.org; sipcore-chairs@ietf.org
> Objet=A0: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
>=20
> Thanks, but does anyone have thoughts on this particular erratum? :-)
>=20
> Ben.
>=20
> > On May 10, 2017, at 11:34 AM, Dale R. Worley 
> wrote:
> >
> > Ben Campbell  writes:
> >> Do people have thoughts on this?
> >
> > I haven't dug into this erratum, but there are a number of places in
> > 7044 where the language isn't as exact as we'd like.
> >
> > Dale
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


From nobody Mon May 15 08:07:55 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B8128BB6; Mon, 15 May 2017 08:07:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 0vk1k_l0NoYs; Mon, 15 May 2017 08:07:48 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 959CC129AD2; Mon, 15 May 2017 08:03:22 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id f55so47927028qta.3; Mon, 15 May 2017 08:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uKZEfn7XBFBqdPG+NsoE18I4SNDFkuRPXOZKP6zoKVU=; b=PzR2pg2DWMQ46ettDfRKeYfeojlhzciJivkBQaF4lBWRmOMto6IU9oxflGt+mDxae4 D0IvfmNCZO1aOOXn4KnnzH3sTQK46SlbMShHLQ9HlgLMkKmugY+ZRzE+xomrtuk3NTsW WeQQcf4DDKAzyzVnNzLg33dAHX67etgwv/oA1KUwmFoPyPAl7r5fcCbmazUzQTa+0MtS vWfLHbp7yaYl6jtoGcT7fwte8qZEMs6y2o5N9fzL41HLlzzT4Jk/FyaSQuRRDW+5igjv nkQohweV4+C3tZYOLGELFlFL3Q6+TmHgRET9FGU+Ro8/dQJceul97bqbE8hkE3FHFNEf 22Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uKZEfn7XBFBqdPG+NsoE18I4SNDFkuRPXOZKP6zoKVU=; b=TmMIyoQELL1XgRY3+C3e+kUjSn7Y9W3FUJb7UqfINUMicGIwh/vTd1K2JzFtKpJteV zC+OFAna2Z2CK5OJBmRQ1CTED5xw89f5vVP7GwTEc8kOjrBrMkwLg8Q0sLTI/bYTIg5J Ll6c4W/P746CnIwEG5ulwfzZaj8UN4TvYXf3HwVy9OrCNJH6w6GAxS2lkqgQCC2Pg4P0 MlFBOU9dyZiBIC63KzM1CEdIpiWf6oEQi86K/EhXI0/M+GVFX1ZvsgaM914IsMNRashy BZjSR9Nzr20fQGtbnN7GVVIJbdpUUGWJ+lgJ8MHqB1lhiM6eB5HO+zkdzq/6XCnKUqiK o/Bw==
X-Gm-Message-State: AODbwcBgLm7hxknlJCv4KwNlSkrgE+xO/MangJ5Am0kf/YV3pcQmQZv+ KQjunJP3TuLOTEEezNhMKRoTYdZgGw==
X-Received: by 10.200.42.28 with SMTP id k28mr6568222qtk.40.1494860600484; Mon, 15 May 2017 08:03:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.36.233 with HTTP; Mon, 15 May 2017 08:03:19 -0700 (PDT)
In-Reply-To: <580237CE-94F8-439F-922F-5AA981B6F3FA@nostrum.com>
References: <87o9v0k6wv.fsf@hobgoblin.ariadne.com> <580237CE-94F8-439F-922F-5AA981B6F3FA@nostrum.com>
From: Mary Barnes 
Date: Mon, 15 May 2017 10:03:19 -0500
Message-ID: 
To: Ben Campbell 
Cc: "Dale R. Worley" , SIPCORE , sipcore-chairs@ietf.org
Content-Type: multipart/alternative; boundary="001a113fdb3214a7b2054f915b3f"
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 15:07:53 -0000

--001a113fdb3214a7b2054f915b3f
Content-Type: text/plain; charset="UTF-8"

I'm looking into it.  At first glance it might have been an oversight, but
we were pretty careful and thorough with this revision, so I'm going to dig
back through some emails, etc. before I have a clear position.

Regards,
Mary.

On Mon, May 15, 2017 at 9:31 AM, Ben Campbell  wrote:

> Thanks, but does anyone have thoughts on this particular erratum? :-)
>
> Ben.
>
> > On May 10, 2017, at 11:34 AM, Dale R. Worley  wrote:
> >
> > Ben Campbell  writes:
> >> Do people have thoughts on this?
> >
> > I haven't dug into this erratum, but there are a number of places in
> > 7044 where the language isn't as exact as we'd like.
> >
> > Dale
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--001a113fdb3214a7b2054f915b3f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I'm looking into it.=C2=A0 At first glance it might ha=
ve been an oversight, but we were pretty careful and thorough with this rev=
ision, so I'm going to dig back through some emails, etc. before I have=
 a clear position.

Regards,
Mary.
<=
div class=3D"gmail_extra">
On Mon, May 15, 20=
17 at 9:31 AM, Ben Campbell <ben@nostrum.com> wrote:
Thanks, but does anyone have thoughts on this part=
icular erratum? :-)



Ben.




> On May 10, 2017, at 11:34 AM, Dale R. Worley <worley@ariadne.com> wrote:

>

> Ben Campbell <ben@nostrum.com> writes:

>> Do people have thoughts on this?

>

> I haven't dug into this erratum, but there are a number of places =
in

> 7044 where the language isn't as exact as we'd like.

>

> Dale



_______________________________________________

sipcore mailing list

sipcore@ietf.org

https://www.ietf.org/mailman/listinfo/sipcore<=
br>




--001a113fdb3214a7b2054f915b3f--


From nobody Mon May 15 12:32:40 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5EC129C43 for ; Mon, 15 May 2017 12:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.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 prQWmuR7Olgs for ; Mon, 15 May 2017 12:32:34 -0700 (PDT)
Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11411129C1A for ; Mon, 15 May 2017 12:29:29 -0700 (PDT)
Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4FJTRSN031236; Mon, 15 May 2017 19:29:27 GMT
Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0018.outbound.protection.outlook.com [23.103.198.18]) by mx0b-0024ed01.pphosted.com with ESMTP id 2aduae9p0j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 May 2017 19:29:27 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bSgkQddflIt0Gr4ZEY5/1bqDqECr/VhclzujOcz9+lw=; b=Zzd34BPuuhXW468neV6vnnsIGdmEmFz5J3IwWkgAD0WiwffpHjDwObd47s9WHQN94wqFtcW+gRbrxRDA0NAKFoKI8PiY1ilaOj6g+ot58iUbufvSIof0FXFr7AqonGm6R+2B69RW8pM/V4IQqvLjkW9JYBEvZvGXLf97zacVbGc=
Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Mon, 15 May 2017 19:29:25 +0000
Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.1084.029; Mon, 15 May 2017 19:29:26 +0000
From: Henning Schulzrinne 
To: "Asveren, Tolga" , "sipcore@ietf.org" 
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
Thread-Index: AQHSybcVBxqDOcm55027tHSsrxw286H1QgKAgACM0TA=
Date: Mon, 15 May 2017 19:29:25 +0000
Message-ID: 
References: <149443909999.16637.11197197582450340705@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: sonusnet.com; dkim=none (message not signed) header.d=none;sonusnet.com; dmarc=none action=none header.from=fcc.gov;
x-originating-ip: [192.104.54.21]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:hJo5+XyYE4XC2osTBrBdKgffylRW4JajKN1NvXuqPa9za/5HN5qT0txiJrksVGTfVrnnvpmjiLN7BLJvR60ouV7y4KO3NzleCneahakvkXgHJF1A/Rip+7sLJPhdPQH1reQ9OPU7+LPTmw6Aw38WepbyyLhhSaNLWTsoGTlQwsV6OggC4xI/H/5UXx2/OJHZvQZKZY4MazmZKnrwO+cBHIihB61khdXMazofVPKYfjnglBHXX11gewPOMWUuJznOzONfJ5yuJFViA8OiDmtP/U4e9b5DNm2X+ZLCNnv+PMn9fT1HXcAfxfqMlBszoJdg/Fdeq0IWpa54ke/f0PoyCQ==
x-ms-office365-filtering-correlation-id: 77b1f5af-c7c5-4abd-2bfc-08d49bc8b2bc
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY1PR09MB0636; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; 
x-forefront-prvs: 0308EE423E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39400400002)(13464003)(377424004)(377454003)(99286003)(55016002)(9686003)(230783001)(229853002)(6246003)(6306002)(38730400002)(3660700001)(3846002)(8676002)(478600001)(77096006)(6436002)(6506006)(25786009)(53546009)(122556002)(81166006)(53936002)(189998001)(2900100001)(72206003)(5660300001)(575784001)(86362001)(2906002)(7736002)(54356999)(3280700002)(7696004)(6116002)(66066001)(2950100002)(50986999)(76176999)(102836003)(74316002)(8936002)(33656002)(2501003)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: fcc.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2017 19:29:25.8648 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-15_10:, , signatures=0
X-Proofpoint-Spam-Reason: safe
Archived-At: 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 19:32:38 -0000

Tolga,

Given that both points have been discussed many times before, I'm reluctant=
 to open those issues again.

On the second issue, 607 is useless if it is has no (potential, statistical=
, etc.) influence on future calls. The called party indicates that they did=
n't want to receive that call and don't want to be called again by the same=
 party, either. I won't repeat the usual caveats we discussed about phone n=
umber changes and such, as those are covered in the document.

Henning

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga
Sent: Monday, May 15, 2017 7:02 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.tx=
t

Looks good to me with just a few comments (or rants, if you will):=20

i- =20
"The user agent of
   the called party, based on input from the called party or some UA-
   internal logic, uses this to indicate that this call is unwanted and
   that future attempts are likely to be similarly rejected."

FWIW, I really feel uneasy about the "or some UA-internal logic" part of th=
e first sentence.

ii-
"As discussed in Section 6, reversing
   the 'unwanted' labeling is beyond the scope of this mechanism, as it
   will likely require a mechanism other than call signaling."

This could be a great place to add a statement that this response code pert=
ains only to a single call and does not mean that the end-user has a desire=
 for blocking the called party permanently. This really would add great val=
ue to prevent misinterpretation of 607 IMHO.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft=
s@ietf.org
Sent: Wednesday, May 10, 2017 1:58 PM
To: i-d-announce@ietf.org
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Session Initiation Protocol Core of the IE=
TF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
	Filename        : draft-ietf-sipcore-status-unwanted-06.txt
	Pages           : 8
	Date            : 2017-05-10

Abstract:
   This document defines the 607 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org=
_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDwICAg&c=3Dy0h0omCe0jA=
UGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq=
8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3Dd8nMGqUjgAnZr_F7bIVtTr4QNXYDwuKhpd6reL=
MfaFI&e=3D=20

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_=
draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0h0omCe0jAU=
Gr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8=
US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3D4ftlZWWq_Hroo1UNfrl1kVXt9I3mDp51YByQsyr=
oCuQ&e=3D=20
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org=
_doc_html_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0=
h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y=
_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DaWXdzCCYLm7gAYjKWeWD6xmTkVdy1=
I3tFq-3Gny_FzI&e=3D=20

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff=
-3Furl2-3Ddraft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0=
h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y=
_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DIhmck2y6dNA28nzmCASmi7n6k1_hX=
xgBHjNW4bzKygg&e=3D=20


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-=
2Ddrafts_&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU=
1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DXl=
dJkTgvhflTtLhcALaRywRr9dfZ4EMWx8lz7DvBVxg&e=3D=20

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV=
0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vw=
E&s=3D_turveVqD0DjvCoQs9ycbZrozjiAWjtJK3Jsl0uT13k&e=3D=20

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV=
0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vw=
E&s=3D_turveVqD0DjvCoQs9ycbZrozjiAWjtJK3Jsl0uT13k&e=3D=20


From nobody Mon May 15 12:33:14 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF225128D69 for ; Mon, 15 May 2017 12:33:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.018
X-Spam-Level: 
X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 lL-HaD7EBxmY for ; Mon, 15 May 2017 12:33:12 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 498061292C5 for ; Mon, 15 May 2017 12:30:04 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4FJU13F091689 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 May 2017 14:30:01 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: "Asveren, Tolga" , "Dale R. Worley" , "sipcore@ietf.org" 
References: <87bmrdmxo0.fsf@hobgoblin.ariadne.com> 
From: "A. Jean Mahoney" 
Message-ID: <6d628729-482d-aace-0bb8-ab579d9e316c@nostrum.com>
Date: Mon, 15 May 2017 14:30:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sipcore] Proposal to revise the dual stack milestone
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 19:33:14 -0000

Hi everyone,

Does anyone else have any thoughts on modifying the milestone?

As the WG finishes up some of the current milestones and adds new WG 
documents, we'll need to update our milestone list.

Thanks!

Jean

On 5/1/17 2:18 AM, Asveren, Tolga wrote:
> I think that is a good idea with a few caveats:
> 
> i- Connectionless transports should be covered as well (possibly by
> making use of OPTIONS) ii- Use of multiple interfaces/transport
> protocols should be mentioned as well. I think this can be done just
> by adding a few sentences along the lines of: All IP Address
> Family/Transport Family/Interface triplet combinations should be
> tried simultaneously. Some headstart may be provided for certain
> combinations depending on local policy.
> 
> Otherwise I think it is the right approach not to dive into details
> of the algorithm to use.
> 
> Thanks, Tolga
> 
> -----Original Message----- From: sipcore
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent:
> Sunday, April 30, 2017 4:46 PM To: sipcore@ietf.org Subject:
> [sipcore] Proposal to revise the dual stack milestone
> 
> The Sipcore working group has the following milestone listed (at 
> https://datatracker.ietf.org/wg/sipcore/about/):
> 
> Dec 2017        Request publication of mechanisms for rapid
> dual-stack protocol selection in SIP
> 
> The draft draft-johansson-sip-he-connection is listed for this
> milestone.  However, that draft covers only a narrow subset of the
> overall problem.
> 
> Over the past month or so, I have been canvassing Sipcore members to
> find out if there is any practical demand for a dual-stack solution
> for SIP.  With the exception of a particular case, I have found no
> interest.
> 
> Because of this, I propose that we narrow the scope of this milestone
> to the one case for which I have found interest:
> 
> Request publication of a mechanism for rapid dual-stack protocol
> selection in SIP when the destination has multiple, unprioritized
> targets for connection-oriented protocols
> 
> Conveniently, draft-johansson-sip-he-connection describes such a
> mechanism.  Its mechanism closely parallels that of RFC 6555 ("Happy
> Eyeballs"), and the text is essentially complete.  Because there are
> no unresolved technical issues, the text is complete, and there are
> known implementation instances where this mechanism is needed, I urge
> the approval of this draft even if its scope is narrow.
> 
> Dale
> 
> _______________________________________________ sipcore mailing list 
> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
> 
> _______________________________________________ sipcore mailing list 
> sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore
> 


From nobody Mon May 15 13:38:00 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5A129B8C for ; Mon, 15 May 2017 13:37:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level: 
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 OrpAAAk_RhUH for ; Mon, 15 May 2017 13:37:56 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B023129AD4 for ; Mon, 15 May 2017 13:35:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17562; q=dns/txt; s=iport; t=1494880515; x=1496090115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IEHMbMvajkhXfBaxphypdGshcS7THABxQZbRScpKIvY=; b=jAOwiAdvUWHl0Acmi6s20gjDPrUApU71bFwLQv/IysOujhfFh5SeMvkB mHTkvx5DFF3rXXDyyrcfXd1Al3rKY2OuUbyj48y8NMKp7k0YvNjJIKxB5 EfGPx3SSbuIrbZCjPmuMeScmcOkkQM5UFdelyq4a3/D3HoLHdHlpn/P1J g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BQAQCoDxpZ/4MNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMB4NkihiRYJA9hTiCDyEBCoUuSgIahRw/GAECAQEBAQE?= =?us-ascii?q?BAWsohRgBAQEBAwEBIUsLDAQCAQgRBAEBKAMCAgIlCxQJCAIEDgUbiggOrF+CJ?= =?us-ascii?q?op6AQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGX4IJgnCHdS+CMQEElm+HGwGHG4t?= =?us-ascii?q?/C4F5j2eIf4tDAR84gQpwFUYSAYZjdodfgQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.38,346,1491264000";  d="scan'208,217";a="426192739"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 May 2017 20:35:14 +0000
Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v4FKZD9k001851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 May 2017 20:35:13 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 15 May 2017 15:35:13 -0500
Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Mon, 15 May 2017 15:35:13 -0500
From: "Gonzalo Salgueiro (gsalguei)" 
To: "A. Jean Mahoney" 
CC: "Asveren, Tolga" , "Dale R. Worley" , "sipcore@ietf.org" 
Thread-Topic: [sipcore] Proposal to revise the dual stack milestone
Thread-Index: AQHSwfMi1SPtLrxom0ufEMFt41ORJKHfZhwAgBbNGYCAABI4gA==
Date: Mon, 15 May 2017 20:35:13 +0000
Message-ID: 
References: <87bmrdmxo0.fsf@hobgoblin.ariadne.com>  <6d628729-482d-aace-0bb8-ab579d9e316c@nostrum.com>
In-Reply-To: <6d628729-482d-aace-0bb8-ab579d9e316c@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.250.251]
Content-Type: multipart/alternative; boundary="_000_ED38E7C8946F4E31AB1E14FEC90010F3ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sipcore] Proposal to revise the dual stack milestone
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 20:37:58 -0000

--_000_ED38E7C8946F4E31AB1E14FEC90010F3ciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgSmVhbiAtDQoNClRoZXJlIGFyZSB0d28gZGlzdGluY3Qgc3ViLW1pbGVzdG9uZXMgZm9yIHRo
aXMgbWlsZXN0b25lLCBpbiBteSBvcGluaW9uLiAgVGhlIGZpcnN0IG9uZSBpcyBuYXJyb3dlciBh
bmQgY2FuIGJlIHNjb3BlZCBhcyBEYWxlIGluZGljYXRlZDoNCg0KICAgICAgIFJlcXVlc3QgcHVi
bGljYXRpb24gb2YgYSBtZWNoYW5pc20gZm9yIHJhcGlkIGR1YWwtc3RhY2sNCiAgICAgICBwcm90
b2NvbCBzZWxlY3Rpb24gaW4gU0lQIHdoZW4gdGhlIGRlc3RpbmF0aW9uIGhhcyBtdWx0aXBsZSwN
CiAgICAgICB1bnByaW9yaXRpemVkIHRhcmdldHMgZm9yIGNvbm5lY3Rpb24tb3JpZW50ZWQgcHJv
dG9jb2xzDQoNCkkgdGhpbmsgZHJhZnQtam9oYW5zc29uLXNpcC1oZS1jb25uZWN0aW9uIGNhbiBi
ZSBhZG9wdGVkIGZvciB0aGlzLg0KDQpTdWJzZXF1ZW50bHkgd2UgaG9wZSB0byBwcm92aWRlIGEg
bW9yZSBjb21wcmVoZW5zaXZlIGR1YWwtc3RhY2sgc29sdXRpb24gZm9yIFNJUCBhbG9uZyB0aGUg
bGluZXMgb2YgZHJhZnQtd29ybGV5LXNpcGNvcmUtaGFwcHktZWFyYmFsbHMuIE15IHByZWZlcmVu
Y2UgaXMgd2UgZ2l2ZSB0aGUgbGF0dGVyIGl0cyBkdWUgcmlnb3IgYW5kIGZvY3VzLCBzbyBJIGRv
buKAmXQgdGhpbmsgdGhleSBzaG91bGQgYmUgZG9uZSBpbiBwYXJhbGxlbCwgcmF0aGVyIGluIHNl
cmllcy4NCg0KVGhhbmtzLA0KDQpHb256YWxvDQoNCg0KT24gTWF5IDE1LCAyMDE3LCBhdCAzOjMw
IFBNLCBBLiBKZWFuIE1haG9uZXkgPG1haG9uZXlAbm9zdHJ1bS5jb208bWFpbHRvOm1haG9uZXlA
bm9zdHJ1bS5jb20+PiB3cm90ZToNCg0KSGkgZXZlcnlvbmUsDQoNCkRvZXMgYW55b25lIGVsc2Ug
aGF2ZSBhbnkgdGhvdWdodHMgb24gbW9kaWZ5aW5nIHRoZSBtaWxlc3RvbmU/DQoNCkFzIHRoZSBX
RyBmaW5pc2hlcyB1cCBzb21lIG9mIHRoZSBjdXJyZW50IG1pbGVzdG9uZXMgYW5kIGFkZHMgbmV3
IFdHIGRvY3VtZW50cywgd2UnbGwgbmVlZCB0byB1cGRhdGUgb3VyIG1pbGVzdG9uZSBsaXN0Lg0K
DQpUaGFua3MhDQoNCkplYW4NCg0KT24gNS8xLzE3IDI6MTggQU0sIEFzdmVyZW4sIFRvbGdhIHdy
b3RlOg0KSSB0aGluayB0aGF0IGlzIGEgZ29vZCBpZGVhIHdpdGggYSBmZXcgY2F2ZWF0czoNCmkt
IENvbm5lY3Rpb25sZXNzIHRyYW5zcG9ydHMgc2hvdWxkIGJlIGNvdmVyZWQgYXMgd2VsbCAocG9z
c2libHkgYnkNCm1ha2luZyB1c2Ugb2YgT1BUSU9OUykgaWktIFVzZSBvZiBtdWx0aXBsZSBpbnRl
cmZhY2VzL3RyYW5zcG9ydA0KcHJvdG9jb2xzIHNob3VsZCBiZSBtZW50aW9uZWQgYXMgd2VsbC4g
SSB0aGluayB0aGlzIGNhbiBiZSBkb25lIGp1c3QNCmJ5IGFkZGluZyBhIGZldyBzZW50ZW5jZXMg
YWxvbmcgdGhlIGxpbmVzIG9mOiBBbGwgSVAgQWRkcmVzcw0KRmFtaWx5L1RyYW5zcG9ydCBGYW1p
bHkvSW50ZXJmYWNlIHRyaXBsZXQgY29tYmluYXRpb25zIHNob3VsZCBiZQ0KdHJpZWQgc2ltdWx0
YW5lb3VzbHkuIFNvbWUgaGVhZHN0YXJ0IG1heSBiZSBwcm92aWRlZCBmb3IgY2VydGFpbg0KY29t
YmluYXRpb25zIGRlcGVuZGluZyBvbiBsb2NhbCBwb2xpY3kuDQpPdGhlcndpc2UgSSB0aGluayBp
dCBpcyB0aGUgcmlnaHQgYXBwcm9hY2ggbm90IHRvIGRpdmUgaW50byBkZXRhaWxzDQpvZiB0aGUg
YWxnb3JpdGhtIHRvIHVzZS4NClRoYW5rcywgVG9sZ2ENCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tIEZyb206IHNpcGNvcmUNClttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgRGFsZSBSLiBXb3JsZXkgU2VudDoNClN1bmRheSwgQXByaWwgMzAsIDIwMTcgNDo0
NiBQTSBUbzogc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4gU3ViamVj
dDoNCltzaXBjb3JlXSBQcm9wb3NhbCB0byByZXZpc2UgdGhlIGR1YWwgc3RhY2sgbWlsZXN0b25l
DQpUaGUgU2lwY29yZSB3b3JraW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZSBs
aXN0ZWQgKGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2lwY29yZS9hYm91dC8p
Og0KRGVjIDIwMTcgICAgICAgIFJlcXVlc3QgcHVibGljYXRpb24gb2YgbWVjaGFuaXNtcyBmb3Ig
cmFwaWQNCmR1YWwtc3RhY2sgcHJvdG9jb2wgc2VsZWN0aW9uIGluIFNJUA0KVGhlIGRyYWZ0IGRy
YWZ0LWpvaGFuc3Nvbi1zaXAtaGUtY29ubmVjdGlvbiBpcyBsaXN0ZWQgZm9yIHRoaXMNCm1pbGVz
dG9uZS4gIEhvd2V2ZXIsIHRoYXQgZHJhZnQgY292ZXJzIG9ubHkgYSBuYXJyb3cgc3Vic2V0IG9m
IHRoZQ0Kb3ZlcmFsbCBwcm9ibGVtLg0KT3ZlciB0aGUgcGFzdCBtb250aCBvciBzbywgSSBoYXZl
IGJlZW4gY2FudmFzc2luZyBTaXBjb3JlIG1lbWJlcnMgdG8NCmZpbmQgb3V0IGlmIHRoZXJlIGlz
IGFueSBwcmFjdGljYWwgZGVtYW5kIGZvciBhIGR1YWwtc3RhY2sgc29sdXRpb24NCmZvciBTSVAu
ICBXaXRoIHRoZSBleGNlcHRpb24gb2YgYSBwYXJ0aWN1bGFyIGNhc2UsIEkgaGF2ZSBmb3VuZCBu
bw0KaW50ZXJlc3QuDQpCZWNhdXNlIG9mIHRoaXMsIEkgcHJvcG9zZSB0aGF0IHdlIG5hcnJvdyB0
aGUgc2NvcGUgb2YgdGhpcyBtaWxlc3RvbmUNCnRvIHRoZSBvbmUgY2FzZSBmb3Igd2hpY2ggSSBo
YXZlIGZvdW5kIGludGVyZXN0Og0KUmVxdWVzdCBwdWJsaWNhdGlvbiBvZiBhIG1lY2hhbmlzbSBm
b3IgcmFwaWQgZHVhbC1zdGFjayBwcm90b2NvbA0Kc2VsZWN0aW9uIGluIFNJUCB3aGVuIHRoZSBk
ZXN0aW5hdGlvbiBoYXMgbXVsdGlwbGUsIHVucHJpb3JpdGl6ZWQNCnRhcmdldHMgZm9yIGNvbm5l
Y3Rpb24tb3JpZW50ZWQgcHJvdG9jb2xzDQpDb252ZW5pZW50bHksIGRyYWZ0LWpvaGFuc3Nvbi1z
aXAtaGUtY29ubmVjdGlvbiBkZXNjcmliZXMgc3VjaCBhDQptZWNoYW5pc20uICBJdHMgbWVjaGFu
aXNtIGNsb3NlbHkgcGFyYWxsZWxzIHRoYXQgb2YgUkZDIDY1NTUgKCJIYXBweQ0KRXllYmFsbHMi
KSwgYW5kIHRoZSB0ZXh0IGlzIGVzc2VudGlhbGx5IGNvbXBsZXRlLiAgQmVjYXVzZSB0aGVyZSBh
cmUNCm5vIHVucmVzb2x2ZWQgdGVjaG5pY2FsIGlzc3VlcywgdGhlIHRleHQgaXMgY29tcGxldGUs
IGFuZCB0aGVyZSBhcmUNCmtub3duIGltcGxlbWVudGF0aW9uIGluc3RhbmNlcyB3aGVyZSB0aGlz
IG1lY2hhbmlzbSBpcyBuZWVkZWQsIEkgdXJnZQ0KdGhlIGFwcHJvdmFsIG9mIHRoaXMgZHJhZnQg
ZXZlbiBpZiBpdHMgc2NvcGUgaXMgbmFycm93Lg0KRGFsZQ0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18gc2lwY29yZSBtYWlsaW5nIGxpc3Qgc2lwY29yZUBp
ZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9zaXBjb3JlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXyBzaXBjb3JlIG1haWxpbmcgbGlzdCBzaXBjb3JlQGlldGYub3JnPG1haWx0
bzpzaXBjb3JlQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl
DQoNCg==

--_000_ED38E7C8946F4E31AB1E14FEC90010F3ciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <3322B94FF553614681DEFF56EEC11D1A@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgSmVhbiAtJm5ic3A7DQo8ZGl2
IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGVyZSBhcmUg
dHdvIGRpc3RpbmN0IHN1Yi1taWxlc3RvbmVzIGZvciB0aGlzIG1pbGVzdG9uZSwgaW4gbXkgb3Bp
bmlvbi4gJm5ic3A7VGhlIGZpcnN0IG9uZSBpcyBuYXJyb3dlciBhbmQgY2FuIGJlIHNjb3BlZCBh
cyBEYWxlIGluZGljYXRlZDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BT
TVQ7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtSZXF1ZXN0IHB1YmxpY2F0
aW9uIG9mIGEgbWVjaGFuaXNtIGZvciByYXBpZCBkdWFsLXN0YWNrPC9zcGFuPjxiciBzdHlsZT0i
Zm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdG9jb2wgc2VsZWN0aW9uIGluIFNJUCB3aGVuIHRoZSBk
ZXN0aW5hdGlvbiBoYXMgbXVsdGlwbGUsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IENv
dXJpZXJOZXdQU01UOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENvdXJp
ZXJOZXdQU01UOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7dW5wcmlvcml0aXplZCB0YXJnZXRzIGZvciBjb25uZWN0aW9uLW9yaWVudGVkIHByb3Rv
Y29sczwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsiIGNsYXNz
PSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IiBjbGFzcz0iIj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl
bnQ6IDBweDsiIGNsYXNzPSIiPkkgdGhpbmsmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigw
LCAwLCAwKTsgZm9udC1mYW1pbHk6IENvdXJpZXJOZXdQU01UOyBmb250LXNpemU6IDE0cHg7IGZv
bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6
IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5kcmFmdC1qb2hhbnNzb24tc2lwLWhlLWNvbm5lY3Rpb24N
CiBjYW4gYmUgYWRvcHRlZCBmb3IgdGhpcy4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl
PSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsiIGNsYXNzPSIiPjxzcGFuIHN0
eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ291cmllck5ld1BTTVQ7IGZv
bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LXRy
YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv
c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog
MHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt
aWx5OiBDb3VyaWVyTmV3UFNNVDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7
IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z
cGFjaW5nOiBub3JtYWw7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs
OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh
c3M9IiI+U3Vic2VxdWVudGx5DQogd2UgaG9wZSB0byBwcm92aWRlIGEgbW9yZSBjb21wcmVoZW5z
aXZlJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh
bWlseTogQ291cmllck5ld1BTTVQ7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFs
OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt
c3BhY2luZzogbm9ybWFsOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h
bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNs
YXNzPSIiPmR1YWwtc3RhY2sNCiBzb2x1dGlvbiBmb3ImbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9
ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDb3VyaWVyTmV3UFNNVDsgZm9udC1z
aXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtdHJhbnNm
b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp
dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+U0lQDQogYWxvbmcgdGhlIGxpbmVz
IG9mJm5ic3A7PC9zcGFuPjxmb250IGZhY2U9IkNvdXJpZXJOZXdQU01UIiBjbGFzcz0iIj5kcmFm
dC13b3JsZXktc2lwY29yZS1oYXBweS1lYXJiYWxscy4gTXkgcHJlZmVyZW5jZSBpcyB3ZSBnaXZl
IHRoZSBsYXR0ZXIgaXRzIGR1ZSByaWdvciBhbmQgZm9jdXMsIHNvIEkgZG9u4oCZdCB0aGluayB0
aGV5IHNob3VsZCBiZSBkb25lIGluIHBhcmFsbGVsLCByYXRoZXIgaW4gc2VyaWVzLjwvZm9udD48
L2Rpdj4NCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyIg
Y2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIiPjxiciBjbGFzcz0i
Ij4NCjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9InRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu
ZGVudDogMHB4OyIgY2xhc3M9IiI+PGZvbnQgZmFjZT0iQ291cmllck5ld1BTTVQiIGNsYXNzPSIi
PlRoYW5rcyw8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWFsaWduOiBzdGFydDsgdGV4
dC1pbmRlbnQ6IDBweDsiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXJOZXdQU01UIiBjbGFz
cz0iIj48YnIgY2xhc3M9IiI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2IHN0eWxlPSJ0ZXh0LWFsaWdu
OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsiIGNsYXNzPSIiPjxmb250IGZhY2U9IkNvdXJpZXJO
ZXdQU01UIiBjbGFzcz0iIj5Hb256YWxvPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6
IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGZvbnQtc2l6ZTogMTRw
eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl
aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0
LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo
aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJ0NvdXJp
ZXIgTmV3JzsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu
dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt
YWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0
ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3
b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkgMTUsIDIwMTcsIGF0IDM6
MzAgUE0sIEEuIEplYW4gTWFob25leSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1haG9uZXlAbm9zdHJ1
bS5jb20iIGNsYXNzPSIiPm1haG9uZXlAbm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N
CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0K
PGRpdiBjbGFzcz0iIj5IaSBldmVyeW9uZSw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpE
b2VzIGFueW9uZSBlbHNlIGhhdmUgYW55IHRob3VnaHRzIG9uIG1vZGlmeWluZyB0aGUgbWlsZXN0
b25lPzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkFzIHRoZSBXRyBmaW5pc2hlcyB1cCBz
b21lIG9mIHRoZSBjdXJyZW50IG1pbGVzdG9uZXMgYW5kIGFkZHMgbmV3IFdHIGRvY3VtZW50cywg
d2UnbGwgbmVlZCB0byB1cGRhdGUgb3VyIG1pbGVzdG9uZSBsaXN0LjxiciBjbGFzcz0iIj4NCjxi
ciBjbGFzcz0iIj4NClRoYW5rcyE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpKZWFuPGJy
IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gNS8xLzE3IDI6MTggQU0sIEFzdmVyZW4sIFRv
bGdhIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi
PkkgdGhpbmsgdGhhdCBpcyBhIGdvb2QgaWRlYSB3aXRoIGEgZmV3IGNhdmVhdHM6PGJyIGNsYXNz
PSIiPg0KaS0gQ29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0cyBzaG91bGQgYmUgY292ZXJlZCBhcyB3
ZWxsIChwb3NzaWJseSBieTxiciBjbGFzcz0iIj4NCm1ha2luZyB1c2Ugb2YgT1BUSU9OUykgaWkt
IFVzZSBvZiBtdWx0aXBsZSBpbnRlcmZhY2VzL3RyYW5zcG9ydDxiciBjbGFzcz0iIj4NCnByb3Rv
Y29scyBzaG91bGQgYmUgbWVudGlvbmVkIGFzIHdlbGwuIEkgdGhpbmsgdGhpcyBjYW4gYmUgZG9u
ZSBqdXN0PGJyIGNsYXNzPSIiPg0KYnkgYWRkaW5nIGEgZmV3IHNlbnRlbmNlcyBhbG9uZyB0aGUg
bGluZXMgb2Y6IEFsbCBJUCBBZGRyZXNzPGJyIGNsYXNzPSIiPg0KRmFtaWx5L1RyYW5zcG9ydCBG
YW1pbHkvSW50ZXJmYWNlIHRyaXBsZXQgY29tYmluYXRpb25zIHNob3VsZCBiZTxiciBjbGFzcz0i
Ij4NCnRyaWVkIHNpbXVsdGFuZW91c2x5LiBTb21lIGhlYWRzdGFydCBtYXkgYmUgcHJvdmlkZWQg
Zm9yIGNlcnRhaW48YnIgY2xhc3M9IiI+DQpjb21iaW5hdGlvbnMgZGVwZW5kaW5nIG9uIGxvY2Fs
IHBvbGljeS48YnIgY2xhc3M9IiI+DQpPdGhlcndpc2UgSSB0aGluayBpdCBpcyB0aGUgcmlnaHQg
YXBwcm9hY2ggbm90IHRvIGRpdmUgaW50byBkZXRhaWxzPGJyIGNsYXNzPSIiPg0Kb2YgdGhlIGFs
Z29yaXRobSB0byB1c2UuPGJyIGNsYXNzPSIiPg0KVGhhbmtzLCBUb2xnYTxiciBjbGFzcz0iIj4N
Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IHNpcGNvcmU8YnIgY2xhc3M9IiI+DQpb
PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyIgY2xhc3M9IiI+bWFpbHRv
OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEYWxlIFIuIFdvcmxl
eSBTZW50OjxiciBjbGFzcz0iIj4NClN1bmRheSwgQXByaWwgMzAsIDIwMTcgNDo0NiBQTSBUbzog
PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIGNsYXNzPSIiPnNpcGNvcmVAaWV0Zi5v
cmc8L2E+IFN1YmplY3Q6PGJyIGNsYXNzPSIiPg0KW3NpcGNvcmVdIFByb3Bvc2FsIHRvIHJldmlz
ZSB0aGUgZHVhbCBzdGFjayBtaWxlc3RvbmU8YnIgY2xhc3M9IiI+DQpUaGUgU2lwY29yZSB3b3Jr
aW5nIGdyb3VwIGhhcyB0aGUgZm9sbG93aW5nIG1pbGVzdG9uZSBsaXN0ZWQgKGF0IDxhIGhyZWY9
Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvc2lwY29yZS9hYm91dC8iIGNsYXNzPSIi
Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9zaXBjb3JlL2Fib3V0LzwvYT4pOjxi
ciBjbGFzcz0iIj4NCkRlYyAyMDE3ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO1JlcXVlc3QgcHVibGljYXRpb24gb2YgbWVjaGFuaXNtcyBmb3IgcmFwaWQ8YnIgY2xh
c3M9IiI+DQpkdWFsLXN0YWNrIHByb3RvY29sIHNlbGVjdGlvbiBpbiBTSVA8YnIgY2xhc3M9IiI+
DQpUaGUgZHJhZnQgZHJhZnQtam9oYW5zc29uLXNpcC1oZS1jb25uZWN0aW9uIGlzIGxpc3RlZCBm
b3IgdGhpczxiciBjbGFzcz0iIj4NCm1pbGVzdG9uZS4gJm5ic3A7SG93ZXZlciwgdGhhdCBkcmFm
dCBjb3ZlcnMgb25seSBhIG5hcnJvdyBzdWJzZXQgb2YgdGhlPGJyIGNsYXNzPSIiPg0Kb3ZlcmFs
bCBwcm9ibGVtLjxiciBjbGFzcz0iIj4NCk92ZXIgdGhlIHBhc3QgbW9udGggb3Igc28sIEkgaGF2
ZSBiZWVuIGNhbnZhc3NpbmcgU2lwY29yZSBtZW1iZXJzIHRvPGJyIGNsYXNzPSIiPg0KZmluZCBv
dXQgaWYgdGhlcmUgaXMgYW55IHByYWN0aWNhbCBkZW1hbmQgZm9yIGEgZHVhbC1zdGFjayBzb2x1
dGlvbjxiciBjbGFzcz0iIj4NCmZvciBTSVAuICZuYnNwO1dpdGggdGhlIGV4Y2VwdGlvbiBvZiBh
IHBhcnRpY3VsYXIgY2FzZSwgSSBoYXZlIGZvdW5kIG5vPGJyIGNsYXNzPSIiPg0KaW50ZXJlc3Qu
PGJyIGNsYXNzPSIiPg0KQmVjYXVzZSBvZiB0aGlzLCBJIHByb3Bvc2UgdGhhdCB3ZSBuYXJyb3cg
dGhlIHNjb3BlIG9mIHRoaXMgbWlsZXN0b25lPGJyIGNsYXNzPSIiPg0KdG8gdGhlIG9uZSBjYXNl
IGZvciB3aGljaCBJIGhhdmUgZm91bmQgaW50ZXJlc3Q6PGJyIGNsYXNzPSIiPg0KUmVxdWVzdCBw
dWJsaWNhdGlvbiBvZiBhIG1lY2hhbmlzbSBmb3IgcmFwaWQgZHVhbC1zdGFjayBwcm90b2NvbDxi
ciBjbGFzcz0iIj4NCnNlbGVjdGlvbiBpbiBTSVAgd2hlbiB0aGUgZGVzdGluYXRpb24gaGFzIG11
bHRpcGxlLCB1bnByaW9yaXRpemVkPGJyIGNsYXNzPSIiPg0KdGFyZ2V0cyBmb3IgY29ubmVjdGlv
bi1vcmllbnRlZCBwcm90b2NvbHM8YnIgY2xhc3M9IiI+DQpDb252ZW5pZW50bHksIGRyYWZ0LWpv
aGFuc3Nvbi1zaXAtaGUtY29ubmVjdGlvbiBkZXNjcmliZXMgc3VjaCBhPGJyIGNsYXNzPSIiPg0K
bWVjaGFuaXNtLiAmbmJzcDtJdHMgbWVjaGFuaXNtIGNsb3NlbHkgcGFyYWxsZWxzIHRoYXQgb2Yg
UkZDIDY1NTUgKCZxdW90O0hhcHB5PGJyIGNsYXNzPSIiPg0KRXllYmFsbHMmcXVvdDspLCBhbmQg
dGhlIHRleHQgaXMgZXNzZW50aWFsbHkgY29tcGxldGUuICZuYnNwO0JlY2F1c2UgdGhlcmUgYXJl
PGJyIGNsYXNzPSIiPg0Kbm8gdW5yZXNvbHZlZCB0ZWNobmljYWwgaXNzdWVzLCB0aGUgdGV4dCBp
cyBjb21wbGV0ZSwgYW5kIHRoZXJlIGFyZTxiciBjbGFzcz0iIj4NCmtub3duIGltcGxlbWVudGF0
aW9uIGluc3RhbmNlcyB3aGVyZSB0aGlzIG1lY2hhbmlzbSBpcyBuZWVkZWQsIEkgdXJnZTxiciBj
bGFzcz0iIj4NCnRoZSBhcHByb3ZhbCBvZiB0aGlzIGRyYWZ0IGV2ZW4gaWYgaXRzIHNjb3BlIGlz
IG5hcnJvdy48YnIgY2xhc3M9IiI+DQpEYWxlPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gc2lwY29yZSBtYWlsaW5nIGxpc3QgPGEg
aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIGNsYXNzPSIiPg0Kc2lwY29yZUBpZXRmLm9y
ZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj
b3JlIiBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lw
Y29yZTwvYT48YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXyBzaXBjb3JlIG1haWxpbmcgbGlzdCA8YSBocmVmPSJtYWlsdG86c2lwY29y
ZUBpZXRmLm9yZyIgY2xhc3M9IiI+DQpzaXBjb3JlQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiIGNsYXNzPSIiPg0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxiciBjbGFzcz0i
Ij4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0Kc2lwY29yZSBtYWlsaW5nIGxp
c3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgY2xhc3M9
IiI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_ED38E7C8946F4E31AB1E14FEC90010F3ciscocom_--


From nobody Mon May 15 14:44:30 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE11124E15; Mon, 15 May 2017 14:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 Zpmo9Fk8xKlL; Mon, 15 May 2017 14:44:24 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F35129562; Mon, 15 May 2017 14:41:08 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 6ADCE1625CA; Mon, 15 May 2017 23:41:06 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4D0C94004C; Mon, 15 May 2017 23:41:06 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0339.000; Mon, 15 May 2017 23:41:05 +0200
From: 
To: Ben Campbell , SIPCORE , "dinoop.p1@gmail.com" 
CC: "sipcore-chairs@ietf.org" 
Thread-Topic: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
Thread-Index: AQHSyZxmSxn8psXz+EOWivhIX9KCV6H1lmXg
Date: Mon, 15 May 2017 21:41:04 +0000
Message-ID: <9929_1494884466_591A2072_9929_9223_1_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <20170510074449.A08C8B817E6@rfc-editor.org> 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174OPEXCLILMA4corp_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 15 May 2017 21:44:29 -0000

--_000_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174OPEXCLILMA4corp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

IMO, I don't think the errata is justified for the following reasons:
In 9.1 it is stated that if there is a missing entry (identified because th=
e R-URI doesn't match the last hi-entry received), an extra hi-entry with t=
he received R-URI content and including an index set to '0' (as described i=
n 10.3 bullet ) must be added (as described in 10.3) before proceeding sect=
ion 9.2 (i.e. before adding the normal entry with the "next" R-URI value as=
 a last entry).
So 9.1 refers to 10.3 for the index setting:
If the Request-URI of the incoming request does not match the hi
-targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
that sent the request did not include a History-Info header field),
the SIP entity MUST add an hi-entry to the end of the cache, on
behalf of the previous SIP entity. This is done as follows, before
proceeding to Section 9.2.
[...]
-The SIP entity MUST set the hi-index parameter as described in
Section 10.3.

In the given example, let's assume that the processing entity wants to forw=
ard the request to sip:marianne@example.com:

if request is received with,
            Request URI : sip:peter@example.com
            and History info :  ;index=3D1
                                                                       ;index=3D1.1
                                                                       ;index=3D1.1.1
                                                                       ;index=3D1.1.2

Then processing entity identifies that peter is not in the last hi-entry re=
ceived. So before modifying the R-URI and adding a new hi-entry with marian=
ne's address, it will reflect the gap by adding a hi-entry for peter's addr=
ess incrementing the index with ".0":
Step 1:
            History info : ;index=3D1
                                   ;index=3D1.1
                                      ;index=3D1.1.1
                                     ;index=3D1.1.2
                                     ;index=3D1.1.2.0
Step 2:
            Request URI : sip:marianne@example.com
            History info : ;index=3D1
                                   ;index=3D1.1
                                      ;index=3D1.1.1
                                     ;index=3D1.1.2
                                     ;index=3D1.1.2.0
;index=3D1.1.2.0.1


However, I agree that wording 10.3 bullet 6 could have been more clear :)

Best regards,
Marianne

De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9 : mercredi 10 mai 2017 16:48
=C0 : SIPCORE
Cc : sipcore-chairs@ietf.org
Objet : [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)

Do people have thoughts on this?

Thanks!

ben.


Begin forwarded message:

From: RFC Errata System >
Subject: [Technical Errata Reported] RFC7044 (5014)
Date: May 10, 2017 at 2:44:49 AM CDT
To: mary.ietf.barnes@gmail.com, francois=
.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com,=
 christer.holmberg@ericsson.com, ben=
@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm, br@brianrose=
n.net, mahoney@nostrum.com
Cc: dinoop.p1@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org

The following errata report has been submitted for RFC7044,
"An Extension to the Session Initiation Protocol (SIP) for Request History =
Information".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5014

--------------------------------------
Type: Technical
Reported by: Dinoop Paloli >

Section: 9.1 and 10.3

Original Text
-------------


Corrected Text
--------------


Notes
-----
Ambiguity exists regarding the handling of missing history info entry

Section 9.1 says,
          If the Request-URI of the incoming request does not match the hi
  -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
  that sent the request did not include a History-Info header field),
  the SIP entity MUST add an hi-entry to the end of the cache on
  behalf of the previous SIP entity

          According to that, for example, if request is received with,
          Request URI : sip:peter@example.com
          and History info :  ;index=3D1
                                                                     ;index=3D1.1
                                                                     ;index=3D1.1.1
                                                                     ;index=3D1.1.2

          Then processing entity has to add an history info in to cache on =
behalf of previous entity as,
          History info : ;index=3D1
              ;index=3D1.1
                                    ;index=3D1.1.1
                                    ;index=3D1.1.2
                                    ;index=3D1.1.2.1

But in section 10.3 basic rules 6 states,
                      If the request clearly has a gap in the hi-entry
      (i.e., the last hi-entry and Request-URI differ), the entity
      adding an hi-entry MUST add a single index with a value of "0"
      (i.e., the non negative integer zero) prior to adding the
      appropriate index for the action to be taken. For example, if
      the index of the last hi-entry in the request received was 1.1.2
      and there was a missing hi-entry and the request was being
      forwarded to the next hop, the resulting index will be 1.1.2.0.1.

            But as per 9.1 stated above, once an entity receive a request w=
ith missing history info
                      it has to add an entry to cache on behalf of previous=
 one.
                      So referring the previous example the added index wou=
ld be 1.1.2.1
                      And by applying the rule in 10.3, the index for the n=
ew request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
--------------------------------------
Title               : An Extension to the Session Initiation Protocol (SIP)=
 for Request History Information
Publication Date    : February 2014
Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. H=
olmberg
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core RAI
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG


___________________________________________________________________________=
______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


--_000_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174OPEXCLILMA4corp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 <=
/p>

IMO, I don=
’t think the errata is justified for the following reasons:=



In 9.1 it =
is stated that if there is a missing entry (identified because the R-URI do=
esn’t match the last hi-entry received), an extra hi-entry
 with the received R-URI content and including an index set to ‘0R=
17; (as described in 10.3 bullet ) must be added (as described in 10.3) bef=
ore proceeding section 9.2 (i.e. before adding the normal entry with the &#=
8220;next” R-URI value as a last entry).


So 9.1 ref=
ers to 10.3 for the index setting:


If the Request-URI of the incoming request =
does not match the hi


-targeted-to-uri in the last hi-entry (i.e.=
, the previous SIP entity


that sent the request did not include a His=
tory-Info header field),


the SIP entity MUST add an hi-entry to the =
end of the cache, on


behalf of the previous SIP entity. This is =
done as follows, before


proceeding to Section 9.2.


[…]


-The SIP entity MUST set the hi-index param=
eter as described in


Section 10.3.


 =
;


In the giv=
en example, let’s assume that the processing entity wants to forward =
the request to
sip:marian=
ne@example.com:


 =
;


if request is received with,

       &n=
bsp;    Request URI : sip:peter@example.com

       &n=
bsp;    and History info :  <sip:bob@example.com>;index=3D1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            
<sip:al=
ice@example>;index=3D1.1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            
<sip:jai=
n@example>;index=3D1.1.1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;            
<sip:dav=
e@example>;index=3D1.1.2



Then processing entity identifies that peter is not in the last hi-entry re=
ceived. So before modifying the R-URI and adding a new hi-entry with marian=
ne’s address, it will reflect the gap by adding a hi-entry for peter&=
#8217;s address incrementing the index with
 ".0":


Step 1:

       &n=
bsp;    History info : <sip:bob@example.com>;index=3D1

            &nb=
sp;            =
          <sip:alice@example>;index=3D1.1

       &n=
bsp;            &nbs=
p;            &=
nbsp;    <sip:jain@example>;index=
=3D1.1.1

       &n=
bsp;            =
;            &n=
bsp;    <sip:dave@example>;index=
=3D1.1.2

       &n=
bsp;            =
;            &n=
bsp;    <=
sip:peter@example.com&=
gt;;index=3D1.1.2.0


Step 2:


=
            
Request URI : sip:marianne@exam=
ple.com

       &n=
bsp;    History info : <sip:bob@example.com>;index=3D1

            &nb=
sp;            =
          <sip:alice@example>;index=3D1.1

       &n=
bsp;            &nbs=
p;            &=
nbsp;    <sip:jain@ex=
ample>;index=3D1.1.1

       &n=
bsp;            =
;            &n=
bsp;    <sip:dave@exa=
mple>;index=3D1.1.2

       &n=
bsp;            =
;            &n=
bsp;    <sip:pet=
er@example.com>;index=3D1.1.2.0


<sip:marianne@example.com>;index=3D1.1.2.0.1<=
/o:p>


 <=
/p>

 <=
/p>

However, I=
 agree that wording 10.3 bullet 6 could have been more clear
J


 =
;


Best regar=
ds,


Marianne


 =
;








De : sipc=
ore [mailto:sipcore-bounces@ietf.org]
De la part de Ben Campbell

Envoy=E9 : mercredi 10 mai 2017 16:48

=C0 : SIPCORE

Cc : sipcore-chairs@ietf.org

Objet : [sipcore] Fwd: [Technical Errata Reported] RFC7044 (501=
4)






 


Do people have thoughts on this=
?




 








Thanks!






 






ben.















Begin forwarded message:




 




From:
RFC Errata System <rfc-editor@rfc-editor.org>






Subject: [Technical Errata Reported]=
 RFC7044 (5014)






Date:
May 10, 2017 at 2:44:49 AM CDT






 






The following errata report has=
 been submitted for RFC7044,

"An Extension to the Session Initiation Protocol (SIP) for Request His=
tory Information".



--------------------------------------

You may review the report below and at:

http://www.rfc-editor.org/errata/eid5014



--------------------------------------

Type: Technical

Reported by: Dinoop Paloli <dinoop.p1@gmail.com&=
gt;



Section: 9.1 and 10.3



Original Text

-------------





Corrected Text

--------------





Notes

-----

Ambiguity exists regarding the handling of missing history info entry



Section 9.1 says,

       &n=
bsp;  If the Request-URI of the incoming request does not match=
 the hi

  -targeted-to-uri in the last hi-entry (i.e., the previous SIP e=
ntity

  that sent the request did not include a History-Info header fie=
ld),

  the SIP entity MUST add an hi-entry to the end of the cache on<=
br>
  behalf of the previous SIP entity



       &n=
bsp;  According to that, for example, if request is received wi=
th,

       &n=
bsp;  Request URI : sip:peter@example.com

       &n=
bsp;  and History info :  <sip:bob@example.com>;index=3D1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;          
<sip:al=
ice@example>;index=3D1.1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;          
<sip:jai=
n@example>;index=3D1.1.1

       &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;          
<sip:dav=
e@example>;index=3D1.1.2



       &n=
bsp;  Then processing entity has to add an history info in to c=
ache on behalf of previous entity as,

       &n=
bsp;  History info : <sip:bob@example.com&g=
t;;index=3D1

            &nb=
sp; <sip:=
alice@example>;index=3D1.1

       &n=
bsp;            &nbs=
p;             =
  <sip:jain@example>;index=3D1.1.1

       &n=
bsp;            =
;            &n=
bsp;   <sip:dave@example>;index=3D1.1=
.2

       &n=
bsp;            =
;            &n=
bsp;   <sip:peter@example.com>;in=
dex=3D1.1.2.1

       &n=
bsp;            =
;            &n=
bsp;   

But in section 10.3 basic rules 6 states,

       &n=
bsp;            =
;  If the request clearly has a gap in the hi-entry

      (i.e., the last hi-entry and Request-UR=
I differ), the entity

      adding an hi-entry MUST add a single in=
dex with a value of "0"

      (i.e., the non negative integer zero) p=
rior to adding the

      appropriate index for the action to be =
taken. For example, if

      the index of the last hi-entry in the r=
equest received was 1.1.2

      and there was a missing hi-entry and th=
e request was being

      forwarded to the next hop, the resultin=
g index will be 1.1.2.0.1.

       &n=
bsp;    

       &n=
bsp;    But as per 9.1 stated above, once an entity r=
eceive a request with missing history info

       &n=
bsp;            =
;  it has to add an entry to cache on behalf of previous one.
       &n=
bsp;            =
;  So referring the previous example the added index would be 1=
.1.2.1

       &n=
bsp;            =
;  And by applying the rule in 10.3, the index for the new requ=
est created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, ple=
ase

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party  

can log in to change the status and edit the report, if necessary. 



--------------------------------------

RFC7044 (draft-ietf-sipcore-rfc4244bis-12)

--------------------------------------

Title            &nb=
sp;  : An Extension to the Session Initiation Protocol (SIP) for =
Request History Information

Publication Date    : February 2014

Author(s)           : M. =
Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg

Category            =
: PROPOSED STANDARD

Source            &n=
bsp; : Session Initiation Protocol Core RAI

Area            &nbs=
p;   : Real-time Applications and Infrastructure

Stream            &n=
bsp; : IETF

Verifying Party     : IESG








 








______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.




--_000_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174OPEXCLILMA4corp_--


From nobody Mon May 15 23:27:16 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CAB129B39; Mon, 15 May 2017 23:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 OGc7T7CqTJDX; Mon, 15 May 2017 23:27:12 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C4412E059; Mon, 15 May 2017 23:24:07 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 3C345C2623; Tue, 16 May 2017 08:24:06 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id EC69E1C007B; Tue, 16 May 2017 08:24:05 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0339.000; Tue, 16 May 2017 08:24:05 +0200
From: 
To: "sipcore@ietf.org" , "sipcore-chairs@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-sipcore-originating-cdiv-parameter-00.txt
Thread-Index: AQHSzXtpw6uhWJqih0Km9hqAYtqogaH2d9NA
Date: Tue, 16 May 2017 06:24:05 +0000
Message-ID: <32266_1494915846_591A9B06_32266_1340_1_8B970F90C584EA4E97D5BAAC9172DBB81C9BA8EC@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <149485330526.11932.4685844116228389575.idtracker@ietfa.amsl.com>
In-Reply-To: <149485330526.11932.4685844116228389575.idtracker@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [sipcore] TR: New Version Notification for draft-ietf-sipcore-originating-cdiv-parameter-00.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 06:27:14 -0000

RllJLA0KDQpIZXJlIGlzIHRoZSAtMDAgdmVyc2lvbiBvZiB0aGUgbmV3IHNpcGNvcmUgd2cgZG9j
dW1lbnQgZHJhZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyLg0KDQpS
ZXZpZXcgYW5kIGNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMsDQpNYXJpYW5u
ZQ0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IGludGVybmV0LWRyYWZ0c0Bp
ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpFbnZvecOpwqA6IGx1
bmRpIDE1IG1haSAyMDE3IDE1OjAyDQrDgMKgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTg0KT2Jq
ZXTCoDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLXNpcGNvcmUtb3Jp
Z2luYXRpbmctY2Rpdi1wYXJhbWV0ZXItMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs
IGRyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlci0wMC50eHQNCmhh
cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWFyaWFubmUgTW9oYWxpIGFuZCBwb3N0
ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtc2lwY29yZS1v
cmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlcg0KUmV2aXNpb246CTAwDQpUaXRsZToJCUEgUC1TZXJ2
ZWQtVXNlciBIZWFkZXIgRmllbGQgUGFyYW1ldGVyIGZvciBPcmlnaW5hdGluZyBDRElWIHNlc3Np
b24gY2FzZSBpbiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkNCkRvY3VtZW50IGRh
dGU6CTIwMTctMDUtMTUNCkdyb3VwOgkJc2lwY29yZQ0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAg
ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwY29y
ZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlci0wMC50eHQNClN0YXR1czogICAgICAgICBodHRw
czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtb3JpZ2luYXRp
bmctY2Rpdi1wYXJhbWV0ZXIvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9odG1sL2RyYWZ0LWlldGYtc2lwY29yZS1vcmlnaW5hdGluZy1jZGl2LXBhcmFtZXRlci0wMA0K
SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJh
ZnQtaWV0Zi1zaXBjb3JlLW9yaWdpbmF0aW5nLWNkaXYtcGFyYW1ldGVyLTAwDQoNCg0KQWJzdHJh
Y3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhIG5ldyBwYXJhbWV0ZXIgb2YgdGhl
IFAtU2VydmVkLVVzZXINCiAgIGhlYWRlciBmaWVsZCBpbiB0aGUgU2Vzc2lvbiBJbml0aWF0aW9u
IFByb3RvY29sIChTSVApLiAgVGhpcyBuZXcNCiAgICJvcmlnLWNkaXYiIHBhcmFtZXRlciBkZWZp
bmVzIHRoZSBzZXNzaW9uIGNhc2UgdXNlZCBieSBhIHByb3h5IHdoZW4NCiAgIGhhbmRsaW5nIGFu
IG9yaWdpbmF0aW5nIHNlc3Npb24gYWZ0ZXIgQ2FsbCBEaXZlcnNpb24gKENESVYpIHNlcnZpY2Vz
DQogICBoYXMgYmVlbiBpbnZva2VkIGZvciB0aGUgc2VydmVkIHVzZXIuICBUaGUgUC1TZXJ2ZWQt
VXNlciBoZWFkZXIgZmllbGQNCiAgIGlzIGRlZmluZWQgaW4gUkZDNTUwMiB0byBjb252ZXkgdGhl
IGlkZW50aXR5IG9mIHRoZSBzZXJ2ZWQgdXNlciBhbmQNCiAgIHRoZSBzZXNzaW9uIGNhc2UgdGhh
dCBhcHBsaWVzIHRvIHRoaXMgcGFydGljdWxhciBjb21tdW5pY2F0aW9uDQogICBzZXNzaW9uIGFu
ZCBhcHBsaWNhdGlvbiBpbnZvY2F0aW9uLiAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQzU1MDIg
dG8NCiAgIGFkZCB0aGUgIm9yaWdpbmF0aW5nIGFmdGVyIENESVYiIHNlc3Npb24gY2FzZSBhbmQg
dG8gcHJvdmlkZSBtb3JlDQogICBndWlkYW5jZSBmb3IgdXNpbmcgdGhlIFAtU2VydmVkLVVzZXIg
aGVhZGVyIGZpZWxkIGluIElQIG5ldHdvcmtzIHRoYXQNCiAgIHdlcmUgbWlzc2luZyBpbiBSRkM1
NTAyLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp
dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv
biB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv
b2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoKX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz
c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp
b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv
aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs
dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh
Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn
ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl
Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk
IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u
LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5
IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5
b3UuCgo=


From nobody Tue May 16 01:25:30 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C51129462; Tue, 16 May 2017 01:25:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level: 
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 EL9BXHSJuTZn; Tue, 16 May 2017 01:25:26 -0700 (PDT)
Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8B412922E; Tue, 16 May 2017 01:21:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1494922883; x=1526458883; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lZmZ/Dl6RVTojb6nLXEq7cdAF/dCqIhEmTF9E/8H7ek=; b=Smlgo81o+EdKqHaQVkCxx+ELnVn2jJVQ/8pYKk6JndXv1mjwvqHfOW7N mi9jVZlPhVR51ciAo3iKZ/6rx7CylISPcNl6lIdPlGui3caxHVW1oBbl/ h8HCd91DWqpBY3jA1ulBQBzuY2FeVaiI689Ref+uHi0olSF3EvgBltmmp KFPwwcMk6o8v0jBje6MHYZnVlzorZHJsuhTHDRnKPELyrYTNrK1Yc4iqK S6VGZhPiz+noxM3hcggEsStFI84XmZE11bHSll9YbN+Rlx+yguPQwh67E gk1A6bJgRTsmtHgOWpiksgNMPxdBId6xUYFb1cy9TpZutgPodP5af754a Q==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2017 10:21:20 +0200
X-IronPort-AV: E=Sophos;i="5.38,348,1491256800"; d="scan'208";a="670693475"
Received: from he105829.emea1.cds.t-internal.com ([10.169.119.32]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 16 May 2017 10:20:50 +0200
Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105829.emea1.cds.t-internal.com (10.169.119.32) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 16 May 2017 10:20:43 +0200
Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1263.000; Tue, 16 May 2017 10:20:43 +0200
From: 
To: , , 
Thread-Topic: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item?
Thread-Index: AQHSrwlDmCU3KpZp80eHca9RBdNfoKHvsqeAgAcn7aA=
Date: Tue, 16 May 2017 08:20:43 +0000
Message-ID: <7a89567439a94b55864a9c267d374f0f@HE105828.emea1.cds.t-internal.com>
References: <6222bd21-f1b1-88a2-5afd-1c85825a9bac@nostrum.com> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.213.223.186]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sipcore] draft-jesske-sipcore-reason-q850-loc - WG item?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 08:25:29 -0000

SGkgSmVhbiwNCmRvY3VtZW50IGlzIHVwbG9hZGVkLg0KDQpEYXRhdHJhY2tlciBVUkw6IGh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNpcGNvcmUtcmVhc29uLXE4NTAtbG9j
Lw0KDQpDb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVzdCBSZWdhcmRzDQoNClJvbGFuZA0KDQo+
IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBBLiBKZWFuIE1haG9u
ZXkgW21haWx0bzptYWhvbmV5QG5vc3RydW0uY29tXQ0KPiBHZXNlbmRldDogRG9ubmVyc3RhZywg
MTEuIE1haSAyMDE3IDIyOjU3DQo+IEFuOiBzaXBjb3JlQGlldGYub3JnOyBkcmFmdC1qZXNza2Ut
c2lwY29yZS1yZWFzb24tcTg1MC1sb2NAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IFtzaXBjb3Jl
XSBkcmFmdC1qZXNza2Utc2lwY29yZS1yZWFzb24tcTg1MC1sb2MgLSBXRyBpdGVtPw0KPiANCj4g
SGkgYWxsLA0KPiANCj4gVGhlcmUgaXMgY29uc2Vuc3VzIGZvciB0YWtpbmcgdGhpcyBkcmFmdCBv
biBhcyBhIFdHIGl0ZW0uDQo+IA0KPiBSb2xhbmQsIHBsZWFzZSBzdWJtaXQgYSBXRyAtMDAgZHJh
ZnQuDQo+IA0KPiBUaGFua3MhDQo+IA0KPiBKZWFuDQo+IA0KPiANCj4gT24gNC82LzE3IDI6MDgg
UE0sIEEuIEplYW4gTWFob25leSB3cm90ZToNCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBEdXJpbmcg
dGhlIFdHIHNlc3Npb24gaW4gQ2hpY2FnbywgUm9sYW5kIHByZXNlbnRlZCB0aGlzIGRyYWZ0LCBh
bmQgdGhlDQo+ID4gY2hhaXJzIHRvb2sgYSBodW0gb24gd2hldGhlciB0aGUgV0cgc2hvdWxkIHRh
a2Ugb24gdGhpcyBkcmFmdCBhcyBhIFdHDQo+IGl0ZW0uDQo+ID4NCj4gPiBUaGVyZSB3YXMgY29u
c2Vuc3VzIGF0IHRoZSBtZWV0aW5nIHRvIHRha2UgdGhpcyBkcmFmdCBvbi4gTm93IEknbQ0KPiA+
IGdhdWdpbmcgaW50ZXJlc3Qgb24gdGhlIG1haWxpbmcgbGlzdC4gUGxlYXNlIGxldCB0aGUgbGlz
dCBrbm93IGlmIHlvdQ0KPiA+IGhhdmUgYW55IG9iamVjdGlvbnMgdG8gdGFraW5nIHRoaXMgd29y
ayBvbi4NCj4gPg0KPiA+IFRoYW5rcyENCj4gPg0KPiA+IEplYW4NCj4gPg0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2lwY29yZSBtYWls
aW5nIGxpc3QNCj4gPiBzaXBjb3JlQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo=


From nobody Tue May 16 01:53:20 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF112E059 for ; Tue, 16 May 2017 01:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.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 FOIGtB9QHMmr for ; Tue, 16 May 2017 01:53:17 -0700 (PDT)
Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377DA129C20 for ; Tue, 16 May 2017 01:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bjCqXY0/5GqCj9/ZHHmDB06Vp/2tsbziV6wg1nevum0=; b=QDmZiWw+Hz9w8AJwsNdQyhJRJ96dmbdUWbu+OTM+kDiYSNj44JaAudJOJDFdl8qwwHCUZk9dEwF87GkTJWMQCNXkXqgwwsiQQqjw2o13LfPh3JC8TYkQxhVnShTbM3tO3Dg2UptzxJX6vlIccQtgUPZxqBs6bXKWHUKEScTcvnM=
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp0178.outbound.protection.outlook.com [216.32.181.178]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-60-em8cf_CyPLyPKepOjdUdtw-1; Tue, 16 May 2017 04:50:00 -0400
Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2344.namprd03.prod.outlook.com (10.166.93.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.16; Tue, 16 May 2017 08:49:55 +0000
Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.1084.029; Tue, 16 May 2017 08:49:56 +0000
From: "Asveren, Tolga" 
To: Henning Schulzrinne , "sipcore@ietf.org" 
Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
Thread-Index: AQHSybceweZbMlDQ40iYNcpH4crOaqH1P1oAgACQV4CAAN4b4A==
Date: Tue, 16 May 2017 08:49:55 +0000
Message-ID: 
References: <149443909999.16637.11197197582450340705@ietfa.amsl.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [73.29.18.75]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CO2PR03MB2344; 7:7fTREMcOp6eeBWU7f23vCR/TJ3RnFYqs24KxLlAhSTIz9Zf4GS3+SRQdCjIXVkw4k60scrmB5G1knQ/y/Pfe583nGJ9M8jzAILhYdk+s1DbYmsBZ+LoD6D6U8XmaHjnAhaZngX19H4+5AgPacZQgeI4lugZ2s11fE5TCDIm2ypxpV56/WL4lGKr4VOXDHLXpcHhegoG8G6Qmm0izAnNrFZMQS78cpT5DiiEMULlGKObh8Y30aLrX9+NPZapqdvqQ3Fqc9pDFibT45m84hQjYaP9M5oDroD+lQ8PBl0vK4YAxzkk/0t7UGIyiztlWeMT15kUCBywmCXceYzLS5kbeLg==; 20:umsv+DugpH0Q5Zopxz+1XGdRN8z38wSDQ74Eo2thlj0KsU7M9J9p/unuBd0SkqQIZmQKhBuJ9yYiajWFPpjuoXLJWwi23B3Ahuuu9nxbTXAtPzy9RBF9EuQ/HhWceowqcqd+1pzk+NSk6h4q8Bqs33ciLMsV9cCxMvHrihTt74s=
x-ms-office365-filtering-correlation-id: ac386d4f-70de-469e-8a00-08d49c3886ee
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CO2PR03MB2344; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(6072148); SRVR:CO2PR03MB2344; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2344; 
x-forefront-prvs: 03094A4065
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39830400002)(39450400003)(39410400002)(13464003)(377424004)(377454003)(305945005)(7736002)(2950100002)(74316002)(575784001)(3660700001)(3280700002)(86362001)(2906002)(25786009)(53546009)(81166006)(33656002)(2900100001)(8676002)(38730400002)(2501003)(5660300001)(6246003)(189998001)(122556002)(229853002)(478600001)(76176999)(6116002)(6436002)(102836003)(6306002)(99286003)(55016002)(7696004)(54356999)(77096006)(50986999)(6506006)(66066001)(9686003)(3846002)(8936002)(53936002)(966005)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2344; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2017 08:49:56.0222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2344
X-MC-Unique: em8cf_CyPLyPKepOjdUdtw-1
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 08:53:20 -0000

Henning,

I am not claiming that there are disagreements about these topics within ac=
tive participants. I merely was stating that some clarifications in the tex=
t could be beneficial for future readers -as we have seen during recent rev=
iews by non-insiders that some confusion arose-.

Having said that, I wouldn't consider the current version as "requires some=
 fixes". It can proceed to become a RFC IMHO even if you prefer not to add =
any clarifications.=20

Thanks,
Tolga

-----Original Message-----
From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20
Sent: Monday, May 15, 2017 3:29 PM
To: Asveren, Tolga ; sipcore@ietf.org
Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.tx=
t

Tolga,

Given that both points have been discussed many times before, I'm reluctant=
 to open those issues again.

On the second issue, 607 is useless if it is has no (potential, statistical=
, etc.) influence on future calls. The called party indicates that they did=
n't want to receive that call and don't want to be called again by the same=
 party, either. I won't repeat the usual caveats we discussed about phone n=
umber changes and such, as those are covered in the document.

Henning

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga
Sent: Monday, May 15, 2017 7:02 AM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.tx=
t

Looks good to me with just a few comments (or rants, if you will):=20

i- =20
"The user agent of
   the called party, based on input from the called party or some UA-
   internal logic, uses this to indicate that this call is unwanted and
   that future attempts are likely to be similarly rejected."

FWIW, I really feel uneasy about the "or some UA-internal logic" part of th=
e first sentence.

ii-
"As discussed in Section 6, reversing
   the 'unwanted' labeling is beyond the scope of this mechanism, as it
   will likely require a mechanism other than call signaling."

This could be a great place to add a statement that this response code pert=
ains only to a single call and does not mean that the end-user has a desire=
 for blocking the called party permanently. This really would add great val=
ue to prevent misinterpretation of 607 IMHO.

Thanks,
Tolga

-----Original Message-----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft=
s@ietf.org
Sent: Wednesday, May 10, 2017 1:58 PM
To: i-d-announce@ietf.org
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Session Initiation Protocol Core of the IE=
TF.

        Title           : A SIP Response Code for Unwanted Calls
        Author          : Henning Schulzrinne
=09Filename        : draft-ietf-sipcore-status-unwanted-06.txt
=09Pages           : 8
=09Date            : 2017-05-10

Abstract:
   This document defines the 607 (Unwanted) SIP response code, allowing
   called parties to indicate that the call or message was unwanted.
   SIP entities may use this information to adjust how future calls from
   this calling party are handled for the called party or more broadly.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org=
_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDwICAg&c=3Dy0h0omCe0jA=
UGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq=
8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3Dd8nMGqUjgAnZr_F7bIVtTr4QNXYDwuKhpd6reL=
MfaFI&e=3D=20

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_=
draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0h0omCe0jAU=
Gr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8=
US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3D4ftlZWWq_Hroo1UNfrl1kVXt9I3mDp51YByQsyr=
oCuQ&e=3D=20
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org=
_doc_html_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0=
h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y=
_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DaWXdzCCYLm7gAYjKWeWD6xmTkVdy1=
I3tFq-3Gny_FzI&e=3D=20

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_rfcdiff=
-3Furl2-3Ddraft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D06&d=3DDwICAg&c=3Dy0=
h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y=
_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DIhmck2y6dNA28nzmCASmi7n6k1_hX=
xgBHjNW4bzKygg&e=3D=20


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-=
2Ddrafts_&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU=
1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vwE&s=3DXl=
dJkTgvhflTtLhcALaRywRr9dfZ4EMWx8lz7DvBVxg&e=3D=20

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV=
0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vw=
E&s=3D_turveVqD0DjvCoQs9ycbZrozjiAWjtJK3Jsl0uT13k&e=3D=20

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_sipcore&d=3DDwICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV=
0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D3y_KHNXo2fq8US-YtsrOVp8ZLkP5SpfX9k73qs25vw=
E&s=3D_turveVqD0DjvCoQs9ycbZrozjiAWjtJK3Jsl0uT13k&e=3D=20


From nobody Tue May 16 02:07:45 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ACE1293F4; Tue, 16 May 2017 02:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level: 
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 CBdKYwkgJi6l; Tue, 16 May 2017 02:07:40 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 8FD2612EAE7; Tue, 16 May 2017 02:03:19 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id k74so121880367qke.1; Tue, 16 May 2017 02:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gaWYNJ+xMjp//nTtz17JDjoryttPvzhgQK/BwH6wmb0=; b=Thfs75a+ufsc6gd3lV/jcah6Q94rz/8gYw/VzrEcTJrqp6iNTX//DLm5SgnJw2nCfG FmuLc796ONXhr1rdas+f+XtLDx4jIqAb+uiJlBmgWApZTATCUGj5uwNgjgoo9Jqe9V+o 1Xo0nMXXfk4fe99IaiEy3wzPLYf3IchvkoB6B5cydRB+lIS5VCSoV9FAeQf5AdFQUh7i TSFe9c9Xtx1LlEUSc/dSAgn/N/8MsecYSwg3WeJPa26sxQSVg96xfGg+rjuo188KMTpU mlfFkZUWs1Z6X8SNka4ILjsypfG2yB+I6qhXLdK+fM7S0mc9gPoRjhl4PQbpvTJ0dQYi agfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gaWYNJ+xMjp//nTtz17JDjoryttPvzhgQK/BwH6wmb0=; b=CcYK60zIFiJrwbq9IkYaKl6Qn63IqsdNfu1UvFu8d6di4UiN7oK92AVAwkjsLlj7cY m2cFPRB73nSXLodQXINrDJcD7kn+hRGI0Jhja2U9shOiEs2IWQsceih6HNHqfkMaGuqK gGOhtpgA/ICSnRR9ziWiAE+RDwi7IB9JxKqf/4GSEAAc8PZOWgzDfqM7/ZihLb738452 CCpSSj1Wg0kf9Gt3eO6tqlxpm0dXERvLKPQgqkkS6T70WDI3Rp2/1mNGToO+UeH9ucLr XMAv48AjS9Pc18pjfknXzCHlFC20ALI68I2+D7ubsrJBQm+jaorMbmDrmpAinB7Hi6WN Xi4A==
X-Gm-Message-State: AODbwcCtJFYI9vgBiwcjtSRnWjK/ANWH2GhbZ0xbJ127beGSYFAf6dUI V76ozPjdOyrDVQKTjlPkNQlZZGC5yw==
X-Received: by 10.80.178.131 with SMTP id p3mr7927081edd.96.1494925398567; Tue, 16 May 2017 02:03:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.181.229 with HTTP; Tue, 16 May 2017 02:02:58 -0700 (PDT)
In-Reply-To: <9929_1494884466_591A2072_9929_9223_1_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <20170510074449.A08C8B817E6@rfc-editor.org>  <9929_1494884466_591A2072_9929_9223_1_8B970F90C584EA4E97D5BAAC9172DBB81C9BA174@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
From: Dinoop 
Date: Tue, 16 May 2017 14:32:58 +0530
Message-ID: 
To: marianne.mohali@orange.com
Cc: Ben Campbell , SIPCORE ,  "sipcore-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045c7f6458f233054fa0714f"
Archived-At: 
Subject: Re: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 09:07:44 -0000

--f403045c7f6458f233054fa0714f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Marianne,

Thanks for the crystal clear explanation. Now I understood the matter.

Also as you said , The  section 10.3 - part 6 , can be interpreted wrongly
as "the gap has to be filled with R-URI and index 1.1.2.0.1". Because it is
not specifically mentioning that the index of hi-entry uri should be
1.1.2.0.

I don't know  whether discussing about the RFC  7131 (History-info call
flows)  is appropriate over here, but since it is very  much related to
above query , I am including those.

In section   3.1. Sequentially Forking , the history info header in message
contains 4 history-info headers such as,

   History-Info: ;index=3D1
   History-Info: ;index=3D1.1=
;rc=3D1
   History-Info: ;index=3D1.2;mp=3D1
   History-Info: ;index=3D1.2.1;rc=3D1.2


My doubts are ,

1) As per the example , request is targeted to office@192.0.2.5 directly,

   in this case why 3rd history info entry is added?. As per the RFC,

   History info is added based on the request URI of new request. If
it is as per standards,

   Can you please mention the RFC, where it is mentioned.

2) The last history-entry is having index 1.2.1, but as the "dot"
represents the new hop, it should be 1.3 right?

why additional "dot" has been added? Can you please point the RFC
describes this behavior?








On Tue, May 16, 2017 at 3:11 AM,  wrote:

> Hi,
>
>
>
> IMO, I don=E2=80=99t think the errata is justified for the following reas=
ons:
>
> In 9.1 it is stated that if there is a missing entry (identified because
> the R-URI doesn=E2=80=99t match the last hi-entry received), an extra hi-=
entry with
> the received R-URI content and including an index set to =E2=80=980=E2=80=
=99 (as described
> in 10.3 bullet ) must be added (as described in 10.3) before proceeding
> section 9.2 (i.e. before adding the normal entry with the =E2=80=9Cnext=
=E2=80=9D R-URI
> value as a last entry).
>
> So 9.1 refers to 10.3 for the index setting:
>
> If the Request-URI of the incoming request does not match the hi
>
> -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
>
> that sent the request did not include a History-Info header field),
>
> the SIP entity MUST add an hi-entry to the end of the cache, on
>
> behalf of the previous SIP entity. This is done as follows, before
>
> proceeding to Section 9.2.
>
> [=E2=80=A6]
>
> -The SIP entity MUST set the hi-index parameter as described in
>
> Section 10.3.
>
>
>
> In the given example, let=E2=80=99s assume that the processing entity wan=
ts to
> forward the request to sip:marianne@example.com:
>
>
>
> if request is received with,
>             Request URI : sip:peter@example.com
>             and History info :  ;index=3D1
>                                                                        <
> sip:alice@example>;index=3D1.1
>                                                                        <
> sip:jain@example>;index=3D1.1.1
>                                                                        <
> sip:dave@example>;index=3D1.1.2
>
> Then processing entity identifies that peter is not in the last hi-entry
> received. So before modifying the R-URI and adding a new hi-entry with
> marianne=E2=80=99s address, it will reflect the gap by adding a hi-entry =
for
> peter=E2=80=99s address incrementing the index with ".0":
>
> Step 1:
>             History info : ;index=3D1
>                                    ;index=3D1.1
>                                       ;index=3D1.1.1
>                                      ;index=3D1.1.2
>                                      ;index=3D1.1.=
2.0
>
> Step 2:
>
>             Request URI : sip:marianne@example.com
>             History info : ;index=3D1
>                                    ;index=3D1.1
>                                       ;index=3D1.1.1
>                                      ;index=3D1.1.2
>                                      ;index=3D1.1.=
2.0
>
> ;index=3D1.1.2.0.1
>
>
>
>
>
> However, I agree that wording 10.3 bullet 6 could have been more clear J
>
>
>
> Best regards,
>
> Marianne
>
>
>
> *De :* sipcore [mailto:sipcore-bounces@ietf.org] *De la part de* Ben
> Campbell
> *Envoy=C3=A9 :* mercredi 10 mai 2017 16:48
> *=C3=80 :* SIPCORE
> *Cc :* sipcore-chairs@ietf.org
> *Objet :* [sipcore] Fwd: [Technical Errata Reported] RFC7044 (5014)
>
>
>
> Do people have thoughts on this?
>
>
>
> Thanks!
>
>
>
> ben.
>
>
>
> Begin forwarded message:
>
>
>
> *From: *RFC Errata System 
>
> *Subject: [Technical Errata Reported] RFC7044 (5014)*
>
> *Date: *May 10, 2017 at 2:44:49 AM CDT
>
> *To: *mary.ietf.barnes@gmail.com, francois.audet@skype.net,
> shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com=
,
> ben@nostrum.com, alissa@cooperw.in, aamelnikov@fastmail.fm,
> br@brianrosen.net, mahoney@nostrum.com
>
> *Cc: *dinoop.p1@gmail.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
>
>
>
> The following errata report has been submitted for RFC7044,
> "An Extension to the Session Initiation Protocol (SIP) for Request Histor=
y
> Information".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata/eid5014
>
> --------------------------------------
> Type: Technical
> Reported by: Dinoop Paloli 
>
> Section: 9.1 and 10.3
>
> Original Text
> -------------
>
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> Ambiguity exists regarding the handling of missing history info entry
>
> Section 9.1 says,
>           If the Request-URI of the incoming request does not match the h=
i
>   -targeted-to-uri in the last hi-entry (i.e., the previous SIP entity
>   that sent the request did not include a History-Info header field),
>   the SIP entity MUST add an hi-entry to the end of the cache on
>   behalf of the previous SIP entity
>
>           According to that, for example, if request is received with,
>           Request URI : sip:peter@example.com
>           and History info :  ;index=3D1
>                                                                      <
> sip:alice@example>;index=3D1.1
>                                                                      <
> sip:jain@example>;index=3D1.1.1
>                                                                      <
> sip:dave@example>;index=3D1.1.2
>
>           Then processing entity has to add an history info in to cache
> on behalf of previous entity as,
>           History info : ;index=3D1
>               ;index=3D1.1
>                                     ;index=3D1.1.1
>                                     ;index=3D1.1.2
>                                     ;index=3D1.1.2=
.1
>
> But in section 10.3 basic rules 6 states,
>                       If the request clearly has a gap in the hi-entry
>       (i.e., the last hi-entry and Request-URI differ), the entity
>       adding an hi-entry MUST add a single index with a value of "0"
>       (i.e., the non negative integer zero) prior to adding the
>       appropriate index for the action to be taken. For example, if
>       the index of the last hi-entry in the request received was 1.1.2
>       and there was a missing hi-entry and the request was being
>       forwarded to the next hop, the resulting index will be 1.1.2.0.1.
>
>             But as per 9.1 stated above, once an entity receive a request
> with missing history info
>                       it has to add an entry to cache on behalf of
> previous one.
>                       So referring the previous example the added index
> would be 1.1.2.1
>                       And by applying the rule in 10.3, the index for the
> new request created by this entity would be 1.1.2.1.0.1 not 1.1.2.0.1
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7044 (draft-ietf-sipcore-rfc4244bis-12)
> --------------------------------------
> Title               : An Extension to the Session Initiation Protocol
> (SIP) for Request History Information
> Publication Date    : February 2014
> Author(s)           : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C.
> Holmberg
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol Core RAI
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
>
>
>
> _________________________________________________________________________=
________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confid=
entielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme o=
u falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged i=
nformation that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and de=
lete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have bee=
n modified, changed or falsified.
> Thank you.
>
>


--=20
Thanks & Regards
Dinoop p

--f403045c7f6458f233054fa0714f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi=C2=A0Marianne,<=
div>
Thanks for the=
 crystal=C2=A0clear explanation. Now I understood the matter.=


A=
lso as you said , The =C2=A0section 10.3 - part 6 , can be interpreted wron=
gly as "the gap has to be filled with R-URI and index 1.1.2.0.1".=
 Because it is not specifically mentioning that the index of hi-entry uri s=
hould be=C2=A01.1.2.0.
<=
span style=3D"color:rgb(31,73,125);font-family:calibri,sans-serif;font-size=
:14.6667px">
I don't know =C2=A0whet=
her discussing about the RFC =C2=A07131 (History-info call flows) =C2=A0is =
appropriate over here, but since it is very =C2=A0much related to above que=
ry , I am including those.

In section=C2=A0=C2=A0 3.1. =
Sequentially Forking , the history info header in message contains 4 histor=
y-info headers such as,

   History-Info: <sip:b=
ob@example.com>;index=3D1
   History-Info: <sip:bob@192.0.2.4?Reason=3DSIP%3Bcause%3D302>;index=3D1.1;=
rc=3D1
   History-Info: <sip:office=
@example.com>;index=3D1.2;mp=3D1
   History-Info: <sip:office@1=
92.0.2.5>;index=3D1.2.1;rc=3D1.2

My doubts are ,
1) As per the example , request is targeted to =
office@192.0.2.5 directly,
   in this case why 3rd history info entry i=
s added?. As per the RFC,
   History=
 info is added based on the request URI of new request. If it is as per sta=
ndards,
   Can you please mention th=
e RFC, where it is mentioned.
2) The=
 last history-entry is having index 1.2.1, but as the "dot" repre=
sents the new hop, it should be 1.3 right?
why additional "dot" has been added? Can you please point =
the RFC describes this behavior?

=





On Tue, May 16, 2017 at 3:11 AM,  <marianne.mohali@orange=
.com> wrote:











Hi,


=C2=A0


IMO, I don=E2=80=99t think th=
e errata is justified=C2=A0for the following reasons:<=
/p>

In 9.1 it is stated that if t=
here is a missing entry (identified because the R-URI doesn=E2=80=99t match=
 the last hi-entry received), an extra hi-entry
 with the received R-URI content and including an index set to =E2=80=980=
=E2=80=99 (as described in 10.3 bullet ) must be added (as described in 10.=
3) before proceeding section 9.2 (i.e. before adding the normal entry with =
the =E2=80=9Cnext=E2=80=9D R-URI value as a last entry).


So 9.1 refers to 10.3 for the=
 index setting:


If the Request-URI of the incoming request =
does not match the hi


-targeted-to-uri in the last hi-entry (i.e.=
, the previous SIP entity


that sent the request did not include a His=
tory-Info header field),


the SIP entity MUST add an hi-entry =
to the end of the cache, on


behalf of the previous SIP entity. This is =
done as follows, before


proceeding to Section 9.2.


[=E2=80=A6]


-The SIP entity MUST set the hi-index param=
eter as described in


Section 10.3.


=C2=A0

In the given example, let=E2=
=80=99s assume that the processing entity wants to forward the request to
sip:marianne@example.com:


=C2=A0

if reque=
st is received with,

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Request URI : sip:peter@example.com

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and History info=
 : =C2=A0<sip:bob@example.com<=
span lang=3D"EN-US">>;index=3D1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:alice@example>;index=3D1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:jain@example>;index=3D1.1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:dave@example>;index=3D1.1.2



Then processing entity identifies that peter is not in the last hi-entry re=
ceived. So before modifying the R-URI and adding a new hi-entry with marian=
ne=E2=80=99s address, it will reflect the gap by adding a hi-entry for pete=
r=E2=80=99s address incrementing the index with
 ".0":


Step 1:

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 History info : &=
lt;sip:bob@example.com>;index=3D1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <<=
span lang=3D"EN-US">sip:alice@example>;i=
ndex=3D1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:jain@example>;=
index=3D1.1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<=
sip:dave@example>=
;;index=3D1.1.2

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<=
sip:peter@example.com>;index=3D1.1.2.0


Step 2:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 
Request URI : sip:marianne@example.com=


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 History info : &=
lt;sip:bob@example.com>;index=3D1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <sip:alic=
e@example>;index=3D1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:ja=
in@example>;index=3D1.1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:=
dave@example>;index=3D1.1.2

=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<<=
a>sip:peter@example.com>;index=3D1.1.2.0


<sip:marianne@ex=
ample.com>;index=3D1.1.2.0.1


=C2=A0


=C2=A0


However, I agree that wording=
 10.3 bullet 6 could have been more clear
J

=C2=A0

Best regards,


Marianne=



=C2=A0







De=C2=A0: sipcore [mailto:sipcore-bounces@ietf.org]
De la part de Ben Campbell

Envoy=C3=A9=C2=A0: mercredi 10 mai 2017 16:48

=C3=80=C2=A0: SIPCORE

Cc=C2=A0: sipcore-chairs@ietf.org

Objet=C2=A0: [sipcore] Fwd: [Technical Errata Reported] RFC7044 (501=
4)






=C2=A0


Do people have thoughts on this=
?




=C2=A0








Thanks!





=C2=A0






ben.















Begin forwarded message:=





=C2=A0




From:
=
RFC Errata System <rfc-editor@rfc-editor.org>






Subject: [Technical Errata Reported] RFC7044 (5014)






Date:
=
May 10, 2017 at 2:44:49 AM CDT







=C2=A0






The following errata report has=
 been submitted for RFC7044,

"An Extension to the Session Initiation Protocol (SIP) for Request His=
tory Information".



--------------------------------------

You may review the report below and at:

http://www.rfc-editor.org/errata/eid5014



--------------------------------------

Type: Technical

Reported by: Dinoop Paloli <dinoop.p1@gmail.com>



Section: 9.1 and 10.3



Original Text

-------------





Corrected Text

--------------





Notes

-----

Ambiguity exists regarding the handling of missing history info entry



Section 9.1 says,

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the Request-URI of the in=
coming request does not match the hi

=C2=A0=C2=A0-targeted-to-uri in the last hi-entry (i.e., the previous SIP e=
ntity

=C2=A0=C2=A0that sent the request did not include a History-Info header fie=
ld),

=C2=A0=C2=A0the SIP entity MUST add an hi-entry to the end of the cache on<=
br>
=C2=A0=C2=A0behalf of the previous SIP entity



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 According to that, for examp=
le, if request is received with,

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Request URI : sip:peter@example.com

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and History info : =C2=A0<=
;sip:bob@example.com>;index=3D1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:alice@example>;index=3D1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:jain@example>;index=3D1.1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
<sip:dave@example>;index=3D1.1.2



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Then processing entity has t=
o add an history info in to cache on behalf of previous entity as,

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 History info : <sip:bob@example.com&g=
t;;index=3D1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<sip:alice@example>;index=3D1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:jain@example>;index=3D1.<=
wbr>1.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:dave@example>;inde=
x=3D1.1.2

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<sip:peter@example.com>=
;index=3D1.1.2.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0

But in section 10.3 basic rules 6 states,

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the request clearly has a ga=
p in the hi-entry

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(i.e., the last hi-entry and Request-UR=
I differ), the entity

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0adding an hi-entry MUST add a single in=
dex with a value of "0"

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(i.e., the non negative integer zero) p=
rior to adding the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0appropriate index for the action to be =
taken. For example, if

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the index of the last hi-entry in the r=
equest received was 1.1.2

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0and there was a missing hi-entry and th=
e request was being

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0forwarded to the next hop, the resultin=
g index will be 1.1.2.0.1.

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0But as per 9.1 s=
tated above, once an entity receive a request with missing history info

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it has to add an entry to cache=
 on behalf of previous one.

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 So referring the previous examp=
le the added index would be 1.1.2.1

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 And by applying the rule in 10.=
3, the index for the new request created by this entity would be 1.1.2.1.0.=
1 not 1.1.2.0.1



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, ple=
ase

use "Reply All" to discuss whether it should be verified or

rejected. When a decision is reached, the verifying party =C2=A0

can log in to change the status and edit the report, if necessary. 



--------------------------------------

RFC7044 (draft-ietf-sipcore-rfc4244bis-12)

--------------------------------------

Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0: An Extension to the Session Initiation Protocol (SIP) for =
Request History Information

Publication Date =C2=A0=C2=A0=C2=A0: February 2014

Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: M. =
Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg

Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
: PROPOSED STANDARD

Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0: Session Initiation Protocol Core RAI

Area =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0: Real-time Applications and Infrastructure

Stream =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0: IETF

Verifying Party =C2=A0=C2=A0=C2=A0=C2=A0: IESG








=C2=A0








____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.







-- 
Thanks & Regards
Dinoop p





--f403045c7f6458f233054fa0714f--


From nobody Tue May 16 10:10:00 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E98129C43; Tue, 16 May 2017 10:09:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149495459455.6596.1379873814347517006@ietfa.amsl.com>
Date: Tue, 16 May 2017 10:09:54 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-reason-q850-loc-00.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 17:09:55 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : ISUP Cause Location Parameter for the SIP Reason Header Field
        Author          : Roland Jesske
	Filename        : draft-ietf-sipcore-reason-q850-loc-00.txt
	Pages           : 5
	Date            : 2017-05-16

Abstract:
   The SIP Reason header field is defined for carrying ISUP cause values
   as well as SIP response codes.  Some services in SIP networks may
   need to know the ISUP location where the call was released in the
   PSTN network to correctly interpret the reason of release.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-reason-q850-loc/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-reason-q850-loc-00
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-reason-q850-loc-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue May 16 14:13:47 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAF112F27B; Tue, 16 May 2017 14:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.821
X-Spam-Level: 
X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 XMC3JquOFyeO; Tue, 16 May 2017 14:13:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2AE3412ACAF; Tue, 16 May 2017 14:09:06 -0700 (PDT)
Received: from [10.0.2.253] (ip-7-232-239-173.texas.us.northamericancoax.com [173.239.232.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4GL94x6065665 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 May 2017 16:09:05 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-7-232-239-173.texas.us.northamericancoax.com [173.239.232.7] claimed to be [10.0.2.253]
From: Ben Campbell 
Content-Type: multipart/alternative; boundary=Apple-Mail-B821791D-CD78-49D6-9BD9-6F98B231AF1C
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Tue, 16 May 2017 17:09:04 -0400
Message-Id: 
To: draft-ietf-sipcore-content-id.all@ietf.org, sipcore@ietf.org
X-Mailer: iPad Mail (14E304)
Archived-At: 
Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:13:46 -0000

--Apple-Mail-B821791D-CD78-49D6-9BD9-6F98B231AF1C
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some po=
ints I would like discuss before going to IETF last call.

Note: I plan to request an Art-Art review on this draft to focus on the MIME=
 usage aspects.

Thanks!

Ben.

Discussion Points:

- I have some difficulty seeing the difference between "the body and related=
 metadata" and "the SIP message". I realize you have the more MIME-specific h=
eader fields in mind when you say "metadata". But any SIP header field could=
 be considered metadata.

The main point of that question is, as used in MIME, Content-Id is intended t=
o label a body part. Message-Id is used to label the whole message. Aren't w=
e talking about the whole message here?

- Is there an expectation for the SIP Content-ID header field value to be re=
ferenced from outside the SIP message? If so, what are the uniqueness expect=
ations? Note that for MIME, Content-ID is expected to be globally unique. Is=
 that the case here?

If the Content-ID is _not_ expected to be referenced from outside of the SIP=
 message that contains it, then we have a sort of degenerate case where it a=
lways identifies _this_ message regardless of the value. Does that value eve=
r need to change? Does that suggest any guidance on how to construct values?=


Specific comments:

1.4 and children: These examples seem like fairly weak motivation, since I a=
ssume in both cases one could still have just put a single body-part inside a=
 multipart envelope. That seems more an "inconvenience" than a "problem". Ar=
e there any known use-cases where that would not be possible? (This is certa=
inly not a show stopper; we are allowed to solve inconveniences. But if ther=
e are any stronger motivations that could be documented, they might save que=
stions down the road.)

3.2, 2nd note: How has the msg-Id been simplified, and why?

3.4 and children: An example or two would be extremely helpful.


Editorial:

1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version.

1.2 and 1.3: A sentence or two that more strongly contrasts "body part" vs "=
message-body" would be helpful. I think that some people will think of a mes=
sage-body as still a body-part.

1.5, Note: Seems like the note belongs in the problem statement more than th=
e solution.



--Apple-Mail-B821791D-CD78-49D6-9BD9-6F98B231AF1C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi,

This is m=
y AD evaluation of draft-ietf-sipcore-content-id-05. I have some points I would like discu=
ss before going to IETF last call.

Note: I plan to request an Art-Art revi=
ew on this draft to focus on the MIME usage aspects.

Thanks=
!

Ben.

Discussion Points:

- I have some difficulty seeing the difference between "the body and relate=
d metadata" and "the SIP message". I realize you have the more MIME-specific=
 header fields in mind when you say "metadata". But any SIP header field cou=
ld be considered metadata.

The main point of that quest=
ion is, as used in MIME, Content-Id is intended to label a body part. Messag=
e-Id is used to label the whole message. Aren't we talking about the whole m=
essage here?

- Is there an expectation for the SIP Content-=
ID header field value to be referenced from outside the SIP message? If so, w=
hat are the uniqueness expectations? Note that for MIME, Content-ID is expec=
ted to be globally unique. Is that the case here?

If the Co=
ntent-ID is _not_ expected to be referenced from outside of the SIP message t=
hat contains it, then we have a sort of degenerate case where it always iden=
tifies _this_ message regardless of the value. Does that value ever need to c=
hange? Does that suggest any guidance on how to construct values?

Specific comments:

1.4 and children: These example=
s seem like fairly weak motivation, since I assume in both cases one could s=
till have just put a single body-part inside a multipart envelope. That seem=
s more an "inconvenience" than a "problem". Are there any known use-cases wh=
ere that would not be possible? (This is certainly not a show stopper; we ar=
e allowed to solve inconveniences. But if there are any stronger motivations=
 that could be documented, they might save questions down the road.)<=
/font>
<=
br>
3.2, 2nd note: How has the msg-Id been simplified, and why?=

=

3.4 and children: An example or two would be extremely helpful.


Editorial:

1.1, 3rd paragraph: Ci=
tation to RFC5621 is not a link in the PDF version.
=

=

1.2 and=
 1.3: A sentence or two that more strongly contrasts "body part" vs "message=
-body" would be helpful. I think that some people will think of a message-bo=
dy as still a body-part.

1.5, Note: Seems like the note bel=
ongs in the problem statement more than the solution.


<=
/span>
=

--Apple-Mail-B821791D-CD78-49D6-9BD9-6F98B231AF1C--


From nobody Tue May 16 14:32:00 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183A612EC7A; Tue, 16 May 2017 14:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.48
X-Spam-Level: 
X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 uYM8ES6FflP3; Tue, 16 May 2017 14:31:57 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D154F12EC9F; Tue, 16 May 2017 14:27:02 -0700 (PDT)
Received: from [10.0.2.215] (ip-62-232-239-173.texas.us.northamericancoax.com [173.239.232.62]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4GLR10b067662 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 May 2017 16:27:02 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-62-232-239-173.texas.us.northamericancoax.com [173.239.232.62] claimed to be [10.0.2.215]
From: Ben Campbell 
Content-Type: multipart/alternative; boundary=Apple-Mail-B1BB382E-A85D-433A-9314-5BAD084C81C3
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Tue, 16 May 2017 17:27:01 -0400
Message-Id: 
To: draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org
X-Mailer: iPad Mail (14E304)
Archived-At: 
Subject: [sipcore] AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:31:59 -0000

--Apple-Mail-B1BB382E-A85D-433A-9314-5BAD084C81C3
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hi,

This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. I have=
 no comments for a change :-) I will kick off IETF LC shortly.

Thanks!

Ben.=

--Apple-Mail-B1BB382E-A85D-433A-9314-5BAD084C81C3
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit

Hi,

This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. I have no comments for a change :-) I will kick off IETF LC shortly.

Thanks!

Ben.

--Apple-Mail-B1BB382E-A85D-433A-9314-5BAD084C81C3--


From nobody Tue May 16 14:40:28 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE5128B93; Tue, 16 May 2017 14:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.878
X-Spam-Level: 
X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 nZLKuU36zP4L; Tue, 16 May 2017 14:40:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B68D712EC3E; Tue, 16 May 2017 14:35:23 -0700 (PDT)
Received: from [10.0.2.215] (ip-62-232-239-173.texas.us.northamericancoax.com [173.239.232.62]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4GLZMxY068573 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 May 2017 16:35:23 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-62-232-239-173.texas.us.northamericancoax.com [173.239.232.62] claimed to be [10.0.2.215]
From: Ben Campbell 
Content-Type: multipart/alternative; boundary=Apple-Mail-DD6FC995-0D38-4C3C-BA94-958C132EF6CD
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
Date: Tue, 16 May 2017 17:35:22 -0400
Message-Id: <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com>
References: 
In-Reply-To: 
To: draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org
X-Mailer: iPad Mail (14E304)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:40:26 -0000

--Apple-Mail-DD6FC995-0D38-4C3C-BA94-958C132EF6CD
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Well, I take that back--I do have one comment/question:

There is no 2119 boilerplate. I assume this is because all the 2119 keywords=
 are in updates to other documents, which should hopefully have their own 21=
19 boilerplate? I'm on the fence about whether is should still be included h=
ere--was it a conscious decision to leave it out?

(Notice that I am not asking about the downrefs :-) )

Thanks!

Ben.

> On May 16, 2017, at 5:27 PM, Ben Campbell  wrote:
>=20
> Hi,
>=20
> This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. I ha=
ve no comments for a change :-) I will kick off IETF LC shortly.
>=20
> Thanks!
>=20
> Ben.

--Apple-Mail-DD6FC995-0D38-4C3C-BA94-958C132EF6CD
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Well, I take that back--I d=
o have one comment/question:

There is no 2119 boile=
rplate. I assume this is because all the 2119 keywords are in updates to oth=
er documents, which should hopefully have their own 2119 boilerplate? I'm on=
 the fence about whether is should still be included here--was it a consciou=
s decision to leave it out?

(Notice that I am not a=
sking about the downrefs :-) )

Thanks!
Ben.

On May 16, 2017, at 5:27 PM, Ben Campbell &l=
t;ben@nostrum.com> wrote:

<=
/div>
Hi,

This is m=
y AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. I have no comments for a chan=
ge :-) I will kick off IETF LC shortly.

Thanks!

Ben.
=

--Apple-Mail-DD6FC995-0D38-4C3C-BA94-958C132EF6CD--


From nobody Tue May 16 14:50:02 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0120126BF3; Tue, 16 May 2017 14:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.821
X-Spam-Level: 
X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 L_B8ViBEov9Q; Tue, 16 May 2017 14:49:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 18A0912EC56; Tue, 16 May 2017 14:45:06 -0700 (PDT)
Received: from unescapeable.local ([66.171.169.35]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4GLj4pn069690 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 May 2017 16:45:05 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [66.171.169.35] claimed to be unescapeable.local
To: Ben Campbell , draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org
References:  <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com>
From: Robert Sparks 
Message-ID: <52c054d6-95ad-9e56-37df-80aa670e51b9@nostrum.com>
Date: Tue, 16 May 2017 17:44:59 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com>
Content-Type: multipart/alternative; boundary="------------DA26925174475E48C6DC6A08"
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:50:00 -0000

This is a multi-part message in MIME format.
--------------DA26925174475E48C6DC6A08
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

The document needs to have that added. (Brian called that out in section 
11 of the writeup).

At the time he asked me about it, I suggested I fix _after_ your AD 
review, to get your comments at the same time.

Do you want me to revise this before IETFLC or deal with it when 
handling other IETFLC comments?

(It won't be hard to add).

RjS


On 5/16/17 5:35 PM, Ben Campbell wrote:
> Well, I take that back--I do have one comment/question:
>
> There is no 2119 boilerplate. I assume this is because all the 2119 
> keywords are in updates to other documents, which should hopefully 
> have their own 2119 boilerplate? I'm on the fence about whether is 
> should still be included here--was it a conscious decision to leave it 
> out?
>
> (Notice that I am not asking about the downrefs :-) )
>
> Thanks!
>
> Ben.
>
> On May 16, 2017, at 5:27 PM, Ben Campbell  > wrote:
>
>> Hi,
>>
>> This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. 
>> I have no comments for a change :-) I will kick off IETF LC shortly.
>>
>> Thanks!
>>
>> Ben.


--------------DA26925174475E48C6DC6A08
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
The document needs to have that added. (Brian called that out in
      section 11 of the writeup).

    
At the time he asked me about it, I suggested I fix _after_ your
      AD review, to get your comments at the same time.

    
Do you want me to revise this before IETFLC or deal with it when
      handling other IETFLC comments?

    
(It won't be hard to add).

    
RjS

    

    

    
On 5/16/17 5:35 PM, Ben Campbell wrote:

    

    

      
      
Well, I take that back--I do have one comment/question:

      


      

      
There is no 2119 boilerplate. I assume this is because all
        the 2119 keywords are in updates to other documents, which
        should hopefully have their own 2119 boilerplate? I'm on the
        fence about whether is should still be included here--was it a
        conscious decision to leave it out?

      


      

      
(Notice that I am not asking about the downrefs :-) )

      


      

      
Thanks!

      


      

      
Ben.

      


        On May 16, 2017, at 5:27 PM, Ben Campbell <ben@nostrum.com>
        wrote:

        

      

      

        

          
          Hi,
          


          

          
This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01.
              I have no comments for a change :-) I will kick off IETF
              LC shortly.

          


            

          
Thanks!

          


            

          
Ben.

        

      

    

    

  


--------------DA26925174475E48C6DC6A08--


From nobody Tue May 16 14:54:52 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A671300CF for ; Tue, 16 May 2017 14:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level: 
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 99-FuN6cmk-y for ; Tue, 16 May 2017 14:54:48 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 C4C15128B51 for ; Tue, 16 May 2017 14:49:26 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id o12so102644455iod.3 for ; Tue, 16 May 2017 14:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LbYXtTl2jOw5QITJmw4UQeMX4v2yk4wJtXJp1LYC9OM=; b=djyaevMF1YY/vYbpHEv5zDLAU3VffBL3FUW53dqZJ3Jk9HZdjW6yUZLYkvNJv0pS/0 fesGEOevDkpyWOQBaa9/oMT0Uj4yQMfHW5AYJfYYQWTJGm03ZlUjZ4V0nraU3UFMWemh aUV+CzH+qC73AUKqaflFwr7m/8rYNyAoh3jQVXvj56dFYVqDdOqroxMZVGTVoXRPy2Wp qjmJUVsMjCwY3e1KN9lMdx4Jo8/O80Bfo40EHe2b8rmr9xkfMjR8qluysrPtwHb70wS/ Sf5q9HwGiaxTmQH38W08u4YxHARl1NNU3O7QEU9wXyzcR83Erw7Q3ZKZ+R81Sy9V7jxe gU8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LbYXtTl2jOw5QITJmw4UQeMX4v2yk4wJtXJp1LYC9OM=; b=oWWKknY6ihZTnUnxlxs1fi3fmieI6q7VUDuy64FTtfJxLDC2tDGIPFEGG4h2ZDXFHk LUvRYZ+oxsp36UovsMcNjc+s4nILkHxk6u6pit/vH0euIyMv1CVR1BOMUv7haP2xd947 mMiWWqSdO5db3DZRFlxrHLyRr70fB5jAyUE+8X/hOmBiTHo9ooMsJ0gCaSqiOcp+ANwl Vwb/9ADvhWKKlEELLW8PY4hDsUsN118XhkALeA+GRB+FDPhpJX+J13ttjo6/BE/Autmr 5hl5YImEvh+cktyRS9EDXZRNgyyn4N5Ectul1e9ZyfRFX9VILd9BDBr6fpVf3b9xXNTv 6LXA==
X-Gm-Message-State: AODbwcBkLkV2At/dAq+d0e9Hc7KLEbr/31RSW/zFp5OXfRVC2Z4QPwmG 2beOmFIDT02AttWh
X-Received: by 10.107.14.195 with SMTP id 186mr125823ioo.112.1494971366182; Tue, 16 May 2017 14:49:26 -0700 (PDT)
Received: from [10.96.43.88] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id p196sm6563857itb.22.2017.05.16.14.49.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 14:49:25 -0700 (PDT)
From: Brian Rosen 
Message-Id: <11B6F22E-C46F-4AE3-9E0C-AC0DBDB9CF15@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BCF45504-1079-4AC3-8DF6-32F6A5E75F1F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 16 May 2017 17:49:24 -0400
In-Reply-To: <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com>
Cc: draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org
To: Ben Campbell 
References:  <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 21:54:49 -0000

--Apple-Mail=_BCF45504-1079-4AC3-8DF6-32F6A5E75F1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If you look at the shepherd=E2=80=99s write up, I noted that, and said =
that the author will fix it with other IESG comments.  I also noted the =
downrefs :)

Brian

> On May 16, 2017, at 5:35 PM, Ben Campbell  wrote:
>=20
> Well, I take that back--I do have one comment/question:
>=20
> There is no 2119 boilerplate. I assume this is because all the 2119 =
keywords are in updates to other documents, which should hopefully have =
their own 2119 boilerplate? I'm on the fence about whether is should =
still be included here--was it a conscious decision to leave it out?
>=20
> (Notice that I am not asking about the downrefs :-) )
>=20
> Thanks!
>=20
> Ben.
>=20
> On May 16, 2017, at 5:27 PM, Ben Campbell > wrote:
>=20
>> Hi,
>>=20
>> This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. =
I have no comments for a change :-) I will kick off IETF LC shortly.
>>=20
>> Thanks!
>>=20
>> Ben.


--Apple-Mail=_BCF45504-1079-4AC3-8DF6-32F6A5E75F1F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If you look at the shepherd=E2=80=99s write up, I noted that, =
and said that the author will fix it with other IESG comments.  I =
also noted the downrefs :)

Brian

On May 16, 2017, at 5:35 PM, =
Ben Campbell <ben@nostrum.com> wrote:

Well, I take that back--I do have one =
comment/question:

There is no 2119 boilerplate. I assume this is because all =
the 2119 keywords are in updates to other documents, which should =
hopefully have their own 2119 boilerplate? I'm on the fence about =
whether is should still be included here--was it a conscious decision to =
leave it out?

(Notice that I am not asking about the downrefs :-) =
)

Thanks!

Ben.

On May 16, 2017, at =
5:27 PM, Ben Campbell <ben@nostrum.com> wrote:

Hi,

This is my AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01. I have no comments =
for a change :-) I will kick off IETF LC shortly.

Thanks!

Ben.

=

--Apple-Mail=_BCF45504-1079-4AC3-8DF6-32F6A5E75F1F--


From nobody Tue May 16 15:35:37 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E61C12EBE4; Tue, 16 May 2017 15:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level: 
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 xm4cndkrPsHH; Tue, 16 May 2017 15:35:33 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1420612F4B2; Tue, 16 May 2017 15:30:55 -0700 (PDT)
Received: from [10.0.2.103] (ip-22-232-239-173.texas.us.northamericancoax.com [173.239.232.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4GMUrf8075610 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 16 May 2017 17:30:54 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host ip-22-232-239-173.texas.us.northamericancoax.com [173.239.232.22] claimed to be [10.0.2.103]
Content-Type: multipart/alternative; boundary=Apple-Mail-467D40EE-3524-42BC-98C0-1A9CF01D0526
Mime-Version: 1.0 (1.0)
From: Ben Campbell 
X-Mailer: iPad Mail (14E304)
In-Reply-To: <52c054d6-95ad-9e56-37df-80aa670e51b9@nostrum.com>
Date: Tue, 16 May 2017 18:30:52 -0400
Cc: draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <671DFB4B-8B03-4644-9A9E-156B6342B9D3@nostrum.com> <52c054d6-95ad-9e56-37df-80aa670e51b9@nostrum.com>
To: Robert Sparks 
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 16 May 2017 22:35:35 -0000

--Apple-Mail-467D40EE-3524-42BC-98C0-1A9CF01D0526
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On May 16, 2017, at 5:44 PM, Robert Sparks  wrote:
>=20
> The document needs to have that added. (Brian called that out in section 1=
1 of the writeup).
>=20
Ah, teach me to review docs on an airplane and forget to re-check the shephe=
rd write up before sending comments :-)
> At the time he asked me about it, I suggested I fix _after_ your AD review=
, to get your comments at the same time.
>=20
> Do you want me to revise this before IETFLC or deal with it when handling o=
ther IETFLC comments?
>=20
With other LC comments will be fine.


> (It won't be hard to add).
>=20
> RjS
>>>=20
>=20

--Apple-Mail-467D40EE-3524-42BC-98C0-1A9CF01D0526
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: 7bit


On May 16, 2017, at 5:44 PM, Robert Sparks <rjsparks@nostrum.com> wrote:


  
    
  
  
    
The document needs to have that added. (Brian called that out in
      section 11 of the writeup).
Ah, teach me to review docs on an airplane and forget to re-check the shepherd write up before sending comments :-)

    
At the time he asked me about it, I suggested I fix _after_ your
      AD review, to get your comments at the same time.

    
Do you want me to revise this before IETFLC or deal with it when
      handling other IETFLC comments?
With other LC comments will be fine.



    
(It won't be hard to add).

    
RjS

    

    


        

      

    

    

  



--Apple-Mail-467D40EE-3524-42BC-98C0-1A9CF01D0526--


From nobody Tue May 16 23:29:14 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82A1294E7; Tue, 16 May 2017 23:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 9q2QsUeOazmV; Tue, 16 May 2017 23:29:11 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD7512E872; Tue, 16 May 2017 23:25:46 -0700 (PDT)
X-AuditID: c1b4fb2d-eff839a00000196b-c1-591bece842b5
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D7.FE.06507.8ECEB195; Wed, 17 May 2017 08:25:44 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Wed, 17 May 2017 08:25:43 +0200
From: Christer Holmberg 
To: Ben Campbell , "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05
Thread-Index: AQHSzolPaE+D+c83j0ekLBIazLog+6H4IhOA
Date: Wed, 17 May 2017 06:25:42 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_D541C89A1CB67christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7q+6LN9KRBg+valnM7zzNbjHz7C4W i68/NrE5MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBltzxcwFWxNrFi3bT5bA2NbaBcj J4eEgInEk1/n2LsYuTiEBI4wSlzedYANwlnCKDH7+wvmLkYODjYBC4nuf9ogcRGBVYwSL/Zc ZgHpFhawk3j/aT8TSI2IgL3E/iniIGERASOJl3fPsoLYLAKqEvPm/QezeQWsJea+2ADWKgTU uvPEHmYQmxOoddqvY2A2o4CYxPdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf2AzRQX0 JPb9+8oGEVeUaH/awAjRmyDRe+UO1F5BiZMzn7BMYBSZhWTsLCRls5CUQcQNJN6fm88MYWtL LFv4GsrWl9j45SzjLKCPmYHemTq7HFnJAkaOVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiB cXdwy2/dHYyrXzseYhTgYFTi4b18WjpSiDWxrLgy9xCjBAezkghv5SugEG9KYmVValF+fFFp TmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYyrXjC0n2BaY+5YrF9oJZQ7de6p 5evvu8403r838N+k0nmNKz9O/bS2YLZj72mzdxEHGg908ciu5rvyKlDbamlX/AM9plPSNczT /3AY/P7LcntT+5U3X93F9q/j3xf16O7ZhTxlzLtT1815pXp8SyvDt8bDs1qOClQaOPDziqks Pe3GV7BVOrpMiaU4I9FQi7moOBEAxLdKIrcCAAA=
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 17 May 2017 06:29:13 -0000

--_000_D541C89A1CB67christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Ben,

Thanks for your comments!

Ivo is currently attending a 3GPP meeting in China, so we=92ll get back to =
you next week.

Thanks!

Regards,

Christer

From: Ben Campbell >
Date: Wednesday 17 May 2017 at 00:09
To: "draft-ietf-sipcore-content-id.all@ietf.org" >, "sipcore@ietf.org" >
Subject: AD Evaluation of draft-ietf-sipcore-content-id-05
Resent-From: >
Resent-To: Christer Holmberg >, Ivo Sedlacek >, "A. Mahoney" >, Brian Rosen >,=
 Ben Campbell >, "adam@nostrum.com<=
mailto:adam@nostrum.com>" >, >, "A. Mahoney" >
Resent-Date: Wednesday 17 May 2017 at 00:13

Hi,

This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some p=
oints I would like discuss before going to IETF last call.

Note: I plan to request an Art-Art review on this draft to focus on the MIM=
E usage aspects.

Thanks!

Ben.

Discussion Points:

- I have some difficulty seeing the difference between "the body and relate=
d metadata" and "the SIP message". I realize you have the more MIME-specifi=
c header fields in mind when you say "metadata". But any SIP header field c=
ould be considered metadata.

The main point of that question is, as used in MIME, Content-Id is intended=
 to label a body part. Message-Id is used to label the whole message. Aren'=
t we talking about the whole message here?

- Is there an expectation for the SIP Content-ID header field value to be r=
eferenced from outside the SIP message? If so, what are the uniqueness expe=
ctations? Note that for MIME, Content-ID is expected to be globally unique.=
 Is that the case here?

If the Content-ID is _not_ expected to be referenced from outside of the SI=
P message that contains it, then we have a sort of degenerate case where it=
 always identifies _this_ message regardless of the value. Does that value =
ever need to change? Does that suggest any guidance on how to construct val=
ues?

Specific comments:

1.4 and children: These examples seem like fairly weak motivation, since I =
assume in both cases one could still have just put a single body-part insid=
e a multipart envelope. That seems more an "inconvenience" than a "problem"=
. Are there any known use-cases where that would not be possible? (This is =
certainly not a show stopper; we are allowed to solve inconveniences. But i=
f there are any stronger motivations that could be documented, they might s=
ave questions down the road.)

3.2, 2nd note: How has the msg-Id been simplified, and why?

3.4 and children: An example or two would be extremely helpful.


Editorial:

1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version.

1.2 and 1.3: A sentence or two that more strongly contrasts "body part" vs =
"message-body" would be helpful. I think that some people will think of a m=
essage-body as still a body-part.

1.5, Note: Seems like the note belongs in the problem statement more than t=
he solution.



--_000_D541C89A1CB67christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <7F56F516C2C4BC42A84A1333FAEE9443@ericsson.com>
Content-Transfer-Encoding: quoted-printable







Hi Ben,







Thanks for your comments!







Ivo is currently attending a 3GPP meeting in China, so we=92ll get bac=
k to you next week.







Thanks!







Regards,







Christer









From: Ben Campbell <ben@nostrum.com>

Date: Wednesday 17 May 2017 at 00:0=
9

To: "draft-ietf-sipcore-content-id.all@ietf=
.org" <draft-ietf-sipcore-content-id.all@ietf.org>,
 "sipcore@ietf.org" <<=
a href=3D"mailto:sipcore@ietf.org">sipcore@ietf.org>

Subject: AD Evaluation of draft-iet=
f-sipcore-content-id-05

Resent-From: <alias-bounces@ietf.org>

Resent-To: Christer Holmberg <christer.holmberg@ericsson.=
com>, Ivo Sedlacek <=
ivo.sedlacek@ericsson.com>, "A. Mahoney" <mahoney@nostrum.com>,
 Brian Rosen <br@brianrosen.net=
>, Ben Campbell <ben@nostrum.com>, "adam@nostrum.com"=
; <adam@nostrum.com>,
 <aamelnikov@fastmail.fm&g=
t;, "A. Mahoney" <mahon=
ey@nostrum.com>

Resent-Date: Wednesday 17 May 2017 =
at 00:13











Hi,








This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some points I =
would like discuss before going to IETF last call.







Note: I plan=
 to request an Art-Art review on this draft to focus on the MIME usage aspe=
cts.







Thanks!







Ben.<=
/font>







Discussion P=
oints:







- I have som=
e difficulty seeing the difference between "the body and related metad=
ata" and "the SIP message". I realize you have the more MIME=
-specific header fields in mind when you say "metadata".
 But any SIP header field could be considered metadata.







The main poi=
nt of that question is, as used in MIME, Content-Id is intended to label a =
body part. Message-Id is used to label the whole message. Aren't we talking=
 about the whole message here?







- Is there a=
n expectation for the SIP Content-ID header field value to be referenced fr=
om outside the SIP message? If so, what are the uniqueness expectations? No=
te that for MIME, Content-ID is expected
 to be globally unique. Is that the case here?







If the Conte=
nt-ID is _not_ expected to be referenced from outside of the SIP message th=
at contains it, then we have a sort of degenerate case where it always iden=
tifies _this_ message regardless of
 the value. Does that value ever need to change? Does that suggest any guid=
ance on how to construct values?







Specific com=
ments:







1.4 and chil=
dren: These examples seem like fairly weak motivation, since I assume in bo=
th cases one could still have just put a single body-part inside a multipar=
t envelope. That seems more an "inconvenience"
 than a "problem". Are there any known use-cases where that would=
 not be possible? (This is certainly not a show stopper; we are allowed to =
solve inconveniences. But if there are any stronger motivations that could =
be documented, they might save questions down
 the road.)







3.2, 2nd not=
e: How has the msg-Id been simplified, and why?







3.4 and chil=
dren: An example or two would be extremely helpful.












Editorial:







1.1, 3rd par=
agraph: Citation to RFC5621 is not a link in the PDF version.=








1.2 and 1.3:=
 A sentence or two that more strongly contrasts "body part" vs &q=
uot;message-body" would be helpful. I think that some people will thin=
k of a message-body as still a body-part.







1.5, Note: S=
eems like the note belongs in the problem statement more than the solution.=




















--_000_D541C89A1CB67christerholmbergericssoncom_--


From nobody Thu May 18 05:58:24 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4A129AD4; Thu, 18 May 2017 05:58:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: ben@nostrum.com, sipcore-chairs@ietf.org, sipcore@ietf.org, draft-ietf-sipcore-name-addr-guidance@ietf.org, br@brianrosen.net, Brian Rosen 
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <149511229601.6682.1176174803456069749.idtracker@ietfa.amsl.com>
Date: Thu, 18 May 2017 05:58:16 -0700
Archived-At: 
Subject: [sipcore] Last Call:  (Clarifications for when to use the name-addr production in SIP messages) to Proposed Standard
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 18 May 2017 12:58:16 -0000

The IESG has received a request from the Session Initiation Protocol Core
WG (sipcore) to consider the following document:
- 'Clarifications for when to use the name-addr production in SIP
   messages'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-06-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   RFC3261 constrained several SIP header fields whose grammar contains
   the "name-addr / addr-spec" alternative to use name-addr when certain
   characters appear.  Unfortunately it expressed the constraints with
   prose copied into each header field definition, and at least one
   header field was missed.  Further, the constraint has not been copied
   into documents defining extension headers whose grammar contains the
   alternative.

   This document updates RFC3261 to state the constraint generically,
   and clarifies that the constraint applies to all SIP header fields
   where there is a choice between using name-addr or addr-spec.  It
   also updates the RFCs that define extension SIP header fields using
   the alternative to clarify that the constraint applies (RFCs 3325,
   3515, 3892, 4508, 5002, 5318, 5360, and 5502).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-name-addr-guidance/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sipcore-name-addr-guidance/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc5502: The SIP P-Served-User Private-Header (P-Header) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem (Informational - IETF stream)
    rfc5318: The Session Initiation Protocol (SIP) P-Refused-URI-List Private-Header (P-Header) (Informational - IETF stream)
    rfc5002: The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header) (Informational - IETF stream)
    rfc3325: Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks (Informational - IETF stream)




From nobody Fri May 19 07:29:13 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E8E127B31; Fri, 19 May 2017 07:29:04 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: sipcore@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149520414470.29079.12494975906762609914@ietfa.amsl.com>
Date: Fri, 19 May 2017 07:29:04 -0700
Archived-At: 
Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-authn-00.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 19 May 2017 14:29:05 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core of the IETF.

        Title           : Third-Party Authentication for Session Initiation Protocol (SIP)
        Authors         : Rifaat Shekh-Yusef
                          Christer Holmberg
                          Victor Pascual
	Filename        : draft-ietf-sipcore-sip-authn-00.txt
	Pages           : 16
	Date            : 2017-05-19

Abstract:
   This document defines an authentication mechanism for SIP, that is
   based on the OAuth 2.0 and OpenID Connect Core 1.0 specifications, to
   enable the delegation of the user authentication to a dedicated
   third-party IdP entity that is separate from the SIP network elements
   that provide the SIP service.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-authn/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-authn-00
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-authn-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon May 22 04:19:49 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF851287A0; Mon, 22 May 2017 04:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.819
X-Spam-Level: 
X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 9GHjY1EHjDw3; Mon, 22 May 2017 04:19:45 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855CE129C01; Mon, 22 May 2017 04:19:44 -0700 (PDT)
X-AuditID: c1b4fb25-73a9f9a0000055fe-4a-5922c94ea05f
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 50.61.22014.E49C2295; Mon, 22 May 2017 13:19:42 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0339.000; Mon, 22 May 2017 13:18:50 +0200
From: Christer Holmberg 
To: Ben Campbell , "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05
Thread-Index: AQHSzolPaE+D+c83j0ekLBIazLog+6IAT7OA
Date: Mon, 22 May 2017 11:18:50 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.18]
Content-Type: multipart/alternative; boundary="_000_D548A4E41CFD7christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7h67fSaVIg+Zl5hbzO0+zW8w8u4vF 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8bRT1PZCiY8Zqy48fc5ewPjhqOM XYycHBICJhILTm5n62Lk4hASOMIo8WzKVHYIZzGjxKPrL4EyHBxsAhYS3f+0QeIiAqsYJV7s ucwC0i0sYCfx/tN+JpAaEQF7if1TxEHCIgJGEmsW32MGsVkEVCVOTr3ODmLzClhLLPx9HqxV CKh154k9YDWcQK3Tfh0DsxkFxCS+n1rDBGIzC4hL3HoynwniUAGJJXvOM0PYohIvH/9jBbFF BfQk9v37ygYRV5T4+GofI8g5zAIJEv23UiDWCkqcnPmEZQKjyCwkU2chVM1CUgVRYiDx/tx8 ZghbW2LZwtdQtr7Exi9nGSFarSVmbEtHVrKAkWMVo2hxanFSbrqRsV5qUWZycXF+nl5easkm RmDcHdzyW3UH4+U3jocYBTgYlXh4VdcpRQqxJpYVV+YeYpTgYFYS4fXaAxTiTUmsrEotyo8v Ks1JLT7EKM3BoiTO67jvQoSQQHpiSWp2ampBahFMlomDU6qBsaD93gqubA6vI+Gn8nVTt+nP unBE4sGct59C/xhbCX/Ju/lx/7Wjrg6J11njYypW5kw/9ffN/l3TF4WwM5zLKrj8T+vMrXXS 4m/WsuqvsTvkP02m+26XgWjTHd4qpidbf26bLTZdgDvl08Lmd9tsZhRt4VHYXm7PZLGm89S/ 1Pus6nVKThYTDZVYijMSDbWYi4oTAURXVLO3AgAA
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 11:19:47 -0000

--_000_D548A4E41CFD7christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


Hi Ben,

>This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some =
points I would like discuss before going to IETF last call.
>
>Note: I plan to request an Art-Art review on this draft to focus on the MI=
ME usage aspects.
>
>Thanks!
>
>Ben.
>

Discussion Points:

>- I have some difficulty seeing the difference between "the body and relat=
ed metadata" and "the SIP message". I realize you have the more MIME-specif=
ic header fields in mind when you say "metadata". But any SIP header field =
could be considered metadata.

(Christer) As metadata, we are only considering SIP header fields that are =
also defined as MIME header fields.

>The main point of that question is, as used in MIME, Content-Id is intende=
d to label a body part. Message-Id is used to label the whole message. Aren=
't we talking about the whole message here?

(Christer) No.

>- Is there an expectation for the SIP Content-ID header field value to be =
referenced from outside the SIP message? If so, what are the uniqueness exp=
ectations? Note that for MIME, Content-ID is expected to be globally unique=
. Is that the case here?

(Christer) The draft does not change the uniqueness requirements of Content=
-ID.

>If the Content-ID is _not_ expected to be referenced from outside of the S=
IP message that contains it, then we have a sort of degenerate case where i=
t always identifies _this_ message regardless of the value. Does that value=
 ever need to change? Does that suggest >any guidance on how to construct v=
alues?

(Christer) RFC 5621 does not define the above characteristics for multipart=
 body usage, and I see no reason how anything would be different for a non-=
multipart message body. If you think there is something generic about Conte=
nt-ID that needs to be clarified I think that should be done as a separate =
task.


Specific comments:

>1.4 and children: These examples seem like fairly weak motivation, since I=
 assume in both cases one could still have just put a single body-part insi=
de a multipart envelope. That
>seems more an "inconvenience" than a "problem". Are there any known use-ca=
ses where that would not be possible? (This is certainly not a show stopper=
; we are allowed to solve
>inconveniences. But if there are any stronger motivations that could be do=
cumented, they might save questions down the road.)

(Christer) I can't think of any use-cases where it would not be possible to=
 use a single-body inside a multipart envelope instead. So, it is about =93=
convenience=94.


>3.2, 2nd note: How has the msg-Id been simplified, and why?

(Christer) The simplification was done based on a comment from Dale W.

https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html


>3.4 and children: An example or two would be extremely helpful.

(Christer) We can do that.


Editorial:

>1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF version.

(Christer) That=92s strange. I checked the XML file, and everything seems c=
orrect. Could the fact that the sentence starts with the reference have any=
thing to do with it?

 defines g=
eneric handling of a multipart message-body in a SIP message.


>1.2 and 1.3: A sentence or two that more strongly contrasts "body part" vs=
 "message-body" would be helpful. I think that some people will think of a =
message-body as still a body-part.

(Christer) We=92ll work on some clarification text.

>1.5, Note: Seems like the note belongs in the problem statement more than =
the solution.

(Christer) We can move it there.

Regards,

Christer


--_000_D548A4E41CFD7christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <3F7866EB0B6BEA47AB0940D035682747@ericsson.com>
Content-Transfer-Encoding: quoted-printable






















Hi Ben=
,







 =










>Th=
is is my AD evaluation of draft-ietf-sipcore-content-id-05. I have some points I would=
 like discuss before going to IETF last call.







> 







>Note: I plan to req=
uest an Art-Art review on this draft to focus on the MIME usage aspects.







> 







>Thanks!=








> 







>Ben.







> 









 =








Discussion Points:







 =








>- I have some diffi=
culty seeing the difference between "the body and related metadata&quo=
t; and "the SIP message". I realize you have the more MIME-specif=
ic header fields in mind when you say "metadata". But any
 SIP header field could be considered metadata.







 =








(Chris=
ter) As metadata, we are only considering SIP header fields that are =
also defined as MIME header fields.







 =








>The main point of t=
hat question is, as used in MIME, Content-Id is intended to label a body pa=
rt. Message-Id is used to label the whole message. Aren't we talking about =
the whole message here?







 =








(Chris=
ter) No.







 =








>- Is there an expec=
tation for the SIP Content-ID header field value to be referenced from outs=
ide the SIP message? If so, what are the uniqueness expectations? Note that=
 for MIME, Content-ID is expected to
 be globally unique. Is that the case here?







 =








(Chris=
ter) The draft does not change the uniqueness requirements of Content-ID.







 =








>If the Content-ID i=
s _not_ expected to be referenced from outside of the SIP message that cont=
ains it, then we have a sort of degenerate case where it always identifies =
_this_ message regardless of the value.
 Does that value ever need to change? Does that suggest >any guidance on=
 how to construct values?







 =








(Chris=
ter) RFC 5621 does not define the above characteristics for multipart body =
usage, and I see no reason how anything would be different for a non-multip=
art message body. If you think there
 is something generic about Content-ID that needs to be clarified I think t=
hat should be done as a separate task.







 =










 =








Specific comments:







 =








>1.4 and children: T=
hese examples seem like fairly weak motivation, since I assume in both case=
s one could still have just put a single body-part inside a multipart envel=
ope. That









>seems more an &quo=
t;inconvenience" than a "problem". Are there any known use-c=
ases where that would not be possible? (This is certainly not
 a show stopper; we are allowed to solve







>inconveniences. But=
 if there are any stronger motivations that could be documented, they might=
 save questions down the road.)







 =








(Chris=
ter) I can't think of any use-cases where it would not be possible to use a=
 single-body inside a multipart envelope instead. So, it is about =93conven=
ience=94.







 =








 =








>3.2, 2nd note: How =
has the msg-Id been simplified, and why?







 =








(Chris=
ter) The simplification was done based on a comment from Dale W.=








 =









 =










 =








>3.4 and children: A=
n example or two would be extremely helpful.









 =








(Chris=
ter) We can do that.









 =








 =








Editorial:<=
/span>







 =








>1.1, 3rd paragraph:=
 Citation to RFC5621 is not a link in the PDF version.








 =








(Chris=
ter) That=92s strange. I checked the XML file, and everything seems correct=
. Could the fact that the sentence starts with the reference have anything =
to do with it?







 =








<t&=
gt;<xref target=3D"RFC5621" pageno=3D"false" format=
=3D"default"/> defines generic handling of a multipart message=
-body in a SIP message.</t>







 =








 =








>1.2 and 1.3: A sent=
ence or two that more strongly contrasts "body part" vs "mes=
sage-body" would be helpful. I think that some people will think of a =
message-body as still a body-part.







 =








(Chris=
ter) We=92ll work on some clarification text.









 =








>1.5, Note: Seems li=
ke the note belongs in the problem statement more than the solution.=
<=
/o:p>









 =








(Chris=
ter) We can move it there.







 =








Regards,







 =








Christer







 =














--_000_D548A4E41CFD7christerholmbergericssoncom_--


From nobody Mon May 22 11:59:42 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B39129C5A; Mon, 22 May 2017 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 BfypevRIHGj4; Mon, 22 May 2017 11:59:30 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C5EC9129B9E; Mon, 22 May 2017 11:59:30 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4MIxQFe087873 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 May 2017 13:59:27 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: 
Date: Mon, 22 May 2017 13:59:26 -0500
Cc: "draft-ietf-sipcore-content-id.all@ietf.org" ,  "sipcore@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com>
References:  
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 22 May 2017 18:59:33 -0000

Thanks for the response. Comments inline:

Thanks!

Ben.

> On May 22, 2017, at 6:18 AM, Christer Holmberg =
 wrote:
>=20
>=20
> Hi Ben,
> =20
> >This is my AD evaluation of draft-ietf-sipcore-content-id-05. I have =
some points I would like discuss before going to IETF last call.
> >=20
> >Note: I plan to request an Art-Art review on this draft to focus on =
the MIME usage aspects.
> >=20
> >Thanks!
> >=20
> >Ben.
> >=20
> =20
> Discussion Points:
> =20
> >- I have some difficulty seeing the difference between "the body and =
related metadata" and "the SIP message". I realize you have the more =
MIME-specific header fields in mind when you say "metadata". But any SIP =
header field could be considered metadata.
> =20
> (Christer) As metadata, we are only considering SIP header fields that =
are also defined as MIME header fields.
> =20
> >The main point of that question is, as used in MIME, Content-Id is =
intended to label a body part. Message-Id is used to label the whole =
message. Aren't we talking about the whole message here?
> =20
> (Christer) No.

We are borrowing this from the usage in email, where people usually =
consider _all_ the header fields as metadata, thus the usage of =
=E2=80=9CMessage-Id=E2=80=9D rather than =E2=80=9CContent-Id=E2=80=9D =
when referring to the entire contents. I=E2=80=99m not saying it=E2=80=99s=
 wrong to do it differently for SIP, but it would be good to include =
some motivation for that difference. I suspect the difference has to do =
with the purpose of email being to deliver the content, while for SIP =
the purpose of the content is to modify the handling of session =
initiation. In which case one might consider the content itself as =
=E2=80=9Cmetadata=E2=80=9D. (I=E2=80=99m curious to hear if there are =
other reasons.)


> =20
> >- Is there an expectation for the SIP Content-ID header field value =
to be referenced from outside the SIP message? If so, what are the =
uniqueness expectations? Note that for MIME, Content-ID is expected to =
be globally unique. Is that the case here?
> =20
> (Christer) The draft does not change the uniqueness requirements of =
Content-ID.
> =20
> >If the Content-ID is _not_ expected to be referenced from outside of =
the SIP message that contains it, then we have a sort of degenerate case =
where it always identifies _this_ message regardless of the value. Does =
that value ever need to change? Does that suggest >any guidance on how =
to construct values?
> =20
> (Christer) RFC 5621 does not define the above characteristics for =
multipart body usage, and I see no reason how anything would be =
different for a non-multipart message body. If you think there is =
something generic about Content-ID that needs to be clarified I think =
that should be done as a separate task.
> =20

5261 used the Content-Id MIME header field. That field and it=E2=80=99s =
uniqueness requirements are defined elsewhere. This draft defines a =
Content-ID sip header field. That didn=E2=80=99t exist before. Therefore =
I think this needs to describe the uniqueness requirements.

5322 requires msg-id to be globally unique because it=E2=80=99s intended =
to be useful outside the context of the given message. Is that the case =
here? If not, then a globally uniqueness requirement may not make sense =
in this context. (IIUC, every single instance of the Content-Id SIP =
header field could have the same, identical value, and things would work =
fine.)


> =20
> Specific comments:
> =20
> >1.4 and children: These examples seem like fairly weak motivation, =
since I assume in both cases one could still have just put a single =
body-part inside a multipart envelope. That
> >seems more an "inconvenience" than a "problem". Are there any known =
use-cases where that would not be possible? (This is certainly not a =
show stopper; we are allowed to solve
> >inconveniences. But if there are any stronger motivations that could =
be documented, they might save questions down the road.)
> =20
> (Christer) I can't think of any use-cases where it would not be =
possible to use a single-body inside a multipart envelope instead. So, =
it is about =E2=80=9Cconvenience=E2=80=9D.

The word =E2=80=9Coptimization=E2=80=9D comes to mind.

> =20
> =20
> >3.2, 2nd note: How has the msg-Id been simplified, and why?
> =20
> (Christer) The simplification was done based on a comment from Dale W.
> =20
> https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html

I think it would be helpful to say something like =E2=80=9C=E2=80=A6 =
simplified to disallow the use of comments and to adapt to SIP=E2=80=99s =
use of leading white space."

> =20
> =20
> >3.4 and children: An example or two would be extremely helpful.
> =20
> (Christer) We can do that.

Thanks!

> =20
> =20
> Editorial:
> =20
> >1.1, 3rd paragraph: Citation to RFC5621 is not a link in the PDF =
version.
> =20
> (Christer) That=E2=80=99s strange. I checked the XML file, and =
everything seems correct. Could the fact that the sentence starts with =
the reference have anything to do with it?
> =20
>  =
defines generic handling of a multipart message-body in a SIP =
message.

I don=E2=80=99t know, it may be an xml2rfc bug. If there=E2=80=99s no =
error in the xml, then we could leave this to the RFC editor.

[I removed the rest of the editorial section, since all my responses =
would be =E2=80=9COkay=E2=80=9D]



From nobody Tue May 23 06:05:13 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E0129A9F for ; Tue, 23 May 2017 06:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 TactIiUAKCNY for ; Tue, 23 May 2017 06:05:08 -0700 (PDT)
Received: from MAILOUT21.telekom.de (MAILOUT21.telekom.de [80.149.113.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F6A129B2B for ; Tue, 23 May 2017 06:05:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1495544708; x=1527080708; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QzBovQ3FlOOfcEfRolwGLrx+IumDUjsJtQTk/+ia9u8=; b=lf3fVP+llo7AKjQLFFR1dm+rNprseyKzkoaTIi1H0l8xfz1Ki6tXilSa veR21cXE5VRBq/WeS6vULuSRhUF7lzHKDtrGj9eZ15bBuBO0JVNPXcSx3 urzIeRRmvzQj/ZvPMUUiVUav6L+rC888hnUnASc/BTqoMa96eSSb9Gjvt 0lfSKNRImwnFefjTKYhu35OWAO/O/8Pq6JqbcLh2U1eoUaMCz7uRsgpWx JdGCEDirkyk7upQuq/ViaI7An4c6Hz3DT1KYhCvUwJuZ03JL+FdNoX2AM ACuAJjxP8zAPhzNSpigRG5aJ+SRCoAztHfWwrp0zlAdRYwbRpH6xoDrxL A==;
Received: from q4de8psa04t.blf.telekom.de ([10.151.13.130]) by MAILOUT21.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2017 15:04:51 +0200
X-IronPort-AV: E=Sophos;i="5.38,382,1491256800"; d="scan'208";a="674651645"
Received: from he105831.emea1.cds.t-internal.com ([10.169.119.34]) by Q4DE8PSA04V.blf.telekom.de with ESMTP/TLS/AES256-SHA; 23 May 2017 15:04:51 +0200
Received: from HE105828.EMEA1.cds.t-internal.com (10.169.119.31) by HE105831.emea1.cds.t-internal.com (10.169.119.34) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 May 2017 15:04:50 +0200
Received: from HE105828.EMEA1.cds.t-internal.com ([fe80::753e:c05:6c77:b585]) by HE105828.emea1.cds.t-internal.com ([fe80::753e:c05:6c77:b585%26]) with mapi id 15.00.1263.000; Tue, 23 May 2017 15:04:50 +0200
From: 
To: 
CC: , , 
Thread-Topic: New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
Thread-Index: AQHS08JpUig+mkZVLEKjpPL+YXPfRqIB3WVA
Date: Tue, 23 May 2017 13:04:50 +0000
Message-ID: <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com>
References: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com>
In-Reply-To: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.213.236.246]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 13:05:11 -0000

RGVhciBhbGwsDQoNCkFmdGVyIHJld29ya2luZyB0aGUgZHJhZnQgZHVlIHRvIHRoZSBjb21tZW50
cyBtYWRlIGJ5IERhbGUsIEkgaGF2ZSB1cGxvYWRlZCBhIG5ldyB2ZXJzaW9uDQpodHRwczovL3d3
dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtbG9j
cGFyYW0tMDEudHh0DQoNCkkgZGlkbid0IGdldCBhbnkgY29tbWVudHMgb24gbXkgYW5zd2VycyBn
aXZlbiB0byBEYWxlcyBtYWlsIHdoaWNoIGFsc28gY292ZXJlZCB0aGUgY29tbWVudHMgbWFkZSB3
aXRoaW4gdGhlIG1lZXRpbmcgcmVwb3J0Lg0KDQpFVFNJIGlzIHN0aWxsIGxvb2tpbmcgZm9yd2Fy
ZCBvbiBwcm9jZXNzaW5nIHRoaXMgZG9jdW1lbnQgZm9yIHRoZWlyIHNvbHV0aW9uIG9uIEVtZXJn
ZW5jeSBDYWxsIGR1ZSB0byB0aGUgUHJvamVjdCBvZiAgdGhlIEV1cm9wZWFuIFVuaW9uIE1hbmRh
dGU6IE00OTMuDQogDQpDb21tZW50cyBhbmQgaW1wcm92ZW1lbnRzIGFyZSB3ZWxjb21lLg0KDQpR
dWVzdGlvbiBpcyBob3cgdG8gcHJvY2VlZCBmdXJ0aGVyIHNpbmNlIEkgZGlkIG5vdCBnZXQgYW55
IGZ1cnRoZXIgY29tbWVudHMgc2luY2UgbXkgbGFzdCBtYWlsIG9uIDR0aCBBcHJpbC4NCg0KQmVz
dCBSZWdhcmRzDQoNClJvbGFuZA0KDQo+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0t
LS0NCj4gVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm
dHNAaWV0Zi5vcmddDQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgMjMuIE1haSAyMDE3IDE0OjQ1DQo+
IEFuOiBKZXNza2UsIFJvbGFuZDsgQnJ1bm8gQ2hhdHJhczsgSmFtZXMgV2ludGVyYm90dG9tOyBB
bmRyZXcgSHV0dG9uDQo+IEJldHJlZmY6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh
ZnQtd2ludGVyYm90dG9tLXNpcGNvcmUtDQo+IGxvY3BhcmFtLTAxLnR4dA0KPiANCj4gDQo+IEEg
bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbS0w
MS50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSb2xhbmQgSmVzc2tl
IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYNCj4gcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFm
dC13aW50ZXJib3R0b20tc2lwY29yZS1sb2NwYXJhbQ0KPiBSZXZpc2lvbjoJMDENCj4gVGl0bGU6
CQlMb2NhdGlvbiBTb3VyY2UgUGFyYW1ldGVyIGZvciB0aGUgU0lQIEdlb2xvY2F0aW9uDQo+IEhl
YWRlciBGaWVsZA0KPiBEb2N1bWVudCBkYXRlOgkyMDE3LTA1LTIzDQo+IEdyb3VwOgkJSW5kaXZp
ZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJOA0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdpbnRlcmJvdHRvbS0NCj4gc2lwY29y
ZS1sb2NwYXJhbS0wMS50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbnRlcmJvdHRvbS0NCj4gc2lwY29yZS1sb2NwYXJhbS8NCj4g
SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW50ZXJi
b3R0b20tc2lwY29yZS0NCj4gbG9jcGFyYW0tMDENCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtDQo+IHdpbnRlcmJvdHRvbS1zaXBj
b3JlLWxvY3BhcmFtLTAxDQo+IERpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9y
ZmNkaWZmP3VybDI9ZHJhZnQtd2ludGVyYm90dG9tLQ0KPiBzaXBjb3JlLWxvY3BhcmFtLTAxDQo+
IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhlcmUgYXJlIHNvbWUgY2lyY3Vtc3RhbmNlcyB3aGVyZSBh
IGdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCBtYXkNCj4gICAgY29udGFpbiBtb3JlIHRoYW4gb25l
IGxvY2F0aW9uIHZhbHVlLiAgS25vd2luZyB0aGUgaWRlbnRpdHkgb2YgdGhlDQo+ICAgIG5vZGUg
YWRkaW5nIHRoZSBsb2NhdGlvbiB2YWx1ZSBhbGxvd3MgdGhlIHJlY2lwaWVudCBtb3JlIGZyZWVk
b20gaW4NCj4gICAgc2VsZWN0aW5nIHRoZSB2YWx1ZSB0byBsb29rIGF0IGZpcnN0IHJhdGhlciB0
aGFuIHJlbHlpbmcgc29sZWx5IG9uDQo+ICAgIHRoZSBvcmRlciBvZiB0aGUgbG9jYXRpb24gdmFs
dWVzLg0KPiANCj4gDQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv
dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gc3VibWlzc2lvbiB1bnRpbCB0aGUg
aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYu
b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K


From nobody Tue May 23 06:42:46 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38693129B52 for ; Tue, 23 May 2017 06:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 ULSa9YduKzWf for ; Tue, 23 May 2017 06:42:43 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 1F08A129B4B for ; Tue, 23 May 2017 06:42:43 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id t26so127942518qtg.0 for ; Tue, 23 May 2017 06:42:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qcUYgBI0Azy3xFjLrK/1EQn0xIJBnciyWIPOjhjDD0s=; b=YAeuZPcrS+rPaJ6ZhjTuk0Zk6pT4i4De7rJ4J+rCbbSRM3u3ZlFDk2YUZKwjxsYXzC 7hE96xns0tnM0qtGmqZ/cVUN3c+pPUBsGd5gJdOl25u34hhE/9kMUqS7zRXjr8DqDAZr H30vx7Ioo3ST8YgW5TB1CUNB0/7PY9ByZoPMrGq70a+2IMmfry7T6pomi5mlD5qbmRQg bgBW+wpRolLog5n4BuH8rno68MDmIMa7mrd9twA7WZP7ZarmuCoiZqzY0ZOCwf4LJFsX VFWNmpYy1iKy/m2GrtmwpXkZxSIWy7L71uirjqJQjGZ0DPvWeyTbI2A9qaRSkghcKP40 KbGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qcUYgBI0Azy3xFjLrK/1EQn0xIJBnciyWIPOjhjDD0s=; b=Z8KVYa2NB8AnvsGYYmP3s9V52ygVe8aRa6vu+synxndCnENaV67hju5DcfCYhUzkI1 Rvknb4CAFad7PtPqqoI/gYKThOHZDVfZuuDzqXe6KqJudAObxjaR8BY06/EwWkI4FrUV YlMVCVdqQKiXlcolmI0IwhRerdmWUTjhFGyuMKFV6R9gSeaCFDpEQm2zR8cE3PsXk/pr 5oHnqxQ0UBnWa9HwsRWCmMcF4VQfgxfkq4U2Oy81hNF/+w8x8/DFbGKPDeEJfelBAkKK YaqSYIotAPMAgZ/OUZybgp1aFOr9zhP4c10u5vabc3yfCNK3Hb5pxZKyLhjnrBAoDAfi ++cw==
X-Gm-Message-State: AODbwcAaDq8RCkX786HjM6EtcTA4Hel5iJ8n0zQ33t6dbmX3601rKddh IBOjIrWB7NCSbxmrKH/chw==
X-Received: by 10.237.36.101 with SMTP id s34mr27227701qtc.137.1495546962190;  Tue, 23 May 2017 06:42:42 -0700 (PDT)
Received: from [10.96.43.88] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id p20sm477621qtf.31.2017.05.23.06.42.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 06:42:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Brian Rosen 
In-Reply-To: <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com>
Date: Tue, 23 May 2017 09:42:40 -0400
Cc: sipcore@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <74608836-48C8-4A14-B37B-90AD9F318AAF@brianrosen.net>
References: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com> <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com>
To: R.Jesske@telekom.de
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 13:42:45 -0000


I had asked a question on this, which was, why isn=E2=80=99t =
 an acceptable solution to the problem?

I didn=E2=80=99t see an answer.

Brian
> On May 23, 2017, at 9:04 AM, R.Jesske@telekom.de wrote:
>=20
> Dear all,
>=20
> After reworking the draft due to the comments made by Dale, I have =
uploaded a new version
> =
https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-0=
1.txt
>=20
> I didn't get any comments on my answers given to Dales mail which also =
covered the comments made within the meeting report.
>=20
> ETSI is still looking forward on processing this document for their =
solution on Emergency Call due to the Project of  the European Union =
Mandate: M493.
>=20
> Comments and improvements are welcome.
>=20
> Question is how to proceed further since I did not get any further =
comments since my last mail on 4th April.
>=20
> Best Regards
>=20
> Roland
>=20
>> -----Urspr=C3=BCngliche Nachricht-----
>> Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>> Gesendet: Dienstag, 23. Mai 2017 14:45
>> An: Jesske, Roland; Bruno Chatras; James Winterbottom; Andrew Hutton
>> Betreff: New Version Notification for draft-winterbottom-sipcore-
>> locparam-01.txt
>>=20
>>=20
>> A new version of I-D, draft-winterbottom-sipcore-locparam-01.txt
>> has been successfully submitted by Roland Jesske and posted to the =
IETF
>> repository.
>>=20
>> Name:		draft-winterbottom-sipcore-locparam
>> Revision:	01
>> Title:		Location Source Parameter for the SIP =
Geolocation
>> Header Field
>> Document date:	2017-05-23
>> Group:		Individual Submission
>> Pages:		8
>> URL:            =
https://www.ietf.org/internet-drafts/draft-winterbottom-
>> sipcore-locparam-01.txt
>> Status:         https://datatracker.ietf.org/doc/draft-winterbottom-
>> sipcore-locparam/
>> Htmlized:       =
https://tools.ietf.org/html/draft-winterbottom-sipcore-
>> locparam-01
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>> winterbottom-sipcore-locparam-01
>> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-=

>> sipcore-locparam-01
>>=20
>> Abstract:
>>   There are some circumstances where a geolocation header field may
>>   contain more than one location value.  Knowing the identity of the
>>   node adding the location value allows the recipient more freedom in
>>   selecting the value to look at first rather than relying solely on
>>   the order of the location values.
>>=20
>>=20
>>=20
>>=20
>> Please note that it may take a couple of minutes from the time of
>> submission until the htmlized version and diff are available at
>> tools.ietf.org.
>>=20
>> The IETF Secretariat
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Tue May 23 12:35:23 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5543512EA8C for ; Tue, 23 May 2017 12:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 jEWd2XLmmkF1 for ; Tue, 23 May 2017 12:35:19 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 A240512EA58 for ; Tue, 23 May 2017 12:35:17 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id e193so123992362pfh.0 for ; Tue, 23 May 2017 12:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1wqJS45nX0cR3/nA8WGRv4cNgmzFt/mtY6zaZtvlGLo=; b=azAOR7jjhCObhAxl6kBQucYG+YrlTF0+E9UCOAs6fXWhrcHwI6ZyjBHBb51uXxQQD/ sgyBDZY/PFsRivfi1VwIVE9u6RTa2nDQJr5GJ/2tTyg+IywWKzW4eq2Zu10iUuPaufDi SDhTpeGe8g3j96vHnEpUSq1h9Q5bvNeu1bTqsnrCoGPBn1Q4E8B7gUD1TSXy7I5mkcI5 U3ZV1QwXKO4l3lxv5QZ9OPbZsx3XR8QVlAVD6uhu8lT2cUT3OesCwmZqilvP9oDJe1QP 0EAlXjumLxf9WaPbpfmWzxlmhi4wBztLRDRVlJrPoVi1iTvJWygcLllN1XGWIWn2mIaS Vdxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1wqJS45nX0cR3/nA8WGRv4cNgmzFt/mtY6zaZtvlGLo=; b=J/Bzvf5Nk01Y0nmDQHjtF2vwH66S9LzI01EFe0+UeqACPocTpbYePnW/Bx7E5dgRRy nkpx/PNWHPLURKI61XH1bIepiALqZetcUK+daStj8adKZxQUWINmuOx3P+gxf7FtopoM jBfTvVRSvutwe6/21KOe7yvglmCFaZw7gEkKO+JvYqMNT2H5ocWcCBmbDVnBYB5+RuuJ kUI4kCU3I3+/5Ro7q8xSB7HW5h+MCt8xG+El89UQ6KMDMY5qX34hdVR0/exqagVggmN6 7bbi5C8jVpET0XNk/S/DAZXCR6wuBcrQN8RiXfi9JgSAlItlokXA5RkPyG8mAjvGjEws PKqw==
X-Gm-Message-State: AODbwcD4/3GQ3Wzpj5Wz2QcrZH2OQrWIqB3LVTOx+HTi6wPt0DwhVtIp 3lFloRC/USBel2H57+g=
X-Received: by 10.99.139.195 with SMTP id j186mr34455475pge.134.1495568117284;  Tue, 23 May 2017 12:35:17 -0700 (PDT)
Received: from ?IPv6:2001:8000:1054:d300:1139:59aa:f06b:5ec2? ([2001:8000:1054:d300:1139:59aa:f06b:5ec2]) by smtp.gmail.com with ESMTPSA id j11sm1746721pgn.38.2017.05.23.12.35.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 12:35:16 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: James Winterbottom 
In-Reply-To: 
Date: Wed, 24 May 2017 05:35:11 +1000
Cc: R.Jesske@telekom.de, sipcore@ietf.org, andrew.hutton@unify.com, bruno.chatras@orange.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <75D7EE00-BE2B-4C6E-91DE-819AF015542F@gmail.com>
References: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com> <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com> 
To: Brian Rosen 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:35:21 -0000

Hi Brian,

Provided-by doesn=E2=80=99t work for two reasons.

1) Provided-by says who determined the location, not who put the thing =
into the geolocation header
2) provided-by only works if you sending location by value, which in the =
European case we are not.


Cheers
James





> On 23 May 2017, at 11:40 pm, Brian Rosen  wrote:
>=20
> 
> I had asked a question on this, which was, why isn=E2=80=99t =
 an acceptable solution to the problem?
>=20
> I didn=E2=80=99t see an answer.
>=20
> Brian
>> On May 23, 2017, at 9:04 AM, R.Jesske@telekom.de wrote:
>>=20
>> Dear all,
>>=20
>> After reworking the draft due to the comments made by Dale, I have =
uploaded a new version
>> =
https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-0=
1.txt
>>=20
>> I didn't get any comments on my answers given to Dales mail which =
also covered the comments made within the meeting report.
>>=20
>> ETSI is still looking forward on processing this document for their =
solution on Emergency Call due to the Project of  the European Union =
Mandate: M493.
>>=20
>> Comments and improvements are welcome.
>>=20
>> Question is how to proceed further since I did not get any further =
comments since my last mail on 4th April.
>>=20
>> Best Regards
>>=20
>> Roland
>>=20
>>> -----Urspr=C3=BCngliche Nachricht-----
>>> Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> Gesendet: Dienstag, 23. Mai 2017 14:45
>>> An: Jesske, Roland; Bruno Chatras; James Winterbottom; Andrew Hutton
>>> Betreff: New Version Notification for draft-winterbottom-sipcore-
>>> locparam-01.txt
>>>=20
>>>=20
>>> A new version of I-D, draft-winterbottom-sipcore-locparam-01.txt
>>> has been successfully submitted by Roland Jesske and posted to the =
IETF
>>> repository.
>>>=20
>>> Name:		draft-winterbottom-sipcore-locparam
>>> Revision:	01
>>> Title:		Location Source Parameter for the SIP =
Geolocation
>>> Header Field
>>> Document date:	2017-05-23
>>> Group:		Individual Submission
>>> Pages:		8
>>> URL:            =
https://www.ietf.org/internet-drafts/draft-winterbottom-
>>> sipcore-locparam-01.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-winterbottom-
>>> sipcore-locparam/
>>> Htmlized:       =
https://tools.ietf.org/html/draft-winterbottom-sipcore-
>>> locparam-01
>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>>> winterbottom-sipcore-locparam-01
>>> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-
>>> sipcore-locparam-01
>>>=20
>>> Abstract:
>>>  There are some circumstances where a geolocation header field may
>>>  contain more than one location value.  Knowing the identity of the
>>>  node adding the location value allows the recipient more freedom in
>>>  selecting the value to look at first rather than relying solely on
>>>  the order of the location values.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> tools.ietf.org.
>>>=20
>>> The IETF Secretariat
>>=20
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>=20


From nobody Tue May 23 12:51:35 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0463112EAE1 for ; Tue, 23 May 2017 12:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.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 t5BDzid7Meei for ; Tue, 23 May 2017 12:51:32 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 43FD1127866 for ; Tue, 23 May 2017 12:51:32 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id v27so137797232qtg.2 for ; Tue, 23 May 2017 12:51:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DmZC7jK9PB1YOGf8LBIDGUYJXZ+r979ReDhq9q535pE=; b=blkYjmPHVPgkSY7ockvqiV63UpTg45sRwidG29/5jko6bE8Ims0oHJNBpds+c5Cfwr cNPO57j6ekvdFDDhApRELDu5Kz/SVqOhzYNR4z4Rh8E7egPb2pIbzUbJy7p3JIHC849p wqolxB+wyEVUe1U994IpiV4/EpcVykV92ML5a7GEflWAlq0VQ5rrw1bAw0mJ/Bqmq+eG i4zlRuKxawTpctvxS7yMtV3HMSREkd5CyeIuUjp4+ezqxaQBchlFvrE35gEqEEUgzgUE E5tuJqd+coXhbc9i4ypWwvMDmqBiVr/z/4hlF0R1j1fyLEBZVH6jac0PSb566TBVvCoD 0MXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DmZC7jK9PB1YOGf8LBIDGUYJXZ+r979ReDhq9q535pE=; b=Aye4mSRKhplqhEdx5xFZmTTilfBwCZ4egNqy9pDTF4Mc47foo8Phekv6YrimJtiNmz GfWQzBy47b/I5803w6IEbc8Ljt/NGlx5lqLyElX0KgQ4Fcb3UXdZuN07otEwGLMyyu+X m01yvBPln01dUwYDFqC4PYMAIpFpczQh1LMVOwHxMrrtbhqkjpAkN7GLgJRyOnxvr6E6 67PcGT746RT+MspV2tdLo2c+KhHUP0z0rLVHY7oxDjnS7sCMLukCEF9pgmkBp6gHtPSN KG+CJIjW5hLTW3yzL9CO0++/Nrd+YS09Gn3MoR9eYXNQk7QGyjxeEgsZ7Hnj3NZ1KCm1 HmIg==
X-Gm-Message-State: AODbwcAFAxlh37beZuzy1JOYFfnRoPqiyijqK+7AHngnvE401d6gNuPL wlRWah8uJQnrklrAgr3r2A==
X-Received: by 10.200.49.194 with SMTP id i2mr31645686qte.156.1495569091382; Tue, 23 May 2017 12:51:31 -0700 (PDT)
Received: from [10.96.43.88] (neustar-sthide-nat1.neustar.biz. [156.154.81.54]) by smtp.gmail.com with ESMTPSA id l14sm1112787qtf.40.2017.05.23.12.51.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 12:51:30 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Brian Rosen 
In-Reply-To: <75D7EE00-BE2B-4C6E-91DE-819AF015542F@gmail.com>
Date: Tue, 23 May 2017 15:51:27 -0400
Cc: Brian Rosen , "Hutton, Andrew" , sipcore@ietf.org, bruno.chatras@orange.com, R.Jesske@telekom.de
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FE4ADF5-7C50-4BEE-A3AA-2CCAED505EE5@brianrosen.net>
References: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com> <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com>  <75D7EE00-BE2B-4C6E-91DE-819AF015542F@gmail.com>
To: James Winterbottom 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:51:34 -0000

Is there a practical difference between who determined location and who =
put it in the header?

Is there a reason you can=E2=80=99t (or even more likely, wouldn=E2=80=99t=
 normally) dereference the URI, and thus get the =20
in every circumstance where the locparam would be used?

Brian

> On May 23, 2017, at 3:35 PM, James Winterbottom =
 wrote:
>=20
> Hi Brian,
>=20
> Provided-by doesn=E2=80=99t work for two reasons.
>=20
> 1) Provided-by says who determined the location, not who put the thing =
into the geolocation header
> 2) provided-by only works if you sending location by value, which in =
the European case we are not.
>=20
>=20
> Cheers
> James
>=20
>=20
>=20
>=20
>=20
>> On 23 May 2017, at 11:40 pm, Brian Rosen  wrote:
>>=20
>> 
>> I had asked a question on this, which was, why isn=E2=80=99t =
 an acceptable solution to the problem?
>>=20
>> I didn=E2=80=99t see an answer.
>>=20
>> Brian
>>> On May 23, 2017, at 9:04 AM, R.Jesske@telekom.de wrote:
>>>=20
>>> Dear all,
>>>=20
>>> After reworking the draft due to the comments made by Dale, I have =
uploaded a new version
>>> =
https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-0=
1.txt
>>>=20
>>> I didn't get any comments on my answers given to Dales mail which =
also covered the comments made within the meeting report.
>>>=20
>>> ETSI is still looking forward on processing this document for their =
solution on Emergency Call due to the Project of  the European Union =
Mandate: M493.
>>>=20
>>> Comments and improvements are welcome.
>>>=20
>>> Question is how to proceed further since I did not get any further =
comments since my last mail on 4th April.
>>>=20
>>> Best Regards
>>>=20
>>> Roland
>>>=20
>>>> -----Urspr=C3=BCngliche Nachricht-----
>>>> Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>> Gesendet: Dienstag, 23. Mai 2017 14:45
>>>> An: Jesske, Roland; Bruno Chatras; James Winterbottom; Andrew =
Hutton
>>>> Betreff: New Version Notification for draft-winterbottom-sipcore-
>>>> locparam-01.txt
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-winterbottom-sipcore-locparam-01.txt
>>>> has been successfully submitted by Roland Jesske and posted to the =
IETF
>>>> repository.
>>>>=20
>>>> Name:		draft-winterbottom-sipcore-locparam
>>>> Revision:	01
>>>> Title:		Location Source Parameter for the SIP =
Geolocation
>>>> Header Field
>>>> Document date:	2017-05-23
>>>> Group:		Individual Submission
>>>> Pages:		8
>>>> URL:            =
https://www.ietf.org/internet-drafts/draft-winterbottom-
>>>> sipcore-locparam-01.txt
>>>> Status:         =
https://datatracker.ietf.org/doc/draft-winterbottom-
>>>> sipcore-locparam/
>>>> Htmlized:       =
https://tools.ietf.org/html/draft-winterbottom-sipcore-
>>>> locparam-01
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>>>> winterbottom-sipcore-locparam-01
>>>> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-
>>>> sipcore-locparam-01
>>>>=20
>>>> Abstract:
>>>> There are some circumstances where a geolocation header field may
>>>> contain more than one location value.  Knowing the identity of the
>>>> node adding the location value allows the recipient more freedom in
>>>> selecting the value to look at first rather than relying solely on
>>>> the order of the location values.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at
>>>> tools.ietf.org.
>>>>=20
>>>> The IETF Secretariat
>>>=20
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>=20
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From nobody Tue May 23 12:55:00 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A7E12EAED for ; Tue, 23 May 2017 12:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 p4e_Xa4YRcNj for ; Tue, 23 May 2017 12:54:57 -0700 (PDT)
Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 D85BC12EAE2 for ; Tue, 23 May 2017 12:54:57 -0700 (PDT)
Received: by mail-pf0-x242.google.com with SMTP id f27so29676591pfe.0 for ; Tue, 23 May 2017 12:54:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xj3FaTjW4T2Aczt/M1uOpIhm7mICRnB2M/+d0ugNfqs=; b=jK/i2ElRThKihneW+XHoQ45YPPmpWRiqF2acuk0JWdt7+4V3Lw+kheLerh6BUAq8Gh JFpR8GsurU1wmL8dyvRzArnV/WPQKPopFCAuvkgDsVevY64JAxKtOOBzPV76WLYfFVeG /+Ek9pmQlAa5i1ZkNFi0NLTwfJdCXoJYhvSJqwZYNbavDVVtntIPa1iiZ75dR+xC0jND 3nqksnEldcdP84+Bipjb9GmDb5dj3wt/MQFCJdeiSKSTLcWlcl4WEfjEzR8HwB+ctt1T LE5ajcjfIKw4DF2pgWKwvqdzeR4zPMT70wQM+vIzrQ1iuaLGMVdBNUZygxJdUxzJYmLc wAlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xj3FaTjW4T2Aczt/M1uOpIhm7mICRnB2M/+d0ugNfqs=; b=KjS/X65k/741W8Pq594UwRVCK51ZwNB7I3k4OJB3q9+2iYBuRGRV+tZrEK+3OwKk5h TfRtOOw/TnIQLCAhR9L7LsoELqDNpnvZgb1jziGCreX4RGBYP2jwPf2RR9ReJ8vttnEF b1/kwFFn+hRiAhth0Zuys7I9zs8c+D8/2/eBohlN9aOvrfiR0Sxgrq7qVzy4SGNnqA20 TXdaqUgf1RtLUi+cu43vLpENeknldnCQeK/erzOeILHKYoCbwQ3ohxbVmIc7K2Orxrla k6WKIW17xi4ilU+IEDyUxoqR6E2A7oWSi7iJpVbbmWTG/40BzwZq3f4foPheQXMpTfMG k5Ig==
X-Gm-Message-State: AODbwcAnSXEiTpdBFupbFdCF04MfrybPy9KJWP/V2KKKe5sKlS5+leDD DFWOe+0V4WMk9g==
X-Received: by 10.84.136.70 with SMTP id 64mr38686803plk.82.1495569296019; Tue, 23 May 2017 12:54:56 -0700 (PDT)
Received: from ?IPv6:2001:8000:1054:d300:1139:59aa:f06b:5ec2? ([2001:8000:1054:d300:1139:59aa:f06b:5ec2]) by smtp.gmail.com with ESMTPSA id e124sm3506292pfc.64.2017.05.23.12.54.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 May 2017 12:54:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: James Winterbottom 
In-Reply-To: <8FE4ADF5-7C50-4BEE-A3AA-2CCAED505EE5@brianrosen.net>
Date: Wed, 24 May 2017 05:54:49 +1000
Cc: Brian Rosen , "Hutton, Andrew" , sipcore@ietf.org, bruno.chatras@orange.com, R.Jesske@telekom.de
Content-Transfer-Encoding: quoted-printable
Message-Id: <84E31F68-FE43-45B7-A16E-8DBD38C3E214@gmail.com>
References: <149554350753.16443.17633151256632718640.idtracker@ietfa.amsl.com> <159c97974a8749d4ab71016f57a768db@HE105828.emea1.cds.t-internal.com>  <75D7EE00-BE2B-4C6E-91DE-819AF015542F@gmail.com> <8FE4ADF5-7C50-4BEE-A3AA-2CCAED505EE5@brianrosen.net>
To: Brian Rosen 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] New Version Notification for draft-winterbottom-sipcore-locparam-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 May 2017 19:55:00 -0000

In the M/493 case yes they are very different.
If the Geolocation header field contains multiple values, then the =
locparam allows the node using the location to decide which one it likes =
best without having to go and fetch them all.

So yes, I think it does provide a differentiator.

Cheers
James



> On 24 May 2017, at 5:51 am, Brian Rosen  wrote:
>=20
> Is there a practical difference between who determined location and =
who put it in the header?
>=20
> Is there a reason you can=E2=80=99t (or even more likely, wouldn=E2=80=99=
t normally) dereference the URI, and thus get the =20
> in every circumstance where the locparam would be used?
>=20
> Brian
>=20
>> On May 23, 2017, at 3:35 PM, James Winterbottom =
 wrote:
>>=20
>> Hi Brian,
>>=20
>> Provided-by doesn=E2=80=99t work for two reasons.
>>=20
>> 1) Provided-by says who determined the location, not who put the =
thing into the geolocation header
>> 2) provided-by only works if you sending location by value, which in =
the European case we are not.
>>=20
>>=20
>> Cheers
>> James
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On 23 May 2017, at 11:40 pm, Brian Rosen  =
wrote:
>>>=20
>>> 
>>> I had asked a question on this, which was, why isn=E2=80=99t =
 an acceptable solution to the problem?
>>>=20
>>> I didn=E2=80=99t see an answer.
>>>=20
>>> Brian
>>>> On May 23, 2017, at 9:04 AM, R.Jesske@telekom.de wrote:
>>>>=20
>>>> Dear all,
>>>>=20
>>>> After reworking the draft due to the comments made by Dale, I have =
uploaded a new version
>>>> =
https://www.ietf.org/internet-drafts/draft-winterbottom-sipcore-locparam-0=
1.txt
>>>>=20
>>>> I didn't get any comments on my answers given to Dales mail which =
also covered the comments made within the meeting report.
>>>>=20
>>>> ETSI is still looking forward on processing this document for their =
solution on Emergency Call due to the Project of  the European Union =
Mandate: M493.
>>>>=20
>>>> Comments and improvements are welcome.
>>>>=20
>>>> Question is how to proceed further since I did not get any further =
comments since my last mail on 4th April.
>>>>=20
>>>> Best Regards
>>>>=20
>>>> Roland
>>>>=20
>>>>> -----Urspr=C3=BCngliche Nachricht-----
>>>>> Von: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>>> Gesendet: Dienstag, 23. Mai 2017 14:45
>>>>> An: Jesske, Roland; Bruno Chatras; James Winterbottom; Andrew =
Hutton
>>>>> Betreff: New Version Notification for draft-winterbottom-sipcore-
>>>>> locparam-01.txt
>>>>>=20
>>>>>=20
>>>>> A new version of I-D, draft-winterbottom-sipcore-locparam-01.txt
>>>>> has been successfully submitted by Roland Jesske and posted to the =
IETF
>>>>> repository.
>>>>>=20
>>>>> Name:		draft-winterbottom-sipcore-locparam
>>>>> Revision:	01
>>>>> Title:		Location Source Parameter for the SIP =
Geolocation
>>>>> Header Field
>>>>> Document date:	2017-05-23
>>>>> Group:		Individual Submission
>>>>> Pages:		8
>>>>> URL:            =
https://www.ietf.org/internet-drafts/draft-winterbottom-
>>>>> sipcore-locparam-01.txt
>>>>> Status:         =
https://datatracker.ietf.org/doc/draft-winterbottom-
>>>>> sipcore-locparam/
>>>>> Htmlized:       =
https://tools.ietf.org/html/draft-winterbottom-sipcore-
>>>>> locparam-01
>>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-
>>>>> winterbottom-sipcore-locparam-01
>>>>> Diff:           =
https://www.ietf.org/rfcdiff?url2=3Ddraft-winterbottom-
>>>>> sipcore-locparam-01
>>>>>=20
>>>>> Abstract:
>>>>> There are some circumstances where a geolocation header field may
>>>>> contain more than one location value.  Knowing the identity of the
>>>>> node adding the location value allows the recipient more freedom =
in
>>>>> selecting the value to look at first rather than relying solely on
>>>>> the order of the location values.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Please note that it may take a couple of minutes from the time of
>>>>> submission until the htmlized version and diff are available at
>>>>> tools.ietf.org.
>>>>>=20
>>>>> The IETF Secretariat
>>>>=20
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipcore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>=20
>>=20
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>=20


From nobody Tue May 23 23:22:55 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C30126E3A; Tue, 23 May 2017 23:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 90D0ZJqPp7W2; Tue, 23 May 2017 23:22:52 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32881204DA; Tue, 23 May 2017 23:22:51 -0700 (PDT)
X-AuditID: c1b4fb2d-5a49e9a000000d37-e5-592526765221
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E8.8D.03383.67625295; Wed, 24 May 2017 08:21:42 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Wed, 24 May 2017 08:21:40 +0200
From: Christer Holmberg 
To: Ben Campbell 
CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05
Thread-Index: AQHSzolPaE+D+c83j0ekLBIazLog+6IAT7OAgABMwwCAAnGaEA==
Date: Wed, 24 May 2017 06:21:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBC5FC9@ESESSMB109.ericsson.se>
References:   <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com>
In-Reply-To: <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7qO5ONdVIg+ltJhbzO0+zW8w8u4vF 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV0bDPYOCWw4Vy/61sTcwtth3MXJy SAiYSJzbuJmxi5GLQ0jgCKPE22UXmCGcxYwSW97NAspwcLAJWEh0/9MGaRARUJJ43ryVBaSG WaCDUeLpkj5WkISwgJ1E07I5TCD1IgL2EvuniEPUO0k8etDNBGKzCKhKrFr1ggWkhFfAV2LD L1WIVUsZJb717gFr5QRqffFKDqScUUBM4vupNWCtzALiEreezGeCuFlAYsme88wQtqjEy8f/ WCFsJYnGJU9YQcYwC2hKrN+lD9GqKDGl+yE7iM0rIChxcuYTlgmMorOQTJ2F0DELSccsJB0L GFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgRGysEtv3V3MK5+7XiIUYCDUYmHt15ANVKI NbGsuDL3EKMEB7OSCK+JGFCINyWxsiq1KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZqakF qUUwWSYOTqkGRp0EpgiTt1LHtSZ37hM4HRn3RTiHVbxCWf/30Wk/TvqmHJ/L/fjlelnbL3F3 trNwBrdH/dq19zhr/lLOuT8n/fBd9rU6p70peFZ953uLR5sFTYtm/rhS8Jep2TRqm/O5htem qpnsFdksosq5F+ZMKfB78bHkzWKebUXbM+aff7tcTLPFZ1JKqxJLcUaioRZzUXEiAJkkqT6Q AgAA
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 May 2017 06:22:54 -0000

SGksDQogIA0KRGlzY3Vzc2lvbiBQb2ludHM6DQogIA0KPj4+LSBJIGhhdmUgc29tZSBkaWZmaWN1
bHR5IHNlZWluZyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJ0aGUgYm9keSBhbmQNCj4+PnJlbGF0
ZWQgbWV0YWRhdGEiIGFuZCAidGhlIFNJUCBtZXNzYWdlIi4gSSByZWFsaXplIHlvdSBoYXZlIHRo
ZSBtb3JlIA0KPj4+TUlNRS1zcGVjaWZpYyBoZWFkZXIgZmllbGRzIGluIG1pbmQgd2hlbiB5b3Ug
c2F5ICJtZXRhZGF0YSIuIEJ1dCBhbnkgDQo+Pj5TSVAgaGVhZGVyIGZpZWxkIGNvdWxkIGJlIGNv
bnNpZGVyZWQgbWV0YWRhdGEuDQo+PiAgDQo+PiAoQ2hyaXN0ZXIpIEFzIG1ldGFkYXRhLCB3ZSBh
cmUgb25seSBjb25zaWRlcmluZyBTSVAgaGVhZGVyIGZpZWxkcyANCj4+IHRoYXQgYXJlIGFsc28g
ZGVmaW5lZCBhcyBNSU1FIGhlYWRlciBmaWVsZHMuDQo+PiAgDQo+Pj5UaGUgbWFpbiBwb2ludCBv
ZiB0aGF0IHF1ZXN0aW9uIGlzLCBhcyB1c2VkIGluIE1JTUUsIENvbnRlbnQtSWQgaXMNCj4+Pmlu
dGVuZGVkIHRvIGxhYmVsIGEgYm9keSBwYXJ0LiBNZXNzYWdlLUlkIGlzIHVzZWQgdG8gbGFiZWwg
dGhlIHdob2xlIA0KPj4+bWVzc2FnZS4gQXJlbid0IHdlIHRhbGtpbmcgYWJvdXQgdGhlIHdob2xl
IG1lc3NhZ2UgaGVyZT8NCj4+ICANCj4+IChDaHJpc3RlcikgTm8uDQo+DQo+V2UgYXJlIGJvcnJv
d2luZyB0aGlzIGZyb20gdGhlIHVzYWdlIGluIGVtYWlsLCB3aGVyZSBwZW9wbGUgdXN1YWxseSAN
Cj5jb25zaWRlciBfYWxsXyB0aGUgaGVhZGVyIGZpZWxkcyBhcyBtZXRhZGF0YSwgdGh1cyB0aGUg
dXNhZ2Ugb2YgDQo+Ik1lc3NhZ2UtSWQiIHJhdGhlciB0aGFuICJDb250ZW50LUlkIiB3aGVuIHJl
ZmVycmluZyB0byB0aGUgZW50aXJlIA0KPmNvbnRlbnRzLiBJwrltIG5vdCBzYXlpbmcgaXTCuXMg
d3JvbmcgdG8gZG8gaXQgZGlmZmVyZW50bHkgZm9yIFNJUCwgYnV0IA0KPml0IHdvdWxkIGJlIGdv
b2QgdG8gaW5jbHVkZSBzb21lIG1vdGl2YXRpb24gZm9yIHRoYXQgZGlmZmVyZW5jZS4gSSANCj5z
dXNwZWN0IHRoZSBkaWZmZXJlbmNlIGhhcyB0byBkbyB3aXRoIHRoZSBwdXJwb3NlIG9mIGVtYWls
IGJlaW5nIHRvIA0KPmRlbGl2ZXIgdGhlIGNvbnRlbnQsIHdoaWxlIGZvciBTSVAgdGhlIHB1cnBv
c2Ugb2YgdGhlIGNvbnRlbnQgaXMgdG8gDQo+bW9kaWZ5IHRoZSBoYW5kbGluZyBvZiBzZXNzaW9u
IGluaXRpYXRpb24uIEluIHdoaWNoIGNhc2Ugb25lIG1pZ2h0IA0KPmNvbnNpZGVyIHRoZSBjb250
ZW50IGl0c2VsZiBhcyDCs21ldGFkYXRhwrIuIChJwrltIGN1cmlvdXMgdG8gaGVhciBpZiANCj50
aGVyZSBhcmUgb3RoZXINCj5yZWFzb25zLikNCg0KKENocmlzdGVyKSBJIGhhdmUgdG8gc2F5IHRo
YXQgSSBhbSBnZXR0aW5nIGEgbGl0dGxlIGxvc3QuLi4NCg0KV2l0aCBhIG11bHRpcGFydCBib2R5
LCBlYWNoIGJvZHkgcGFydCBNSU1FIGNhbiBjb250YWluIE1JTUUgaGVhZGVyIGZpZWxkcyBwcm92
aWRpbmcgbWV0YWRhdGEgZm9yIHRoYXQgc3BlY2lmaWMgYm9keSBwYXJ0Lg0KDQpXaXRoIGEgbm9u
LW11bHRpcGFydCBib2R5LCB5b3UgY2FuIHRvZGF5IGRvIHRoZSBzYW1lIHRoaW5nIHVzaW5nIE1J
TUUgaGVhZGVyIGZpZWxkcyB0aGF0IGhhdmUgYmVlbiBkZWZpbmVkIGFzIFNJUCBoZWFkZXIgZmll
bGQgKENvbnRlbnQtVGhpcywgQ29udGVudC1UaGF0KS4gSG93ZXZlciwgQ29udGVudC1JRCBoYXMg
bm90IGJlZW4gZGVmaW5lZCBhcyBhIFNJUCBoZWFkZXIgZmllbGQsIGFuZCB0aGF0IGlzIHdoYXQg
d2UgZG8gaW4gdGhlIGRyYWZ0LiBXZSBhcmUgbm90IGFkZGluZyBuZXcgbWV0YWRhdGEsIG9yIGV4
dGVuZGluZyB0aGUgc2NvcGUgb2YgdGhlIG1ldGFkYXRhIC0gd2Ugc2ltcGx5IGFsbG93IHVzaW5n
IHRoZSBzYW1lIG1ldGFkYXRhIHRvIGRlc2NyaWJlIGEgbm9uLW11bHRpcGFydCBib2R5IGFzIHlv
dSBjYW4gdXNlIHRvIGRlc2NyaWJlIGJvZHkgcGFydHMgaW4gYSBtdWx0aXBhcnQgYm9keS4NCg0K
SWYgeW91ciBpc3N1ZSBpcyBjYXVzZWQgYnkgdXNhZ2Ugb2YgdGhlIHRlcm0gIm1ldGFkYXRhIiB3
aXRob3V0IGEgZm9ybWFsIGRlZmluaXRpb24sIHRoZW4gd2UgY2FuIGRlZmluZSB0aGUgdGVybSAi
bWV0YWRhdGEiIGFzICJhIE1JTUUtVmVyc2lvbiBTSVAgaGVhZGVyIGZpZWxkIGFuZCBhbnkgJ0Nv
bnRlbnQtJyBwcmVmaXhlZCBTSVAgaGVhZGVyIGZpZWxkIi4gT3IsIHdlIGNhbiByZXBsYWNlIGFu
eSBvY2N1cnJlbmNlIG9mIHRoZSB0ZXJtICJtZXRhZGF0YSIgd2l0aCAiYSBNSU1FLVZlcnNpb24g
U0lQIGhlYWRlciBmaWVsZCBhbmQgYW55ICdDb250ZW50LScgcHJlZml4ZWQgU0lQIGhlYWRlciBm
aWVsZCIgaW4gdGhlIGRyYWZ0Lg0KICANCj4+Pi0gSXMgdGhlcmUgYW4gZXhwZWN0YXRpb24gZm9y
IHRoZSBTSVAgQ29udGVudC1JRCBoZWFkZXIgZmllbGQgdmFsdWUgDQo+Pj50byBiZSByZWZlcmVu
Y2VkIGZyb20gb3V0c2lkZSB0aGUgU0lQIG1lc3NhZ2U/IElmIHNvLCB3aGF0IGFyZSB0aGUgDQo+
Pj51bmlxdWVuZXNzIGV4cGVjdGF0aW9ucz8gTm90ZSB0aGF0IGZvciBNSU1FLCBDb250ZW50LUlE
IGlzIGV4cGVjdGVkIHRvIA0KPj4+YmUgZ2xvYmFsbHkgdW5pcXVlLiBJcyB0aGF0IHRoZSBjYXNl
IGhlcmU/DQo+PiAgDQo+PihDaHJpc3RlcikgVGhlIGRyYWZ0IGRvZXMgbm90IGNoYW5nZSB0aGUg
dW5pcXVlbmVzcyByZXF1aXJlbWVudHMgb2YgDQo+PkNvbnRlbnQtSUQuDQo+PiAgDQo+Pj5JZiB0
aGUgQ29udGVudC1JRCBpcyBfbm90XyBleHBlY3RlZCB0byBiZSByZWZlcmVuY2VkIGZyb20gb3V0
c2lkZSBvZg0KPj4+dGhlIFNJUCBtZXNzYWdlIHRoYXQgY29udGFpbnMgaXQsIHRoZW4gd2UgaGF2
ZSBhIHNvcnQgb2YgZGVnZW5lcmF0ZSANCj4+PmNhc2Ugd2hlcmUgaXQgYWx3YXlzIGlkZW50aWZp
ZXMgX3RoaXNfIG1lc3NhZ2UgcmVnYXJkbGVzcyBvZiB0aGUgDQo+Pj52YWx1ZS4gRG9lcyB0aGF0
IHZhbHVlIGV2ZXIgbmVlZCB0byBjaGFuZ2U/IERvZXMgdGhhdCBzdWdnZXN0ID5hbnkgDQo+Pj5n
dWlkYW5jZSBvbiBob3cgdG8gY29uc3RydWN0IHZhbHVlcz8NCj4+ICANCj4+KENocmlzdGVyKSBS
RkMgNTYyMSBkb2VzIG5vdCBkZWZpbmUgdGhlIGFib3ZlIGNoYXJhY3RlcmlzdGljcyBmb3IgDQo+
Pm11bHRpcGFydCBib2R5IHVzYWdlLCBhbmQgSSBzZWUgbm8gcmVhc29uIGhvdyBhbnl0aGluZyB3
b3VsZCBiZSANCj4+ZGlmZmVyZW50IGZvciBhIG5vbi1tdWx0aXBhcnQgbWVzc2FnZSBib2R5LiBJ
ZiB5b3UgdGhpbmsgdGhlcmUgaXMgDQo+PnNvbWV0aGluZyBnZW5lcmljIGFib3V0IENvbnRlbnQt
SUQgdGhhdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQgSSB0aGluayANCj4+dGhhdCBzaG91bGQgYmUg
ZG9uZSBhcyBhIHNlcGFyYXRlIHRhc2suICANCj4NCj41MjYxIHVzZWQgdGhlIENvbnRlbnQtSWQg
TUlNRSBoZWFkZXIgZmllbGQuIFRoYXQgZmllbGQgYW5kIGl0wrlzIA0KPnVuaXF1ZW5lc3MgcmVx
dWlyZW1lbnRzIGFyZSBkZWZpbmVkIGVsc2V3aGVyZS4gVGhpcyBkcmFmdCBkZWZpbmVzIGEgDQo+
Q29udGVudC1JRCBzaXAgaGVhZGVyIGZpZWxkLiBUaGF0IGRpZG7CuXQgZXhpc3QgYmVmb3JlLiBU
aGVyZWZvcmUgSSANCj50aGluayB0aGlzIG5lZWRzIHRvIGRlc2NyaWJlIHRoZSB1bmlxdWVuZXNz
IHJlcXVpcmVtZW50cy4NCj4NCj41MzIyIHJlcXVpcmVzIG1zZy1pZCB0byBiZSBnbG9iYWxseSB1
bmlxdWUgYmVjYXVzZSBpdMK5cyBpbnRlbmRlZCB0byBiZSANCj51c2VmdWwgb3V0c2lkZSB0aGUg
Y29udGV4dCBvZiB0aGUgZ2l2ZW4gbWVzc2FnZS4gSXMgdGhhdCB0aGUgY2FzZSBoZXJlPw0KPklm
IG5vdCwgdGhlbiBhIGdsb2JhbGx5IHVuaXF1ZW5lc3MgcmVxdWlyZW1lbnQgbWF5IG5vdCBtYWtl
IHNlbnNlIGluIA0KPnRoaXMgY29udGV4dC4gKElJVUMsIGV2ZXJ5IHNpbmdsZSBpbnN0YW5jZSBv
ZiB0aGUgQ29udGVudC1JZCBTSVAgaGVhZGVyIA0KPmZpZWxkIGNvdWxkIGhhdmUgdGhlIHNhbWUs
IGlkZW50aWNhbCB2YWx1ZSwgYW5kIHRoaW5ncyB3b3VsZCB3b3JrIA0KPmZpbmUuKQ0KDQooQ2hy
aXN0ZXIpIEkgaGF2ZSBuZXZlciBoZWFyZCBhYm91dCBDb250ZW50LUlEIGJlaW5nIHVzZWQgb3V0
c2lkZSB0aGUgY29udGV4dCBvZiBhIGdpdmVuIG1lc3NhZ2UsIHNvIEkgdGhpbmsgdGhlIHZhbHVl
IG9ubHkgbmVlZHMgdG8gYmUgdW5pcXVlIHdpdGhpbiBhIGdpdmVuIG1lc3NhZ2UuDQoNCiAgDQpT
cGVjaWZpYyBjb21tZW50czoNCiAgDQo+Pj4xLjQgYW5kIGNoaWxkcmVuOiBUaGVzZSBleGFtcGxl
cyBzZWVtIGxpa2UgZmFpcmx5IHdlYWsgbW90aXZhdGlvbiwNCj4+PnNpbmNlIEkgYXNzdW1lIGlu
IGJvdGggY2FzZXMgb25lIGNvdWxkIHN0aWxsIGhhdmUganVzdCBwdXQgYSBzaW5nbGUgDQo+Pj5i
b2R5LXBhcnQgaW5zaWRlIGEgbXVsdGlwYXJ0IGVudmVsb3BlLiBUaGF0DQo+Pj5zZWVtcyBtb3Jl
IGFuICJpbmNvbnZlbmllbmNlIiB0aGFuIGEgInByb2JsZW0iLiBBcmUgdGhlcmUgYW55IGtub3du
DQo+Pj51c2UtY2FzZXMgd2hlcmUgdGhhdCB3b3VsZCBub3QgYmUgcG9zc2libGU/IChUaGlzIGlz
IGNlcnRhaW5seSBub3QgYSANCj4+PnNob3cgc3RvcHBlcjsgd2UgYXJlIGFsbG93ZWQgdG8gc29s
dmUNCj4+PmluY29udmVuaWVuY2VzLiBCdXQgaWYgdGhlcmUgYXJlIGFueSBzdHJvbmdlciBtb3Rp
dmF0aW9ucyB0aGF0IGNvdWxkDQo+Pj5iZSBkb2N1bWVudGVkLCB0aGV5IG1pZ2h0IHNhdmUgcXVl
c3Rpb25zIGRvd24gdGhlIHJvYWQuKQ0KPj4gIA0KPj4oQ2hyaXN0ZXIpIEkgY2FuJ3QgdGhpbmsg
b2YgYW55IHVzZS1jYXNlcyB3aGVyZSBpdCB3b3VsZCBub3QgYmUgDQo+PnBvc3NpYmxlIHRvIHVz
ZSBhIHNpbmdsZS1ib2R5IGluc2lkZSBhIG11bHRpcGFydCBlbnZlbG9wZSBpbnN0ZWFkLiBTbywg
DQo+Pml0IGlzIGFib3V0ICJjb252ZW5pZW5jZSIuDQo+DQo+VGhlIHdvcmQgIm9wdGltaXphdGlv
biIgY29tZXMgdG8gbWluZC4NCg0KKENocmlzdGVyKSBJIGd1ZXNzIHRoYXQgd29ya3MgdG9vIDop
DQoNCj4+PjMuMiwgMm5kIG5vdGU6IEhvdyBoYXMgdGhlIG1zZy1JZCBiZWVuIHNpbXBsaWZpZWQs
IGFuZCB3aHk/DQo+PiAgDQo+PiAoQ2hyaXN0ZXIpIFRoZSBzaW1wbGlmaWNhdGlvbiB3YXMgZG9u
ZSBiYXNlZCBvbiBhIGNvbW1lbnQgZnJvbSBEYWxlIFcuDQo+PiAgDQo+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzg2Mi5odG1sDQo+
DQo+SSB0aGluayBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHNheSBzb21ldGhpbmcgbGlrZSDCs8Wg
IHNpbXBsaWZpZWQgdG8gDQo+ZGlzYWxsb3cgdGhlIHVzZSBvZiBjb21tZW50cyBhbmQgdG8gYWRh
cHQgdG8gU0lQwrlzIHVzZSBvZiBsZWFkaW5nIHdoaXRlIA0KPnNwYWNlLiINCg0KKENocmlzdGVy
KSBPaywgd2XCuWxsIGFkZCBzb21lIHRleHQuDQoNCiAgICANCkVkaXRvcmlhbDoNCiAgDQo+Pj4x
LjEsIDNyZCBwYXJhZ3JhcGg6IENpdGF0aW9uIHRvIFJGQzU2MjEgaXMgbm90IGEgbGluayBpbiB0
aGUgUERGIHZlcnNpb24uDQo+PiAgDQo+PihDaHJpc3RlcikgVGhhdMK5cyBzdHJhbmdlLiBJIGNo
ZWNrZWQgdGhlIFhNTCBmaWxlLCBhbmQgZXZlcnl0aGluZyANCj4+c2VlbXMgY29ycmVjdC4gQ291
bGQgdGhlIGZhY3QgdGhhdCB0aGUgc2VudGVuY2Ugc3RhcnRzIHdpdGggdGhlIA0KPj5yZWZlcmVu
Y2UgaGF2ZSBhbnl0aGluZyB0byBkbyB3aXRoIGl0Pw0KPj4gIA0KPj48dD48eHJlZiB0YXJnZXQ9
IlJGQzU2MjEiIHBhZ2Vubz0iZmFsc2UiIGZvcm1hdD0iZGVmYXVsdCIvPiBkZWZpbmVzIA0KPj5n
ZW5lcmljIGhhbmRsaW5nIG9mIGEgbXVsdGlwYXJ0IG1lc3NhZ2UtYm9keSBpbiBhIFNJUCBtZXNz
YWdlLjwvdD4NCj4NCj5JIGRvbsK5dCBrbm93LCBpdCBtYXkgYmUgYW4geG1sMnJmYyBidWcuIElm
IHRoZXJlwrlzIG5vIGVycm9yIGluIHRoZSB4bWwsIA0KPnRoZW4gd2UgY291bGQgbGVhdmUgdGhp
cyB0byB0aGUgUkZDIGVkaXRvci4NCg0KKENocmlzdGVyKSBPay4NCg0KUmVnYXJkcywNCg0KQ2hy
aXN0ZXINCg==


From nobody Thu May 25 13:49:59 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BA01275AB; Thu, 25 May 2017 13:49:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 66bLVQ_xV2Um; Thu, 25 May 2017 13:49:55 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EE04C126C23; Thu, 25 May 2017 13:49:54 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4PKnnaT064725 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 25 May 2017 15:49:50 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBC5FC9@ESESSMB109.ericsson.se>
Date: Thu, 25 May 2017 15:49:50 -0500
Cc: "draft-ietf-sipcore-content-id.all@ietf.org" ,  "sipcore@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7ECBF64F-0C31-4924-8627-02E5C31EDC26@nostrum.com>
References:   <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CBC5FC9@ESESSMB109.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 May 2017 20:49:58 -0000

> On May 24, 2017, at 1:21 AM, Christer Holmberg =
 wrote:
>=20
> Hi,
>=20
> Discussion Points:
>=20
>>>> - I have some difficulty seeing the difference between "the body =
and
>>>> related metadata" and "the SIP message". I realize you have the =
more=20
>>>> MIME-specific header fields in mind when you say "metadata". But =
any=20
>>>> SIP header field could be considered metadata.
>>>=20
>>> (Christer) As metadata, we are only considering SIP header fields=20
>>> that are also defined as MIME header fields.
>>>=20
>>>> The main point of that question is, as used in MIME, Content-Id is
>>>> intended to label a body part. Message-Id is used to label the =
whole=20
>>>> message. Aren't we talking about the whole message here?
>>>=20
>>> (Christer) No.
>>=20
>> We are borrowing this from the usage in email, where people usually=20=

>> consider _all_ the header fields as metadata, thus the usage of=20
>> "Message-Id" rather than "Content-Id" when referring to the entire=20
>> contents. I=C2=B9m not saying it=C2=B9s wrong to do it differently =
for SIP, but=20
>> it would be good to include some motivation for that difference. I=20
>> suspect the difference has to do with the purpose of email being to=20=

>> deliver the content, while for SIP the purpose of the content is to=20=

>> modify the handling of session initiation. In which case one might=20
>> consider the content itself as =C2=B3metadata=C2=B2. (I=C2=B9m =
curious to hear if=20
>> there are other
>> reasons.)
>=20
> (Christer) I have to say that I am getting a little lost...
>=20
> With a multipart body, each body part MIME can contain MIME header =
fields providing metadata for that specific body part.
>=20
> With a non-multipart body, you can today do the same thing using MIME =
header fields that have been defined as SIP header field (Content-This, =
Content-That). However, Content-ID has not been defined as a SIP header =
field, and that is what we do in the draft. We are not adding new =
metadata, or extending the scope of the metadata - we simply allow using =
the same metadata to describe a non-multipart body as you can use to =
describe body parts in a multipart body.
>=20
> If your issue is caused by usage of the term "metadata" without a =
formal definition, then we can define the term "metadata" as "a =
MIME-Version SIP header field and any 'Content-' prefixed SIP header =
field". Or, we can replace any occurrence of the term "metadata" with "a =
MIME-Version SIP header field and any 'Content-' prefixed SIP header =
field" in the draft.

My issue is not caused by the definition of the metadata in question =
(3.3 does a reasonable job of that.) It was more a question of why you =
chose to limit the metadata to that set, which somewhat goes against the =
way people think about email=E2=80=94and all of this comes from email. =
But I recognize that the way SIP uses bodies is different than the way =
email uses them. So let=E2=80=99s go with the thinking in the draft, and =
see if anyone objects in IETF LC (where I still hope to get a MIME =
expert review.)

(To be clear, that means no change needed due to this particular =
discussion point.)

>=20
>>>> - Is there an expectation for the SIP Content-ID header field value=20=

>>>> to be referenced from outside the SIP message? If so, what are the=20=

>>>> uniqueness expectations? Note that for MIME, Content-ID is expected =
to=20
>>>> be globally unique. Is that the case here?
>>>=20
>>> (Christer) The draft does not change the uniqueness requirements of=20=

>>> Content-ID.
>>>=20
>>>> If the Content-ID is _not_ expected to be referenced from outside =
of
>>>> the SIP message that contains it, then we have a sort of degenerate=20=

>>>> case where it always identifies _this_ message regardless of the=20
>>>> value. Does that value ever need to change? Does that suggest >any=20=

>>>> guidance on how to construct values?
>>>=20
>>> (Christer) RFC 5621 does not define the above characteristics for=20
>>> multipart body usage, and I see no reason how anything would be=20
>>> different for a non-multipart message body. If you think there is=20
>>> something generic about Content-ID that needs to be clarified I =
think=20
>>> that should be done as a separate task. =20
>>=20
>> 5261 used the Content-Id MIME header field. That field and it=C2=B9s=20=

>> uniqueness requirements are defined elsewhere. This draft defines a=20=

>> Content-ID sip header field. That didn=C2=B9t exist before. Therefore =
I=20
>> think this needs to describe the uniqueness requirements.
>>=20
>> 5322 requires msg-id to be globally unique because it=C2=B9s intended =
to be=20
>> useful outside the context of the given message. Is that the case =
here?
>> If not, then a globally uniqueness requirement may not make sense in=20=

>> this context. (IIUC, every single instance of the Content-Id SIP =
header=20
>> field could have the same, identical value, and things would work=20
>> fine.)
>=20
> (Christer) I have never heard about Content-ID being used outside the =
context of a given message, so I think the value only needs to be unique =
within a given message

Are you expecting to ever have both the SIP header field and one or more =
MIME Content-ID header fields in the same message? If so, then text to =
the effect of the following seems to make sense:

=E2=80=9CThe value of Content-Id header field value must be unique in =
the context of a given SIP message, including any imbedded MIME =
Content-Id header field values. Note that the SIP Content-ID header =
field value is not expected to be unique among all SIP messages; it has =
no meaning outside of the message in which it is included.=E2=80=9D=20

If, OTOH, you think there might ever be a need to reference a body from =
a different SIP message, then we would need it to be globally unique.



>=20
>=20
> Specific comments:
>=20
>>>> 1.4 and children: These examples seem like fairly weak motivation,
>>>> since I assume in both cases one could still have just put a single=20=

>>>> body-part inside a multipart envelope. That
>>>> seems more an "inconvenience" than a "problem". Are there any known
>>>> use-cases where that would not be possible? (This is certainly not =
a=20
>>>> show stopper; we are allowed to solve
>>>> inconveniences. But if there are any stronger motivations that =
could
>>>> be documented, they might save questions down the road.)
>>>=20
>>> (Christer) I can't think of any use-cases where it would not be=20
>>> possible to use a single-body inside a multipart envelope instead. =
So,=20
>>> it is about "convenience".
>>=20
>> The word "optimization" comes to mind.
>=20
> (Christer) I guess that works too :)

Okay, no change needed.

>=20
>>>> 3.2, 2nd note: How has the msg-Id been simplified, and why?
>>>=20
>>> (Christer) The simplification was done based on a comment from Dale =
W.
>>>=20
>>> https://www.ietf.org/mail-archive/web/sipcore/current/msg07862.html
>>=20
>> I think it would be helpful to say something like =C2=B3=C5=A0 =
simplified to=20
>> disallow the use of comments and to adapt to SIP=C2=B9s use of =
leading white=20
>> space."
>=20
> (Christer) Ok, we=C2=B9ll add some text.

Thanks. If you can submit a version with that change, as well as some =
guidance on uniqueness as discussed above, I think it will be ready for =
IETF LC.

Thanks!

Ben.




From nobody Fri May 26 03:17:00 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73CB129C15; Fri, 26 May 2017 03:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 SShF3Wvj9X7V; Fri, 26 May 2017 03:16:57 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88425129B43; Fri, 26 May 2017 03:16:56 -0700 (PDT)
X-AuditID: c1b4fb2d-5a49e9a000000d37-9c-59280096b50d
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.14.03383.69008295; Fri, 26 May 2017 12:16:54 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Fri, 26 May 2017 12:16:53 +0200
From: Christer Holmberg 
To: Ben Campbell 
CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05
Thread-Index: AQHSzolPaE+D+c83j0ekLBIazLog+6IAT7OAgABMwwCAAnGaEIACZD0AgAEVeAA=
Date: Fri, 26 May 2017 10:16:54 +0000
Message-ID: 
References:   <2F0DAA1D-33EF-4742-A8A1-438921735CD0@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CBC5FC9@ESESSMB109.ericsson.se> <7ECBF64F-0C31-4924-8627-02E5C31EDC26@nostrum.com>
In-Reply-To: <7ECBF64F-0C31-4924-8627-02E5C31EDC26@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.16]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7ru40Bo1Ig77XphbzO0+zW8w8u4vF 4uuPTWwOzB5Llvxk8pi18wlLAFMUl01Kak5mWWqRvl0CV8byg79ZC47oVzQeW8zUwLhCr4uR g0NCwESiudmri5GLQ0jgCKPEyY7FzBDOYkaJCdMeM4MUsQlYSHT/0+5i5OQQEVCSeN68lQWk hlmgg1Hi6ZI+VpCEsICdxPtP+5lA6kUE7CX2TxGHqPeTONQ+iQ0kzCKgKjFtZSxImFfAWuLv ilmMEKvmMUmcb+lnAanhBGrdMiUKpIZRQEzi+6k1TCA2s4C4xK0n88FsCQEBiSV7zjND2KIS Lx//YwVpFRXQk3i33xMirCix82w72PHMApoS63fpQ0yxllj7tJcdwlaUmNL9kB3iGkGJkzOf sExgFJ+FZNkshO5ZSLpnIemehaR7ASPrKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAeDu4 5bfuDsbVrx0PMQpwMCrx8CZ/U48UYk0sK67MPcQowcGsJMK75iVQiDclsbIqtSg/vqg0J7X4 EKM0B4uSOK/DvgsRQgLpiSWp2ampBalFMFkmDk6pBsYpcfNXBfzaVbt6Xstn3aB5vf1bHFp1 rk3TXtUR3WTHfHa6qGFQvX6+svv2yfGn1ywScuif7vAtz2Ajs/mdc88fhjSJXfxZH2BpsGXh RMdu3fzQS3aZ5Wk/xWftEw1K/aw/2/fnWeNvmhNdd8S+YhQ95GbNsHDBgjmXjBvmS3u1VPH/ agrublBiKc5INNRiLipOBABjR8pSswIAAA==
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 10:16:59 -0000

SGksDQoNCuKApg0KDQo+Pj4+Pi0gSXMgdGhlcmUgYW4gZXhwZWN0YXRpb24gZm9yIHRoZSBTSVAg
Q29udGVudC1JRCBoZWFkZXIgZmllbGQgdmFsdWUNCj4+Pj4+IHRvIGJlIHJlZmVyZW5jZWQgZnJv
bSBvdXRzaWRlIHRoZSBTSVAgbWVzc2FnZT8gSWYgc28sIHdoYXQgYXJlIHRoZQ0KPj4+Pj4gdW5p
cXVlbmVzcyBleHBlY3RhdGlvbnM/IE5vdGUgdGhhdCBmb3IgTUlNRSwgQ29udGVudC1JRCBpcyBl
eHBlY3RlZA0KPj4+Pj50byANCj4+Pj4+IGJlIGdsb2JhbGx5IHVuaXF1ZS4gSXMgdGhhdCB0aGUg
Y2FzZSBoZXJlPw0KPj4+PiANCj4+Pj4gKENocmlzdGVyKSBUaGUgZHJhZnQgZG9lcyBub3QgY2hh
bmdlIHRoZSB1bmlxdWVuZXNzIHJlcXVpcmVtZW50cyBvZg0KPj4+PiBDb250ZW50LUlELg0KPj4+
PiANCj4+Pj4+IElmIHRoZSBDb250ZW50LUlEIGlzIF9ub3RfIGV4cGVjdGVkIHRvIGJlIHJlZmVy
ZW5jZWQgZnJvbSBvdXRzaWRlIG9mDQo+Pj4+PiB0aGUgU0lQIG1lc3NhZ2UgdGhhdCBjb250YWlu
cyBpdCwgdGhlbiB3ZSBoYXZlIGEgc29ydCBvZiBkZWdlbmVyYXRlDQo+Pj4+PiBjYXNlIHdoZXJl
IGl0IGFsd2F5cyBpZGVudGlmaWVzIF90aGlzXyBtZXNzYWdlIHJlZ2FyZGxlc3Mgb2YgdGhlDQo+
Pj4+PiB2YWx1ZS4gRG9lcyB0aGF0IHZhbHVlIGV2ZXIgbmVlZCB0byBjaGFuZ2U/IERvZXMgdGhh
dCBzdWdnZXN0ID5hbnkNCj4+Pj4+IGd1aWRhbmNlIG9uIGhvdyB0byBjb25zdHJ1Y3QgdmFsdWVz
Pw0KPj4+PiANCj4+Pj4gKENocmlzdGVyKSBSRkMgNTYyMSBkb2VzIG5vdCBkZWZpbmUgdGhlIGFi
b3ZlIGNoYXJhY3RlcmlzdGljcyBmb3INCj4+Pj4gbXVsdGlwYXJ0IGJvZHkgdXNhZ2UsIGFuZCBJ
IHNlZSBubyByZWFzb24gaG93IGFueXRoaW5nIHdvdWxkIGJlDQo+Pj4+IGRpZmZlcmVudCBmb3Ig
YSBub24tbXVsdGlwYXJ0IG1lc3NhZ2UgYm9keS4gSWYgeW91IHRoaW5rIHRoZXJlIGlzDQo+Pj4+
IHNvbWV0aGluZyBnZW5lcmljIGFib3V0IENvbnRlbnQtSUQgdGhhdCBuZWVkcyB0byBiZSBjbGFy
aWZpZWQgSSB0aGluaw0KPj4+PiB0aGF0IHNob3VsZCBiZSBkb25lIGFzIGEgc2VwYXJhdGUgdGFz
ay4NCj4+PiANCj4+PiA1MjYxIHVzZWQgdGhlIENvbnRlbnQtSWQgTUlNRSBoZWFkZXIgZmllbGQu
IFRoYXQgZmllbGQgYW5kIGl0wrlzDQo+Pj4gdW5pcXVlbmVzcyByZXF1aXJlbWVudHMgYXJlIGRl
ZmluZWQgZWxzZXdoZXJlLiBUaGlzIGRyYWZ0IGRlZmluZXMgYQ0KPj4+IENvbnRlbnQtSUQgc2lw
IGhlYWRlciBmaWVsZC4gVGhhdCBkaWRuwrl0IGV4aXN0IGJlZm9yZS4gVGhlcmVmb3JlIEkNCj4+
PiB0aGluayB0aGlzIG5lZWRzIHRvIGRlc2NyaWJlIHRoZSB1bmlxdWVuZXNzIHJlcXVpcmVtZW50
cy4NCj4+PiANCj4+PiA1MzIyIHJlcXVpcmVzIG1zZy1pZCB0byBiZSBnbG9iYWxseSB1bmlxdWUg
YmVjYXVzZSBpdMK5cyBpbnRlbmRlZCB0byBiZQ0KPj4+IHVzZWZ1bCBvdXRzaWRlIHRoZSBjb250
ZXh0IG9mIHRoZSBnaXZlbiBtZXNzYWdlLiBJcyB0aGF0IHRoZSBjYXNlIGhlcmU/DQo+Pj4gSWYg
bm90LCB0aGVuIGEgZ2xvYmFsbHkgdW5pcXVlbmVzcyByZXF1aXJlbWVudCBtYXkgbm90IG1ha2Ug
c2Vuc2UgaW4NCj4+PiB0aGlzIGNvbnRleHQuIChJSVVDLCBldmVyeSBzaW5nbGUgaW5zdGFuY2Ug
b2YgdGhlIENvbnRlbnQtSWQgU0lQDQo+Pj5oZWFkZXIgDQo+Pj4gZmllbGQgY291bGQgaGF2ZSB0
aGUgc2FtZSwgaWRlbnRpY2FsIHZhbHVlLCBhbmQgdGhpbmdzIHdvdWxkIHdvcmsNCj4+PiBmaW5l
LikNCj4+IA0KPj4gKENocmlzdGVyKSBJIGhhdmUgbmV2ZXIgaGVhcmQgYWJvdXQgQ29udGVudC1J
RCBiZWluZyB1c2VkIG91dHNpZGUgdGhlDQo+PmNvbnRleHQgb2YgYSBnaXZlbiBtZXNzYWdlLCBz
byBJIHRoaW5rIHRoZSB2YWx1ZSBvbmx5IG5lZWRzIHRvIGJlIHVuaXF1ZQ0KPj53aXRoaW4gYSBn
aXZlbiBtZXNzYWdlDQo+DQo+QXJlIHlvdSBleHBlY3RpbmcgdG8gZXZlciBoYXZlIGJvdGggdGhl
IFNJUCBoZWFkZXIgZmllbGQgYW5kIG9uZSBvciBtb3JlDQo+TUlNRSBDb250ZW50LUlEIGhlYWRl
ciBmaWVsZHMgaW4gdGhlIHNhbWUgbWVzc2FnZT8NCg0KSSBkb27igJl0IGhhdmUgYSB1c2UtY2Fz
ZSBhdCB0aGUgbW9tZW50LCBidXQgSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZA0KZGlzYWxsb3cg
aXQuDQoNCg0KPklmIHNvLCB0aGVuIHRleHQgdG8gdGhlIGVmZmVjdCBvZiB0aGUgZm9sbG93aW5n
IHNlZW1zIHRvIG1ha2Ugc2Vuc2U6DQo+DQo+4oCcVGhlIHZhbHVlIG9mIENvbnRlbnQtSWQgaGVh
ZGVyIGZpZWxkIHZhbHVlIG11c3QgYmUgdW5pcXVlIGluIHRoZSBjb250ZXh0DQo+b2YgYSBnaXZl
biBTSVAgbWVzc2FnZSwgaW5jbHVkaW5nIGFueSBpbWJlZGRlZCBNSU1FIENvbnRlbnQtSWQgaGVh
ZGVyDQo+ZmllbGQgdmFsdWVzLiBOb3RlIHRoYXQgdGhlIFNJUCBDb250ZW50LUlEIGhlYWRlciBm
aWVsZCB2YWx1ZSBpcyBub3QNCj5leHBlY3RlZCB0byBiZSB1bmlxdWUgYW1vbmcgYWxsIFNJUCBt
ZXNzYWdlczsgaXQgaGFzIG5vIG1lYW5pbmcgb3V0c2lkZQ0KPm9mIHRoZSBtZXNzYWdlIGluIHdo
aWNoIGl0IGlzIGluY2x1ZGVkLuKAnQ0KDQpMb29rcyBnb29kLg0KDQpzL2ltYmVkZGVkL2VtYmVk
ZGVkDQoNCj4NCj5JZiwgT1RPSCwgeW91IHRoaW5rIHRoZXJlIG1pZ2h0IGV2ZXIgYmUgYSBuZWVk
IHRvIHJlZmVyZW5jZSBhIGJvZHkgZnJvbSBhDQo+ZGlmZmVyZW50IFNJUCBtZXNzYWdlLCB0aGVu
IHdlIHdvdWxkIG5lZWQgaXQgdG8gYmUgZ2xvYmFsbHkgdW5pcXVlLg0KDQpJRiBzb21lb25lIGV2
ZXIgY29tZXMgdXAgd2l0aCBzdWNoIHVzZS1jYXNlLCB3ZSBjYW4gZGVhbCB3aXRoIGl0Lg0KDQoN
Cj4+IA0KPj4gDQo+PiBTcGVjaWZpYyBjb21tZW50czoNCj4+IA0KPj4+Pj4gMS40IGFuZCBjaGls
ZHJlbjogVGhlc2UgZXhhbXBsZXMgc2VlbSBsaWtlIGZhaXJseSB3ZWFrIG1vdGl2YXRpb24sDQo+
Pj4+PiBzaW5jZSBJIGFzc3VtZSBpbiBib3RoIGNhc2VzIG9uZSBjb3VsZCBzdGlsbCBoYXZlIGp1
c3QgcHV0IGEgc2luZ2xlDQo+Pj4+PiBib2R5LXBhcnQgaW5zaWRlIGEgbXVsdGlwYXJ0IGVudmVs
b3BlLiBUaGF0DQo+Pj4+PiBzZWVtcyBtb3JlIGFuICJpbmNvbnZlbmllbmNlIiB0aGFuIGEgInBy
b2JsZW0iLiBBcmUgdGhlcmUgYW55IGtub3duDQo+Pj4+PiB1c2UtY2FzZXMgd2hlcmUgdGhhdCB3
b3VsZCBub3QgYmUgcG9zc2libGU/IChUaGlzIGlzIGNlcnRhaW5seSBub3QgYQ0KPj4+Pj4gc2hv
dyBzdG9wcGVyOyB3ZSBhcmUgYWxsb3dlZCB0byBzb2x2ZQ0KPj4+Pj4gaW5jb252ZW5pZW5jZXMu
IEJ1dCBpZiB0aGVyZSBhcmUgYW55IHN0cm9uZ2VyIG1vdGl2YXRpb25zIHRoYXQgY291bGQNCj4+
Pj4+IGJlIGRvY3VtZW50ZWQsIHRoZXkgbWlnaHQgc2F2ZSBxdWVzdGlvbnMgZG93biB0aGUgcm9h
ZC4pDQo+Pj4+IA0KPj4+PiAoQ2hyaXN0ZXIpIEkgY2FuJ3QgdGhpbmsgb2YgYW55IHVzZS1jYXNl
cyB3aGVyZSBpdCB3b3VsZCBub3QgYmUNCj4+Pj4gcG9zc2libGUgdG8gdXNlIGEgc2luZ2xlLWJv
ZHkgaW5zaWRlIGEgbXVsdGlwYXJ0IGVudmVsb3BlIGluc3RlYWQuDQo+Pj4+U28sIA0KPj4+PiBp
dCBpcyBhYm91dCAiY29udmVuaWVuY2UiLg0KPj4+IA0KPj4+IFRoZSB3b3JkICJvcHRpbWl6YXRp
b24iIGNvbWVzIHRvIG1pbmQuDQo+PiANCj4+IChDaHJpc3RlcikgSSBndWVzcyB0aGF0IHdvcmtz
IHRvbyA6KQ0KPg0KPk9rYXksIG5vIGNoYW5nZSBuZWVkZWQuDQo+DQo+PiANCj4+Pj4+IDMuMiwg
Mm5kIG5vdGU6IEhvdyBoYXMgdGhlIG1zZy1JZCBiZWVuIHNpbXBsaWZpZWQsIGFuZCB3aHk/DQo+
Pj4+IA0KPj4+PiAoQ2hyaXN0ZXIpIFRoZSBzaW1wbGlmaWNhdGlvbiB3YXMgZG9uZSBiYXNlZCBv
biBhIGNvbW1lbnQgZnJvbSBEYWxlIFcuDQo+Pj4+IA0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwNzg2Mi5odG1sDQo+Pj4gDQo+
Pj4gSSB0aGluayBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHNheSBzb21ldGhpbmcgbGlrZSDCs8Wg
IHNpbXBsaWZpZWQgdG8NCj4+PiBkaXNhbGxvdyB0aGUgdXNlIG9mIGNvbW1lbnRzIGFuZCB0byBh
ZGFwdCB0byBTSVDCuXMgdXNlIG9mIGxlYWRpbmcNCj4+PndoaXRlIA0KPj4+IHNwYWNlLiINCj4+
IA0KPj4gKENocmlzdGVyKSBPaywgd2XCuWxsIGFkZCBzb21lIHRleHQuDQo+DQo+VGhhbmtzLiBJ
ZiB5b3UgY2FuIHN1Ym1pdCBhIHZlcnNpb24gd2l0aCB0aGF0IGNoYW5nZSwgYXMgd2VsbCBhcyBz
b21lDQo+Z3VpZGFuY2Ugb24gdW5pcXVlbmVzcyBhcyBkaXNjdXNzZWQgYWJvdmUsIEkgdGhpbmsg
aXQgd2lsbCBiZSByZWFkeSBmb3INCj5JRVRGIExDLg0KDQpJIHNob3VsZCBoYXZlIHNvbWV0aGlu
ZyByZWFkeSBubyBsYXRlciB0aGFuIE1vbmRheS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K


From nobody Fri May 26 04:59:06 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4720F126E01; Fri, 26 May 2017 04:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 9EHTIpXr6k-Z; Fri, 26 May 2017 04:59:04 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C1C128B51; Fri, 26 May 2017 04:59:03 -0700 (PDT)
X-AuditID: c1b4fb3a-6e3519a000004a6a-fb-592818853ac7
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.54.19050.58818295; Fri, 26 May 2017 13:59:01 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0339.000; Fri, 26 May 2017 13:59:00 +0200
From: Christer Holmberg 
To: Ben Campbell 
CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
Thread-Index: AQHS1hd1b6bmbyrEbUuHjC4DfZ2Vqg==
Date: Fri, 26 May 2017 11:58:59 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <26A699CC292AF84ABFD621142892F84E@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdXbdVQiPSYPEZTYv5nafZLWae3cVi 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+PR/ZqCWywV03ZMZ2xgfMTcxcjJ ISFgIvH+yjFGEFtI4AijxPTN+V2MXED2YkaJjZO/sXcxcnCwCVhIdP/TBqkREVCSeN68lQWk hlmgg1Hi6ZI+VpCEsICvRNfbG+wQRQESP/duZYKw9SSaT1wHW8AioCrxov00mM0rYC3x4/08 MJtRQEzi+6k1YPXMAuISt57MZ4I4TkBiyZ7zUIeKSrx8/I8V5B5RoJnv9ntChBUlPr7axwjR qidxY+oUNgjbWmLFhJdQcW2JZQtfM0OsFZQ4OfMJywRG0VlIts1C0j4LSfssJO2zkLQvYGRd xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYRQe3/LbawXjwueMhRgEORiUe3hwBjUgh1sSy 4srcQ4wSHMxKIrw24kAh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbB ZJk4OKUaGPkSiqymeF8Nu65nca1Jfu6Bidpvw19aRmdsTZl3e37GoecssSmi4lfPeBhEfWs8 rvusJLVHcuJFoT0cx9p+ie/3enP+94fSz9O2yt+VNGD+x37fPnHB4Rl33+o/CpY/0Hpbmjud 7dd9sZnb8o7PsV6jcJ7pXEGN2mcp288HNBoOL/iz5uW/9EAlluKMREMt5qLiRABkYYwnngIA AA==
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 11:59:05 -0000

Hi Ben,

I have created a pull request, based on your comments:

https://github.com/cdh4u/draft-content-id/pull/6


However, I wasn=B9t sure how to address the following comment:

"1.2 and 1.3: A sentence or two that more strongly contrasts "body part"
vs "message-body" would be helpful. I think that some people will think of
a message-body as still a body-part.=B2

I think section 1.1 describes the difference between a message-body and a
body-part. I don=B9t think we should copy/paste that in sections 1.2 and
1.3. Or, did I misunderstand you comment?

Regards,

Christer



From nobody Fri May 26 09:28:06 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F57129AE3; Fri, 26 May 2017 09:28:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 nDm4OEeyrRdM; Fri, 26 May 2017 09:28:03 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 ACA6D129AE7; Fri, 26 May 2017 09:28:03 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4QGRxiC065201 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 May 2017 11:27:59 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: 
Date: Fri, 26 May 2017 11:27:59 -0500
Cc: "draft-ietf-sipcore-content-id.all@ietf.org" ,  "sipcore@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com>
References: 
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 16:28:05 -0000

> On May 26, 2017, at 6:58 AM, Christer Holmberg =
 wrote:
>=20
> Hi Ben,
>=20
> I have created a pull request, based on your comments:
>=20
> https://github.com/cdh4u/draft-content-id/pull/6
>=20
>=20

The diff looks fine. We probably want to make sure the WG shares the =
opinion that the Content-ID will never be referenced from outside the =
SIP message.

Jean, do  you have thoughts on that from the shepherd perspective?


> However, I wasn=C4=85t sure how to address the following comment:
>=20
> "1.2 and 1.3: A sentence or two that more strongly contrasts "body =
part"
> vs "message-body" would be helpful. I think that some people will =
think of
> a message-body as still a body-part.=CB=9B
>=20
> I think section 1.1 describes the difference between a message-body =
and a
> body-part. I don=C4=85t think we should copy/paste that in sections =
1.2 and
> 1.3. Or, did I misunderstand you comment?

On reflection, I think this might be fine like it is. I know that some =
people casually refer to the entire body as still a =E2=80=9Cpart=E2=80=9D=
, but that doesn=E2=80=99t seem to be reflected in the MIME RFCs. =
Let=E2=80=99s see if anyone comments in LC.

>=20
> Regards,
>=20
> Christer
>=20
>=20


From nobody Fri May 26 10:53:46 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9044A129B13; Fri, 26 May 2017 10:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 3QMR_TjEr4sL; Fri, 26 May 2017 10:53:43 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9DA0129B1A; Fri, 26 May 2017 10:53:42 -0700 (PDT)
X-AuditID: c1b4fb3a-307ff70000004a6a-4a-59286ba46c62
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DC.9A.19050.4AB68295; Fri, 26 May 2017 19:53:41 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Fri, 26 May 2017 19:53:39 +0200
From: Christer Holmberg 
To: Ben Campbell 
CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
Thread-Index: AQHS1hd1b6bmbyrEbUuHjC4DfZ2VqqIGrF2AgAA3o1A=
Date: Fri, 26 May 2017 17:53:39 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBCBE9D@ESESSMB109.ericsson.se>
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com>
In-Reply-To: <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7pe7SbI1Ig94OQYv5nafZLWae3cVi 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK2PC24UsBTs4K+601DYwzuDsYuTk kBAwkeif9Zq5i5GLQ0jgCKPE7Lfb2CGcxYwSO1ftZOti5OBgE7CQ6P6nDdIgIqAk8bx5KwtI DbNAB6PE0yV9rCA1wgK+Ev/PiULUBEj83LuVCcK2kmi/+YoJpIRFQFXi5EQfkDAvSPXXqYwg tpBAgcTWS9/BbE4Be4llq+axg9iMAmIS30+tARvDLCAucevJfCaImwUkluw5zwxhi0q8fPyP FcJWklix/RIjyCpmAU2J9bv0IVoVJaZ0P2SHWCsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZ VjGKFqcWF+emGxnppRZlJhcX5+fp5aWWbGIERsrBLb+tdjAefO54iFGAg1GJh/dzikakEGti WXFl7iFGCQ5mJRFebRWgEG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATSE0tSs1NTC1KL YLJMHJxSDYwrduV+Off3nOfSzqzL/HOmqsrcqi+NP6cV27H05/RLxyJ8RAvD3ae7Ndq53Jfs MZrzuvtFVSLD871f2vTTdxX8DVYWspxrcz/mc13P2tkNDkp/XV93ruyRttihXNfIfXfVEtUN +80u9F2VVihexS39WHHTWob29CS7XovPbzkSMmZL+8bWTlFiKc5INNRiLipOBACkki6nkAIA AA==
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 17:53:45 -0000

SGksDQoNCi4uLg0KDQo+PiBIb3dldmVyLCBJIHdhc24ndCBzdXJlIGhvdyB0byBhZGRyZXNzIHRo
ZSBmb2xsb3dpbmcgY29tbWVudDoNCj4+IA0KPj4gIjEuMiBhbmQgMS4zOiBBIHNlbnRlbmNlIG9y
IHR3byB0aGF0IG1vcmUgc3Ryb25nbHkgY29udHJhc3RzICJib2R5IHBhcnQiDQo+PiB2cyAibWVz
c2FnZS1ib2R5IiB3b3VsZCBiZSBoZWxwZnVsLiBJIHRoaW5rIHRoYXQgc29tZSBwZW9wbGUgd2ls
bCANCj4+IHRoaW5rIG9mIGEgbWVzc2FnZS1ib2R5IGFzIHN0aWxsIGEgYm9keS1wYXJ0LsubDQo+
PiANCj4+IEkgdGhpbmsgc2VjdGlvbiAxLjEgZGVzY3JpYmVzIHRoZSBkaWZmZXJlbmNlIGJldHdl
ZW4gYSBtZXNzYWdlLWJvZHkgDQo+PiBhbmQgYSBib2R5LXBhcnQuIEkgZG9uxIV0IHRoaW5rIHdl
IHNob3VsZCBjb3B5L3Bhc3RlIHRoYXQgaW4gc2VjdGlvbnMgDQo+PiAxLjIgYW5kIDEuMy4gT3Is
IGRpZCBJIG1pc3VuZGVyc3RhbmQgeW91IGNvbW1lbnQ/DQo+DQo+IE9uIHJlZmxlY3Rpb24sIEkg
dGhpbmsgdGhpcyBtaWdodCBiZSBmaW5lIGxpa2UgaXQgaXMuIEkga25vdyB0aGF0IHNvbWUgcGVv
cGxlIGNhc3VhbGx5IHJlZmVyIHRvIHRoZSBlbnRpcmUgYm9keSBhcyBzdGlsbCBhIOKAnHBhcnTi
gJ0sIGJ1dCANCj4gdGhhdCBkb2VzbuKAmXQgc2VlbSB0byBiZSByZWZsZWN0ZWQgaW4gdGhlIE1J
TUUgUkZDcy4gTGV04oCZcyBzZWUgaWYgYW55b25lIGNvbW1lbnRzIGluIExDLg0KDQpPay4NCg0K
SSdsbCB3YWl0IGZvciBKZWFuJ3MgY29tbWVudCByZWdhcmRpbmcgdXNhZ2Utb2YtQ29udGVudC1J
RC1vdXRzaWRlLXRoZS1TSVAtbWVzc2FnZSBiZWZvcmUgc3VibWl0dGluZyBhIG5ldyB2ZXJzaW9u
Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K


From nobody Fri May 26 12:28:39 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADBA129418; Fri, 26 May 2017 12:28:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level: 
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 brP_3LptwE48; Fri, 26 May 2017 12:28:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D02D4126BFD; Fri, 26 May 2017 12:28:36 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4QJSVJ2099939 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 May 2017 14:28:32 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: Ben Campbell , Christer Holmberg 
Cc: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com>
From: "A. Jean Mahoney" 
Message-ID: <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com>
Date: Fri, 26 May 2017 14:28:31 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 May 2017 19:28:38 -0000

Hi Ben,

On 5/26/17 11:27 AM, Ben Campbell wrote:
> 
>> On May 26, 2017, at 6:58 AM, Christer Holmberg
>>  wrote:
>> 
>> Hi Ben,
>> 
>> I have created a pull request, based on your comments:
>> 
>> https://github.com/cdh4u/draft-content-id/pull/6
>> 
>> 
> 
> The diff looks fine. We probably want to make sure the WG shares the
> opinion that the Content-ID will never be referenced from outside the
> SIP message.
> 
> Jean, do  you have thoughts on that from the shepherd perspective?
> 

The WG did discuss whether the Content-ID could be used outside of the 
message. The takeaway was, that since a SIP header has non-MIME fields, 
the Content-ID can't really refer to the entire message, and thus would 
not be useful outside the message.

Anyone have any input on the changes to the draft?

Jean

PS - nit: Campbell is misspelled in the "Change Log".


> 
>> However, I wasnąt sure how to address the following comment:
>> 
>> "1.2 and 1.3: A sentence or two that more strongly contrasts "body
>> part" vs "message-body" would be helpful. I think that some people
>> will think of a message-body as still a body-part.˛
>> 
>> I think section 1.1 describes the difference between a message-body
>> and a body-part. I donąt think we should copy/paste that in
>> sections 1.2 and 1.3. Or, did I misunderstand you comment?
> 
> On reflection, I think this might be fine like it is. I know that
> some people casually refer to the entire body as still a “part”, but
> that doesn’t seem to be reflected in the MIME RFCs. Let’s see if
> anyone comments in LC.
> 
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
> 


From nobody Fri May 26 18:36:43 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E125129BD8; Fri, 26 May 2017 18:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 Ie7AZgiyhGfB; Fri, 26 May 2017 18:36:41 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0ACC8129BB5; Fri, 26 May 2017 18:36:41 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4R1aaeQ072380 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 26 May 2017 20:36:37 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com>
Date: Fri, 26 May 2017 20:36:36 -0500
Cc: Christer Holmberg , "draft-ietf-sipcore-content-id.all@ietf.org" ,  "sipcore@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com>
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com> <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com>
To: "A. Jean Mahoney" 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 27 May 2017 01:36:42 -0000

> On May 26, 2017, at 2:28 PM, A. Jean Mahoney  =
wrote:
>=20
> Hi Ben,
>=20
> On 5/26/17 11:27 AM, Ben Campbell wrote:
>>> On May 26, 2017, at 6:58 AM, Christer Holmberg
>>>  wrote:
>>> Hi Ben,
>>> I have created a pull request, based on your comments:
>>> https://github.com/cdh4u/draft-content-id/pull/6
>> The diff looks fine. We probably want to make sure the WG shares the
>> opinion that the Content-ID will never be referenced from outside the
>> SIP message.
>> Jean, do  you have thoughts on that from the shepherd perspective?
>=20
> The WG did discuss whether the Content-ID could be used outside of the =
message. The takeaway was, that since a SIP header has non-MIME fields, =
the Content-ID can't really refer to the entire message, and thus would =
not be useful outside the message.
>=20

There seems to be two ideas intertwined there; namely the idea of what a =
content-ID identifies, and the idea of whether a content-ID could be =
referred to from outside the containing SIP message. But I take your =
comment to mean that both were discussed. Is that correct?

Thanks!

Ben.

> Anyone have any input on the changes to the draft?
>=20
> Jean
>=20
> PS - nit: Campbell is misspelled in the "Change Log".
>=20
>=20
>>> However, I wasn=C4=85t sure how to address the following comment:
>>> "1.2 and 1.3: A sentence or two that more strongly contrasts "body
>>> part" vs "message-body" would be helpful. I think that some people
>>> will think of a message-body as still a body-part.=CB=9B
>>> I think section 1.1 describes the difference between a message-body
>>> and a body-part. I don=C4=85t think we should copy/paste that in
>>> sections 1.2 and 1.3. Or, did I misunderstand you comment?
>> On reflection, I think this might be fine like it is. I know that
>> some people casually refer to the entire body as still a =E2=80=9Cpart=E2=
=80=9D, but
>> that doesn=E2=80=99t seem to be reflected in the MIME RFCs. Let=E2=80=99=
s see if
>> anyone comments in LC.
>>> Regards,
>>> Christer


From nobody Sun May 28 11:40:46 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A15126CD8; Sun, 28 May 2017 11:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.321
X-Spam-Level: 
X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 PsX_Hy9XE_Ky; Sun, 28 May 2017 11:40:43 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05021129445; Sun, 28 May 2017 11:40:42 -0700 (PDT)
X-AuditID: c1b4fb3a-31fff70000004a6a-63-592b19a754d9
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 77.3E.19050.7A91B295; Sun, 28 May 2017 20:40:41 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Sun, 28 May 2017 20:40:39 +0200
From: Christer Holmberg 
To: Ben Campbell , "A. Jean Mahoney" 
CC: "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
Thread-Index: AQHS1hd1b6bmbyrEbUuHjC4DfZ2VqqIGrF2AgAAycYCAAGbXAIAC0LTA
Date: Sun, 28 May 2017 18:40:38 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBCDE09@ESESSMB109.ericsson.se>
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com> <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com> <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com>
In-Reply-To: <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdTHelpHakwYtNghbzO0+zW8w8u4vF oqFzJavF1x+b2BxYPJYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSujD9LjrMXfBGtWPSbp4Fx jWgXIweHhICJxN5JOl2MXBxCAkcYJXb9v8nSxcgJ5CxmlHhwFqyGTcBCovufNogpIuAtselK LUg5s0AHo8TTJX2sIHFhAV+J/+dEQTpFBAIkfu7dygRR7iax8Zk0SJhFQFXi2fxt7CA2L1B1 6/xfrBBbbzFK/Ps3HyzBKWAvMa91CxOIzSggJvH91Bowm1lAXOLWk/lgtoSAgMSSPeeZIWxR iZeP/7FC2EoSjUuegJ3DLKApsX6XPkSrosSU7odQewUlTs58wjKBUXQWkqmzEDpmIemYhaRj ASPLKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAeDm45bfVDsaDzx0PMQpwMCrx8N4R044U Yk0sK67MPcQowcGsJMJreEcrUog3JbGyKrUoP76oNCe1+BCjNAeLkjivw74LEUIC6Yklqdmp qQWpRTBZJg5OqQbG+YvvVqQ7me0q9F8dds9/rxDTMh5n++mrGmYmq8l8fX2cMVhm549PJb+K bkkUaJlfKr2y1LduztQl+0K/m6dlbTjwd4dR7P/ENtGQuwtKL60QvCPYe3dTTlTn7SXHXt4K TzyWcCp/jbzhpPWf3b8XGF5Y/lekrerWTFsD4+j9UZtcL7V+3ClapsRSnJFoqMVcVJwIAIkZ HMCTAgAA
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 28 May 2017 18:40:45 -0000

SGksDQoNCj4+Pj4gSSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3QsIGJhc2VkIG9uIHlvdXIg
Y29tbWVudHM6DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1jb250ZW50LWlk
L3B1bGwvNg0KPj4+IFRoZSBkaWZmIGxvb2tzIGZpbmUuIFdlIHByb2JhYmx5IHdhbnQgdG8gbWFr
ZSBzdXJlIHRoZSBXRyBzaGFyZXMgdGhlIA0KPj4+IG9waW5pb24gdGhhdCB0aGUgQ29udGVudC1J
RCB3aWxsIG5ldmVyIGJlIHJlZmVyZW5jZWQgZnJvbSBvdXRzaWRlIHRoZSANCj4+PiBTSVAgbWVz
c2FnZS4NCj4+PiBKZWFuLCBkbyAgeW91IGhhdmUgdGhvdWdodHMgb24gdGhhdCBmcm9tIHRoZSBz
aGVwaGVyZCBwZXJzcGVjdGl2ZT8NCj4+IA0KPj4gVGhlIFdHIGRpZCBkaXNjdXNzIHdoZXRoZXIg
dGhlIENvbnRlbnQtSUQgY291bGQgYmUgdXNlZCBvdXRzaWRlIG9mIHRoZSBtZXNzYWdlLiANCj4+
IFRoZSB0YWtlYXdheSB3YXMsIHRoYXQgc2luY2UgYSBTSVAgaGVhZGVyIGhhcyBub24tTUlNRSBm
aWVsZHMsIHRoZSBDb250ZW50LUlEIGNhbid0IA0KPj4gcmVhbGx5IHJlZmVyIHRvIHRoZSBlbnRp
cmUgbWVzc2FnZSwgYW5kIHRodXMgd291bGQgbm90IGJlIHVzZWZ1bCBvdXRzaWRlIHRoZSBtZXNz
YWdlLg0KPiANCj4gVGhlcmUgc2VlbXMgdG8gYmUgdHdvIGlkZWFzIGludGVydHdpbmVkIHRoZXJl
OyBuYW1lbHkgdGhlIGlkZWEgb2Ygd2hhdCBhIGNvbnRlbnQtSUQgaWRlbnRpZmllcywgDQo+IGFu
ZCB0aGUgaWRlYSBvZiB3aGV0aGVyIGEgY29udGVudC1JRCBjb3VsZCBiZSByZWZlcnJlZCB0byBm
cm9tIG91dHNpZGUgdGhlIGNvbnRhaW5pbmcgU0lQIG1lc3NhZ2UuIA0KPiBCdXQgSSB0YWtlIHlv
dXIgY29tbWVudCB0byBtZWFuIHRoYXQgYm90aCB3ZXJlIGRpc2N1c3NlZC4gSXMgdGhhdCBjb3Jy
ZWN0Pw0KDQpBcyBmYXIgYXMgSSByZW1lbWJlciwgd2UgZGlkIG5vdCBkaXNjdXNzIHRoZSBwb3Nz
aWJpbGl0eSBvZiByZWZlcmVuY2luZyBhIGJvZHkgb3V0c2lkZSB0aGUgU0lQIG1lc3NhZ2UuDQoN
Ckhvd2V2ZXIsIG5vYm9keSBoYXMgcmVxdWVzdGVkIGZvciB0aGF0IHBvc3NpYmlsaXR5LCBzbyBJ
IGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gY292ZXIgaXQuIElmIHNvbWVvbmUsIGFzIHNvbWUgcG9p
bnQsIHNlZSBhIG5lZWQgZm9yIGl0LCBoZS9zaGUgY2FuIHVwZGF0ZSB0aGUgc3BlYyBhbmQgZGVm
aW5lIGhvdyBpdCBpcyBkb25lLCB3aGF0IGltcGFjdHMgaXQgaGFzIG9uIHRoZSB1bmlxdWVuZXNz
IGV0Yy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCj4+PiBIb3dldmVyLCBJIHdhc27E
hXQgc3VyZSBob3cgdG8gYWRkcmVzcyB0aGUgZm9sbG93aW5nIGNvbW1lbnQ6DQo+Pj4gIjEuMiBh
bmQgMS4zOiBBIHNlbnRlbmNlIG9yIHR3byB0aGF0IG1vcmUgc3Ryb25nbHkgY29udHJhc3RzICJi
b2R5IA0KPj4+IHBhcnQiIHZzICJtZXNzYWdlLWJvZHkiIHdvdWxkIGJlIGhlbHBmdWwuIEkgdGhp
bmsgdGhhdCBzb21lIHBlb3BsZSANCj4+PiB3aWxsIHRoaW5rIG9mIGEgbWVzc2FnZS1ib2R5IGFz
IHN0aWxsIGEgYm9keS1wYXJ0LsubIEkgdGhpbmsgc2VjdGlvbiANCj4+PiAxLjEgZGVzY3JpYmVz
IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gYSBtZXNzYWdlLWJvZHkgYW5kIGEgYm9keS1wYXJ0LiAN
Cj4+PiBJIGRvbsSFdCB0aGluayB3ZSBzaG91bGQgY29weS9wYXN0ZSB0aGF0IGluIHNlY3Rpb25z
IDEuMiBhbmQgMS4zLiBPciwgDQo+Pj4gZGlkIEkgbWlzdW5kZXJzdGFuZCB5b3UgY29tbWVudD8N
Cj4+IE9uIHJlZmxlY3Rpb24sIEkgdGhpbmsgdGhpcyBtaWdodCBiZSBmaW5lIGxpa2UgaXQgaXMu
IEkga25vdyB0aGF0IA0KPj4gc29tZSBwZW9wbGUgY2FzdWFsbHkgcmVmZXIgdG8gdGhlIGVudGly
ZSBib2R5IGFzIHN0aWxsIGEg4oCccGFydOKAnSwgYnV0IA0KPj4gdGhhdCBkb2VzbuKAmXQgc2Vl
bSB0byBiZSByZWZsZWN0ZWQgaW4gdGhlIE1JTUUgUkZDcy4gTGV04oCZcyBzZWUgaWYgDQo+PiBh
bnlvbmUgY29tbWVudHMgaW4gTEMuDQo+Pj4gUmVnYXJkcywNCj4+PiBDaHJpc3Rlcg0KDQo=


From nobody Mon May 29 05:21:19 2017
Return-Path: 
X-Original-To: sipcore@ietf.org
Delivered-To: sipcore@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A856712954C; Mon, 29 May 2017 05:21:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bert Wijnen 
To: 
Cc: draft-ietf-sipcore-name-addr-guidance.all@ietf.org, sipcore@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149606047056.22794.2528878714319182056@ietfa.amsl.com>
Date: Mon, 29 May 2017 05:21:10 -0700
Archived-At: 
Subject: [sipcore] Opsdir last call review of draft-ietf-sipcore-name-addr-guidance-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 29 May 2017 12:21:11 -0000

Reviewer: Bert Wijnen
Review result: Ready

This document makes a clarification to a set of RFCs. I think the
clarifications are clear and understandable.

Bert Wijnen


From nobody Tue May 30 08:22:09 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397BF128BB6 for ; Tue, 30 May 2017 08:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.819
X-Spam-Level: 
X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 gP_hqK8v5cxo for ; Tue, 30 May 2017 08:22:07 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E8D7A127180 for ; Tue, 30 May 2017 08:22:06 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.26.91]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4UFM5sc073811 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 30 May 2017 10:22:05 -0500 (CDT) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [47.186.26.91] claimed to be mutabilis-2.local
To: SIPCORE 
From: "A. Jean Mahoney" 
Message-ID: <9cab6062-a55a-96da-80bc-268a2af81555@nostrum.com>
Date: Tue, 30 May 2017 10:22:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [sipcore] IETF 99 Prague - SIPCORE WG session
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 30 May 2017 15:22:08 -0000

Hi all,

Does anyone have anything they want to present? If so, let us know. The 
chairs need to get in a scheduling request by this Friday, UTC 23:59 
2017-06-02.

Thanks!

Jean


From nobody Wed May 31 10:27:28 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D859E129AA3 for ; Wed, 31 May 2017 09:46:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level: 
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 e1lnE0ZLSI31 for ; Wed, 31 May 2017 09:46:09 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D293129A96 for ; Wed, 31 May 2017 09:46:09 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id D7755B81931; Wed, 31 May 2017 09:45:48 -0700 (PDT)
To: jmpolk@cisco.com, br@brianrosen.net, jon.peterson@neustar.biz, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, br@brianrosen.net,  mahoney@nostrum.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Cc: lreeder@bandwidth.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20170531164548.D7755B81931@rfc-editor.org>
Date: Wed, 31 May 2017 09:45:48 -0700 (PDT)
Archived-At: 
X-Mailman-Approved-At: Wed, 31 May 2017 10:27:28 -0700
Subject: [sipcore] [Technical Errata Reported] RFC6442 (5027)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 16:46:11 -0000

The following errata report has been submitted for RFC6442,
"Location Conveyance for the Session Initiation Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5027

--------------------------------------
Type: Technical
Reported by: Larry Reeder 

Section: 5.1

Original Text
-------------
 --boundary1

   Content-Type: application/pidf+xml
   Content-ID: 
   
       

   
       
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E391129AD3; Wed, 31 May 2017 13:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level: 
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 HqjoAJZq0v-U; Wed, 31 May 2017 13:02:55 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E3F47129AD0; Wed, 31 May 2017 13:02:54 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4VK2oDW012435 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 May 2017 15:02:50 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell 
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBCDE09@ESESSMB109.ericsson.se>
Date: Wed, 31 May 2017 15:02:49 -0500
Cc: "A. Jean Mahoney" , "draft-ietf-sipcore-content-id.all@ietf.org" ,  "sipcore@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B59744D-7A19-46F8-9C17-D67DF1DA9E78@nostrum.com>
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com> <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com> <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CBCDE09@ESESSMB109.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 20:02:57 -0000

> On May 28, 2017, at 1:40 PM, Christer Holmberg =
 wrote:
>=20
> Hi,
>=20
>>>>> I have created a pull request, based on your comments:
>>>>> https://github.com/cdh4u/draft-content-id/pull/6
>>>> The diff looks fine. We probably want to make sure the WG shares =
the=20
>>>> opinion that the Content-ID will never be referenced from outside =
the=20
>>>> SIP message.
>>>> Jean, do  you have thoughts on that from the shepherd perspective?
>>>=20
>>> The WG did discuss whether the Content-ID could be used outside of =
the message.=20
>>> The takeaway was, that since a SIP header has non-MIME fields, the =
Content-ID can't=20
>>> really refer to the entire message, and thus would not be useful =
outside the message.
>>=20
>> There seems to be two ideas intertwined there; namely the idea of =
what a content-ID identifies,=20
>> and the idea of whether a content-ID could be referred to from =
outside the containing SIP message.=20
>> But I take your comment to mean that both were discussed. Is that =
correct?
>=20
> As far as I remember, we did not discuss the possibility of =
referencing a body outside the SIP message.
>=20
> However, nobody has requested for that possibility, so I don't think =
we need to cover it. If someone, as some point, see a need for it, =
he/she can update the spec and define how it is done, what impacts it =
has on the uniqueness etc.

It=E2=80=99s kind of hard to define extra-message references later if =
the initial version does not require global uniqueness. If people want =
to leave that option open, then global uniqueness may still make sense =
now. I=E2=80=99m okay with it either way as long as the WG has thought =
it through, and hasn=E2=80=99t just picked it arbitrarily.

>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
>>>> However, I wasn=C4=85t sure how to address the following comment:
>>>> "1.2 and 1.3: A sentence or two that more strongly contrasts "body=20=

>>>> part" vs "message-body" would be helpful. I think that some people=20=

>>>> will think of a message-body as still a body-part.=CB=9B I think =
section=20
>>>> 1.1 describes the difference between a message-body and a =
body-part.=20
>>>> I don=C4=85t think we should copy/paste that in sections 1.2 and =
1.3. Or,=20
>>>> did I misunderstand you comment?
>>> On reflection, I think this might be fine like it is. I know that=20
>>> some people casually refer to the entire body as still a =E2=80=9Cpart=
=E2=80=9D, but=20
>>> that doesn=E2=80=99t seem to be reflected in the MIME RFCs. Let=E2=80=99=
s see if=20
>>> anyone comments in LC.
>>>> Regards,
>>>> Christer
>=20


From nobody Wed May 31 13:21:36 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16B1129AD0 for ; Wed, 31 May 2017 13:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.765
X-Spam-Level: 
X-Spam-Status: No, score=0.765 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 HNZK1TPbGwW3 for ; Wed, 31 May 2017 13:21:33 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C880912922E for ; Wed, 31 May 2017 13:21:33 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id GA7Td23v5dlFQGA7YdVErU; Wed, 31 May 2017 20:21:32 +0000
Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-19v.sys.comcast.net with SMTP id GA7YdGPSqngy3GA7Yd43Yc; Wed, 31 May 2017 20:21:32 +0000
To: sipcore@ietf.org
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com> <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com> <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CBCDE09@ESESSMB109.ericsson.se> <7B59744D-7A19-46F8-9C17-D67DF1DA9E78@nostrum.com>
From: Paul Kyzivat 
Message-ID: <44a4ffd8-c35e-5a80-ff48-dd82d9f35f43@alum.mit.edu>
Date: Wed, 31 May 2017 16:21:31 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <7B59744D-7A19-46F8-9C17-D67DF1DA9E78@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfFqrpk70hXJpm3e7Angws7bVbs3tYLVI2tTdN/UB34G7OJcgZQQlcLAeFbXsEPLeycizCWY9b8RmI0FPVN/BGsfeGvptfYkB70mOvjP39UfqgGkBt70s XLq/YNSN+Q11dfWuWLN4I79aMKUqllfOKnAbXWQ2Mwgl8BB9dN01sYBI
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 20:21:35 -0000

On 5/31/17 4:02 PM, Ben Campbell wrote:

> It’s kind of hard to define extra-message references later if the initial version does not require global uniqueness. If people want to leave that option open, then global uniqueness may still make sense now. I’m okay with it either way as long as the WG has thought it through, and hasn’t just picked it arbitrarily.

I'm struggling to conceive of what extra-message references would 
*mean*. Under what circumstances would that make sense? I guess one 
might make some sort of case for reference to body parts from other 
messages in the same dialog. But doing that would require that the state 
to be referenced be retained - hence expanding the dialog state model.

It would also then raise a whole host of new issues regarding how those 
references might/might not work through B2BUAs.

Imagining some meaning beyond a dialog is even more fanciful. It would 
require an even more expansive expansion of state models.

I don't think we should go there.

	Thanks,
	Paul


From nobody Wed May 31 14:42:08 2017
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD2912EA24; Wed, 31 May 2017 14:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 t4CwgUb1VjWk; Wed, 31 May 2017 14:42:00 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0756112E3AE; Wed, 31 May 2017 14:41:59 -0700 (PDT)
X-AuditID: c1b4fb3a-307ff70000004a6a-c8-592f38a4536e
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.05.19050.4A83F295; Wed, 31 May 2017 23:41:58 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Wed, 31 May 2017 23:41:58 +0200
From: Christer Holmberg 
To: Ben Campbell 
CC: "A. Jean Mahoney" , "draft-ietf-sipcore-content-id.all@ietf.org" , "sipcore@ietf.org" 
Thread-Topic: AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
Thread-Index: AQHS1hd1b6bmbyrEbUuHjC4DfZ2VqqIGrF2AgAAycYCAAGbXAIAC0LTAgAStsoCAADya0A==
Date: Wed, 31 May 2017 21:41:56 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBD3961@ESESSMB109.ericsson.se>
References:  <528630A5-051A-4116-9D5C-79755DF347B3@nostrum.com> <645392ed-901f-e6c7-6b19-03ef31fb9865@nostrum.com> <7EE79107-041E-4725-B40C-D1C8350F7411@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CBCDE09@ESESSMB109.ericsson.se> <7B59744D-7A19-46F8-9C17-D67DF1DA9E78@nostrum.com>
In-Reply-To: <7B59744D-7A19-46F8-9C17-D67DF1DA9E78@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGbE9RHeZhX6kwZ19AhbzO0+zW8w8u4vF oqFzJavF1x+b2BxYPJYs+cnkMWvnE5YApigum5TUnMyy1CJ9uwSujB2L5zIWrFCu+HN3JXMD 4xalLkZODgkBE4m7pzaydjFycQgJHGGUaDh+jRHCWcwo0Xh1J5DDwcEmYCHR/U8bpEFEQEni efNWFpAaZoHNjBJftjeC1QgL+Er8PycKURMg8XPvViYIO0ziwoftYDaLgKrEjX//2UFsXqDy zfd/sYDYQgKXmST2LMwGsTkF7CUePWtjBrEZBcQkvp9aA9bLLCAucevJfCaIowUkluw5zwxh i0q8fPyPFcJWklh7eDsLyDnMApoS63fpQ7QqSkzpfgi1VlDi5MwnLBMYRWchmToLoWMWko5Z SDoWMLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMm4NbflvtYDz43PEQowAHoxIP705F /Ugh1sSy4srcQ4wSHMxKIry+akAh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRm p6YWpBbBZJk4OKUaGKU8u4663mDwSOj48e+qSMr3KXt2Ja4XvJPzhPXcAbMDxbUxmnUxsyca 7zZSZl+554/dw6PR2p4W6z/bShsVpEmZbD7T5z/pUPLzV0GtaR0Re1RfHZ69t37Gk5rud+nq j8tWrp4V9PnpNskEhUXVzypjbydICR+5c0ZZUazI4PK3l28UhTi6OJRYijMSDbWYi4oTAWBh Q9qXAgAA
Archived-At: 
Subject: Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 May 2017 21:42:07 -0000

SGksDQoNCkkgcmVhbGx5IHRoaW5rIHRoYXQgbWFuZGF0aW5nIGdsb2JhbCB1bmlxdWVuZXNzLCBm
b3IgYSBwb3NzaWJsZSB1c2UtY2FzZSB0aGF0IG5vYm9keSBpcyBzdGlsbCBhd2FyZSBvZiwgaXMg
b3ZlcmtpbGwuDQoNCklGIHN1Y2ggdXNlLWNhc2UgY29tZXMgdXAsIHNvbWVvbmUgY2FuIGFsd2F5
cyB1cGRhdGUgdGhlIHNwZWMgaW4gb3JkZXIgdG8gbWFuZGF0ZSBhIGdsb2JhbGx5IHVuaXF1ZSB2
YWx1ZSBmb3Igc3VjaCB1c2UtY2FzZS4gQWx0ZXJuYXRpdmVseSwgdGhlIHZhbHVlIGNhbiBiZSB1
c2VkIHRvZ2V0aGVyIHdpdGggc29tZSBvdGhlciB2YWx1ZShzKSAoQ2FsbC1JRCwgdHJhbnNhY3Rp
b24taWQsIENTZXEgZXRjIGV0YyBldGMpIGluIG9yZGVyIHRvIGNyZWF0ZSBhIHVuaXF1ZSByZWZl
cmVuY2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmVuQG5vc3RydW0uY29tXSANClNlbnQ6
IDMxIE1heSAyMDE3IDIyOjAzDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBBLiBKZWFuIE1haG9uZXkgPG1haG9uZXlAbm9zdHJ1bS5j
b20+OyBkcmFmdC1pZXRmLXNpcGNvcmUtY29udGVudC1pZC5hbGxAaWV0Zi5vcmc7IHNpcGNvcmVA
aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtc2lwY29y
ZS1jb250ZW50LWlkLTA1IC0gUFVMTCBSRVFVRVNUDQoNCg0KPiBPbiBNYXkgMjgsIDIwMTcsIGF0
IDE6NDAgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b20+IHdyb3RlOg0KPiANCj4gSGksDQo+IA0KPj4+Pj4gSSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJl
cXVlc3QsIGJhc2VkIG9uIHlvdXIgY29tbWVudHM6DQo+Pj4+PiBodHRwczovL2dpdGh1Yi5jb20v
Y2RoNHUvZHJhZnQtY29udGVudC1pZC9wdWxsLzYNCj4+Pj4gVGhlIGRpZmYgbG9va3MgZmluZS4g
V2UgcHJvYmFibHkgd2FudCB0byBtYWtlIHN1cmUgdGhlIFdHIHNoYXJlcyANCj4+Pj4gdGhlIG9w
aW5pb24gdGhhdCB0aGUgQ29udGVudC1JRCB3aWxsIG5ldmVyIGJlIHJlZmVyZW5jZWQgZnJvbSAN
Cj4+Pj4gb3V0c2lkZSB0aGUgU0lQIG1lc3NhZ2UuDQo+Pj4+IEplYW4sIGRvICB5b3UgaGF2ZSB0
aG91Z2h0cyBvbiB0aGF0IGZyb20gdGhlIHNoZXBoZXJkIHBlcnNwZWN0aXZlPw0KPj4+IA0KPj4+
IFRoZSBXRyBkaWQgZGlzY3VzcyB3aGV0aGVyIHRoZSBDb250ZW50LUlEIGNvdWxkIGJlIHVzZWQg
b3V0c2lkZSBvZiB0aGUgbWVzc2FnZS4gDQo+Pj4gVGhlIHRha2Vhd2F5IHdhcywgdGhhdCBzaW5j
ZSBhIFNJUCBoZWFkZXIgaGFzIG5vbi1NSU1FIGZpZWxkcywgdGhlIA0KPj4+IENvbnRlbnQtSUQg
Y2FuJ3QgcmVhbGx5IHJlZmVyIHRvIHRoZSBlbnRpcmUgbWVzc2FnZSwgYW5kIHRodXMgd291bGQg
bm90IGJlIHVzZWZ1bCBvdXRzaWRlIHRoZSBtZXNzYWdlLg0KPj4gDQo+PiBUaGVyZSBzZWVtcyB0
byBiZSB0d28gaWRlYXMgaW50ZXJ0d2luZWQgdGhlcmU7IG5hbWVseSB0aGUgaWRlYSBvZiANCj4+
IHdoYXQgYSBjb250ZW50LUlEIGlkZW50aWZpZXMsIGFuZCB0aGUgaWRlYSBvZiB3aGV0aGVyIGEg
Y29udGVudC1JRCBjb3VsZCBiZSByZWZlcnJlZCB0byBmcm9tIG91dHNpZGUgdGhlIGNvbnRhaW5p
bmcgU0lQIG1lc3NhZ2UuDQo+PiBCdXQgSSB0YWtlIHlvdXIgY29tbWVudCB0byBtZWFuIHRoYXQg
Ym90aCB3ZXJlIGRpc2N1c3NlZC4gSXMgdGhhdCBjb3JyZWN0Pw0KPiANCj4gQXMgZmFyIGFzIEkg
cmVtZW1iZXIsIHdlIGRpZCBub3QgZGlzY3VzcyB0aGUgcG9zc2liaWxpdHkgb2YgcmVmZXJlbmNp
bmcgYSBib2R5IG91dHNpZGUgdGhlIFNJUCBtZXNzYWdlLg0KPiANCj4gSG93ZXZlciwgbm9ib2R5
IGhhcyByZXF1ZXN0ZWQgZm9yIHRoYXQgcG9zc2liaWxpdHksIHNvIEkgZG9uJ3QgdGhpbmsgd2Ug
bmVlZCB0byBjb3ZlciBpdC4gSWYgc29tZW9uZSwgYXMgc29tZSBwb2ludCwgc2VlIGEgbmVlZCBm
b3IgaXQsIGhlL3NoZSBjYW4gdXBkYXRlIHRoZSBzcGVjIGFuZCBkZWZpbmUgaG93IGl0IGlzIGRv
bmUsIHdoYXQgaW1wYWN0cyBpdCBoYXMgb24gdGhlIHVuaXF1ZW5lc3MgZXRjLg0KDQpJdOKAmXMg
a2luZCBvZiBoYXJkIHRvIGRlZmluZSBleHRyYS1tZXNzYWdlIHJlZmVyZW5jZXMgbGF0ZXIgaWYg
dGhlIGluaXRpYWwgdmVyc2lvbiBkb2VzIG5vdCByZXF1aXJlIGdsb2JhbCB1bmlxdWVuZXNzLiBJ
ZiBwZW9wbGUgd2FudCB0byBsZWF2ZSB0aGF0IG9wdGlvbiBvcGVuLCB0aGVuIGdsb2JhbCB1bmlx
dWVuZXNzIG1heSBzdGlsbCBtYWtlIHNlbnNlIG5vdy4gSeKAmW0gb2theSB3aXRoIGl0IGVpdGhl
ciB3YXkgYXMgbG9uZyBhcyB0aGUgV0cgaGFzIHRob3VnaHQgaXQgdGhyb3VnaCwgYW5kIGhhc27i
gJl0IGp1c3QgcGlja2VkIGl0IGFyYml0cmFyaWx5Lg0KDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4g
Q2hyaXN0ZXINCj4gDQo+IA0KPiANCj4+Pj4gSG93ZXZlciwgSSB3YXNuxIV0IHN1cmUgaG93IHRv
IGFkZHJlc3MgdGhlIGZvbGxvd2luZyBjb21tZW50Og0KPj4+PiAiMS4yIGFuZCAxLjM6IEEgc2Vu
dGVuY2Ugb3IgdHdvIHRoYXQgbW9yZSBzdHJvbmdseSBjb250cmFzdHMgImJvZHkgDQo+Pj4+IHBh
cnQiIHZzICJtZXNzYWdlLWJvZHkiIHdvdWxkIGJlIGhlbHBmdWwuIEkgdGhpbmsgdGhhdCBzb21l
IHBlb3BsZSANCj4+Pj4gd2lsbCB0aGluayBvZiBhIG1lc3NhZ2UtYm9keSBhcyBzdGlsbCBhIGJv
ZHktcGFydC7LmyBJIHRoaW5rIHNlY3Rpb24NCj4+Pj4gMS4xIGRlc2NyaWJlcyB0aGUgZGlmZmVy
ZW5jZSBiZXR3ZWVuIGEgbWVzc2FnZS1ib2R5IGFuZCBhIGJvZHktcGFydC4gDQo+Pj4+IEkgZG9u
xIV0IHRoaW5rIHdlIHNob3VsZCBjb3B5L3Bhc3RlIHRoYXQgaW4gc2VjdGlvbnMgMS4yIGFuZCAx
LjMuIA0KPj4+PiBPciwgZGlkIEkgbWlzdW5kZXJzdGFuZCB5b3UgY29tbWVudD8NCj4+PiBPbiBy
ZWZsZWN0aW9uLCBJIHRoaW5rIHRoaXMgbWlnaHQgYmUgZmluZSBsaWtlIGl0IGlzLiBJIGtub3cg
dGhhdCANCj4+PiBzb21lIHBlb3BsZSBjYXN1YWxseSByZWZlciB0byB0aGUgZW50aXJlIGJvZHkg
YXMgc3RpbGwgYSDigJxwYXJ04oCdLCBidXQgDQo+Pj4gdGhhdCBkb2VzbuKAmXQgc2VlbSB0byBi
ZSByZWZsZWN0ZWQgaW4gdGhlIE1JTUUgUkZDcy4gTGV04oCZcyBzZWUgaWYgDQo+Pj4gYW55b25l
IGNvbW1lbnRzIGluIExDLg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBDaHJpc3Rlcg0KPiANCg0K