Re: [sipcore] AD Evaluation of draft-ietf-sipcore-content-id-05 - PULL REQUEST

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 31 May 2017 20:21 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 <sipcore@ietfa.amsl.com>; 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 <sipcore@ietfa.amsl.com>; 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 <sipcore@ietf.org>; 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: <D54DF3B2.1D309%christer.holmberg@ericsson.com> <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 <pkyzivat@alum.mit.edu>
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: <https://mailarchive.ietf.org/arch/msg/sipcore/zMpD7ccEgoSg80pg6WGvFhIiB-U>
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 <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=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