Re: [sipcore] Establishing an IANA registry for Call-Info protocol parameter values

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 17 August 2023 00:18 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 17F24C1516E1 for <sipcore@ietfa.amsl.com>; Wed, 16 Aug 2023 17:18:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.091, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U201ELKV2pz for <sipcore@ietfa.amsl.com>; Wed, 16 Aug 2023 17:18:16 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on2041.outbound.protection.outlook.com [40.107.96.41]) (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 C8B7EC151555 for <sipcore@ietf.org>; Wed, 16 Aug 2023 17:18:16 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NSttr/krAMF6f4FP1vYjVseciCQeTvskwAAX0FK/g1m3GmBv13UxfEtqOdCCTjftlc/FwQEYv5d0jyjvPRxzIzq19rcSxbyQp/veBBdQ+3OVZMGRjM1cWEfAxQ74XMuPn7CrvPY9+Wf5g6pgGGp/7NZ03uHiifj80CD7cG7LTC2fvlw9cz+sYENsWs12UOieQUR3HdkvlU07vGpmzae6OmQNHhxWVcTJl+pz7cYwWlz63U09dGpNZrRD7IgHTH9wLHBYcVZnXJDyTsMHay+Kn7E6Y04A4PtavrKYEU/hG9jSLLu6y6aOhhKV0pzdhWfHLA25vbv9HshB6SlskCidRQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=5MktAn0mZ88j37xrwtU/N0wPuOzPUg2onjTRgGdz95I=; b=a4vwsSH/uGmGhS6o10wR1fhenHlHyJtMRKGc56puzYfJWd9aCxcIlCnN7X4R+SFLj0/Mz980HW5hXnfvG2cUZ4SBf2Mh7RQMKt/TfVwTAoj3XZXNsyX0r2laa4LZrYE36TxC0r6M8PxLYCIP/C2hnnHyM1u2l6/QOyW51F0n6rkNU9K2Jkvh44n3NNfr9oD8wiCX6m6w+iZDjO+8+JqKfDtpShw4VIP7sUiWG0UWKVELcqUYm0LXLk2G/fsAsQ8dm4jeUl26UBloHR+/MDeV/e4Jad4510MwDBOMuT1xWFqkTY1b4wvIX2fYfpsd62Z1uOSNdKHGtSz4pZ5m/FcRTA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=pass (p=none sp=none pct=100) action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5MktAn0mZ88j37xrwtU/N0wPuOzPUg2onjTRgGdz95I=; b=Uspnaq9hVy5QWVLYXdsroVqyJXZIciPsFd2Ed6KGt1xMmPctmAFHu+Cdc5Wub0rNv56MzYIAIC886AmI9LkrkIITe8B+pLnCsGlsmGIUlZFUYhdT1KN++yLEHirXdwPivIYUlYSqy+xSQDB+OE2ruOfFyXqGJzhkQ6qfd7iw2V0=
Received: from SA9PR03CA0014.namprd03.prod.outlook.com (2603:10b6:806:20::19) by LV2PR12MB5920.namprd12.prod.outlook.com (2603:10b6:408:172::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.26; Thu, 17 Aug 2023 00:18:15 +0000
Received: from SN1NAM02FT0056.eop-nam02.prod.protection.outlook.com (2603:10b6:806:20:cafe::22) by SA9PR03CA0014.outlook.office365.com (2603:10b6:806:20::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6652.33 via Frontend Transport; Thu, 17 Aug 2023 00:18:14 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; pr=C
Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0056.mail.protection.outlook.com (10.97.4.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.15 via Frontend Transport; Thu, 17 Aug 2023 00:18:14 +0000
Received: from [192.168.1.52] (c-73-143-251-114.hsd1.ct.comcast.net [73.143.251.114]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 37H0ICDa019852 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for <sipcore@ietf.org>; Wed, 16 Aug 2023 20:18:13 -0400
Message-ID: <40f43ad2-738a-badf-bfbe-4733bb409883@alum.mit.edu>
Date: Wed, 16 Aug 2023 20:18:12 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0
Content-Language: en-US
To: sipcore@ietf.org
References: <da9ba37b-52a0-c8db-252b-8a6977140581@nostrum.com> <088772af-222e-1fdd-0a00-e6c49edd3d3d@alum.mit.edu> <84624ced-707b-6847-a4bf-d67f5de16c0f@ntlworld.com> <0cc14a38-9d1b-8024-8a0c-5e61ee795837@alum.mit.edu> <FFD22496-2030-4FA9-BA17-D10FA5F4F090@brianrosen.net> <97726013-cd4e-4765-d85f-4eeaf94413ce@alum.mit.edu> <97a4efad-ac00-c356-b05f-4051c9c73722@ntlworld.com> <5DB89F6B-36C3-4AD2-9CBA-B110753CBF63@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-Reply-To: <5DB89F6B-36C3-4AD2-9CBA-B110753CBF63@brianrosen.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SN1NAM02FT0056:EE_|LV2PR12MB5920:EE_
X-MS-Office365-Filtering-Correlation-Id: 58835a20-ee0a-435a-45e8-08db9eb772b8
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: v7ISPzEn+J69qPk6Xfthhq0koVjIjzLIrdTgnhPwVJ1cPrOy3SzhiSAUTV2SJB0i7vChLC/d/kRozV6YW8qyMr+IyNkzmwBAgL8S+LtI51rxvj2Vp/LxZfTqim8TaEu4ujmjWmjuqT0NMlPSx11qGGGPbj+DWwM8iLgz+mQMeVrLpJfMhBF0S9XTsZVEa+qQfBmUNmk0gmPm2WcxlHHOmS/dsNvR24ReKM6EeXA7QLou2LRNsEbiG4F+zCVRPFVVOhsTHvPqVIrZDhwR9DfxSEELPDMNNGOjycQnQsMLfC3i2wrkTFNiD1xceG/32czCZsZLUd72gRlfuVGMXzDYsGZD16DA83kmLS00YPUKQxKo0kozQWqGyZTnbxXHlCCOBIFwWrAAv+JzkujTotly0Bpg4+KgDlgrdmHe6Z+NMFpAa+N/Bf/yzX40jTAq0xktVffHlZlFEwCTn1T9MI3pV0OREC3b1s/yVY86/B46OHuFWD+eVWzLszN3t5m5dCXwEa231PXBDkQxj9uNWw7C7sMtkXY5Elt5x5F75mTuQUYLZei5uup6Fc+Azqdn1lTJNVz8N4nmWUjVMjVPvXUp1dmGHzK3qLnPlPGEbVVPheDku21KEIVDlrj6RtTPyhWbx7fbViH+URmSin+LzywwSVhq/EgFc4C0HIuyAG3Asp2ndD0yAIMP3ahT09xCf1tEy0wSHxEL2PPWbb5Fw7hBb+mZwe5kixyGY1vHtETYlTY=
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(13230031)(376002)(136003)(346002)(39860400002)(396003)(1800799009)(451199024)(186009)(82310400011)(46966006)(36840700001)(2906002)(83380400001)(66899024)(26005)(86362001)(40480700001)(336012)(478600001)(956004)(2616005)(53546011)(31696002)(41320700001)(75432002)(966005)(5660300002)(36860700001)(41300700001)(82740400003)(786003)(356005)(7596003)(316002)(70206006)(70586007)(6916009)(31686004)(8676002)(8936002)(47076005)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2023 00:18:14.1908 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 58835a20-ee0a-435a-45e8-08db9eb772b8
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: SN1NAM02FT0056.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LV2PR12MB5920
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/ZhwpON0Rt_taxEs8BBQVg7eAObo>
Subject: Re: [sipcore] Establishing an IANA registry for Call-Info protocol parameter values
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 17 Aug 2023 00:18:21 -0000

Brian,

On 8/16/23 6:23 PM, Brian Rosen wrote:
> As I said, we have several defined in emergency services, and wished we had a registry to declare them.  There are no RFCs that define them, but there are published, referenceable standards.

Hmm. That puts an interesting spin on this. If those defs aren't in the 
RFCs that are currently referenced in the existing registry, then there 
is no way for a party unaware of them to discover those values. And, in 
the future, somebody else intending to define a new value might 
accidentally reuse one of your existing values!

	Thanks,
	Paul

> Brian
> 
>> On Aug 16, 2023, at 4:01 PM, Keith Drage <drageke=40ntlworld.com@dmarc.ietf.org> wrote:
>>
>> As to the why - Is this a header field parameter that more values are likely to be defined in the future, or where there are other usages not documented by RFCs out in the field. If the answer is no, then there is no point. The minimum already exists by pointing to a list of RFCs.
>>
>> I would anly add to the how in that the actual documentation is fairly simple, and the data is merely an instruction to IANA, so its status would be informational. As to where it is documented, as such it should take path that requires least administrative effort.
>>
>> Keith
>>
>> On 16/08/2023 19:06, Paul Kyzivat wrote:
>>> [Changing subject since this is no longer about draft-ietf-sipcore-callinfo-rcd.]
>>>
>>> Just thinking about what changes are required to do this...
>>>
>>> First, *why*?
>>>
>>> The registry for the Call-Info purpose parameter currently has references to eight RFCs, each of which defines one or more purpose values. Getting a list of all defined values requires reading every one of those. Finding the definition of a particular value requires a search until you find it. This is not ideal.
>>>
>>> In theory this problem could exist for other header field parameters. But none of the others have more than three references, so the problem is less severe for them. So I'm not inclined to propose a general solution.
>>>
>>> Now, *how*?
>>>
>>> We have header field positional parameters that have their own registry of values. (E.g., "Reason Protocols".) But I'm not finding any header field keyword parameters (generic-param format, the kind listed in Header Field Parameters and Parameter Values) that have their own registry of values. Is there an existing example I have missed? If not then we have to make it up.
>>>
>>> I think we could follow what is done for positional header field parameters, such as the "Reason Protocols" registry for the Reason header field. We would need an RFC to establish this registry and initialize it with the grandfathered values.
>>>
>>> This RFC would have IANA considerations that define the registry policy and provide a template to be used by future documents that want to add another Call-Info purpose. I suggest that it is probably better as a stand-alone RFC rather than as an appendage to draft-ietf-sipcore-callinfo-rcd. This new RFC should revise the entry for the Call-Info purpose parameter, so that it only references RFC3261 and this new RFC,removing the references to all the past RFCs that have defined new values.  (That will guide future updaters to the new IANA registration parameters.)
>>>
>>> Then the new registry ("Call-Info Purposes"?) will contain a reference to the defining RFC for each defined purpose.
>>>
>>> Does the above seem right? Any better ideas?
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> On 8/15/23 10:48 AM, Brian Rosen wrote:
>>>> We have used new Call-Info purpose parameters in emergency services a lot.  For example, we have an Incident-Id, and a Call-IId that has different semantics to the SIP call id.
>>>> The lack of a registry is unfortunate.
>>>>
>>>> I would be happy to contribute text for this document that does the registry, or write a short draft that does it, or add it to a draft we’re working on in ecrit that defines a bunch of new registries.
>>>>
>>>> Brian
>>>>
>>>>> On Aug 14, 2023, at 12:43 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>>>>>
>>>>> .
>>>>
>>>
>>> _______________________________________________
>>> 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