IETF Logo Mail Archive

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

worley@ariadne.com Thu, 17 August 2023 16:07 UTC

Return-Path: <worley@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 04018C14F747 for <sipcore@ietfa.amsl.com>; Thu, 17 Aug 2023 09:07:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.993
X-Spam-Level:
X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, 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 (2048-bit key) header.d=comcastmailservice.net
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 iSwTkaysui-p for <sipcore@ietfa.amsl.com>; Thu, 17 Aug 2023 09:07:49 -0700 (PDT)
Received: from resqmta-h1p-028594.sys.comcast.net (resqmta-h1p-028594.sys.comcast.net [96.102.200.2]) (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 6EB8CC14F74E for <sipcore@ietf.org>; Thu, 17 Aug 2023 09:07:49 -0700 (PDT)
Received: from resomta-h1p-028517.sys.comcast.net ([96.102.179.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-h1p-028594.sys.comcast.net with ESMTP id WdQBqK8chtOBwWfVMqERcI; Thu, 17 Aug 2023 16:05:48 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1692288348; bh=kLsfRGR347OyIUWv7A0Wdcdk7ThsvqIG+QNKsHfkp48=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=t+gLvvlpT4rVjnNU0kRdmJCveWvvFbBMeQpMjG7YIW9Uauj7HorIxrBIJ88TV/TPt 6r8jHwKSkY1lfNm3oftOiiI0KYxKX8qOXD/c3uIhiNtzqqDv6XJ06yf7UkiVxvFf2w wHE9HL4R+ZPkggI1xUTgFXyKfTxfSu48F2LzvZeD5CTKmU7QfrKO8ZF0Grd6UxrfuE b3jDaYyoo/HdwlpzraZbRAbOI2Jw/qVKZx+AT6TIX3jNB0IqCXmCCU3DEMTBzmPrRd CL2ZEL3LrHMjHkAaJnFOYzRaC/oyiAHZL8OjOv86N5oOD6l+kfIKBipMpHaJuFoTEj odrz/dc88qQnQ==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::67f6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-h1p-028517.sys.comcast.net with ESMTPA id WfUyqTJZEbXTjWfUzqV1pT; Thu, 17 Aug 2023 16:05:26 +0000
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedviedrudduuddgleejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucenucfjughrpefhvffujghssedttddttddttddtnecuhfhrohhmpeifohhrlhgvhiesrghrihgrughnvgdrtghomhculdffrghlvgcutfdrucghohhrlhgvhidmnecuggftrfgrthhtvghrnhepveejfedtgeeffefhkeehffdttefhjeejhedtheehheelfeeutdehhfduieelgeehnecuffhomhgrihhnpegvgigrmhhplhgvrdgtohhmpdgvgigrmhhplhgvrdhnvghtnecukfhppedviedtudemudelvdemgegrtddtmeegfedtmeemieejfheinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohephhhosghgohgslhhinhdrrghrihgrughnvgdrtghomhdpihhnvghtpedviedtudemudelvdemgegrtddtmeegfedtmeemieejfheipdhmrghilhhfrhhomhepfihorhhlvgihsegrlhhumhdrmhhithdrvgguuhdpnhgspghrtghpthhtohepvddprhgtphhtthhopehsihhptghorhgvsehivghtfhdrohhrghdprhgtphhtthhopehpkhihiihivhgrthesrghluhhmrdhmihhtrdgvughu
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 37HG5OjN288426 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 17 Aug 2023 12:05:24 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 37HG5NtF288423; Thu, 17 Aug 2023 12:05:23 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: pkyzivat@alum.mit.edu, sipcore@ietf.org
In-Reply-To: <BC246A33-892F-4251-B5A8-28765D504733@edvina.net> (oej@edvina.net)
Sender: worley@ariadne.com
Date: Thu, 17 Aug 2023 12:05:23 -0400
Message-ID: <87350hy7r0.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/sA8pzxB5nkFBp7ikXDsvHi3WJbc>
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 16:07:55 -0000

"Olle E. Johansson" <oej@edvina.net> writes:
>> 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!
>> 
> Brians information is a clear indication that we need the registry for
> interoperability. Agree fully with Paul here.

Certainly, we need a way to document values used in the field for
emergency services.

I checked to see whether a "grep" would turn up a list of the defined
values by searching for examples of usage.  What that delivers is:

$ grep 'Call-Info.*purpose=' ...
./rfc3261.txt:   Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon,
./rfc6910.txt:   Call-Info: monitor-URI;purpose=call-completion;m=XX
./rfc6910.txt:         | Call-Info:<sip:456@z.b.com>;purpose=call-completion;m=NR
./rfc6910.txt:   a Call-Info header field with "purpose=call-completion".  The
./rfc6993.txt:   Call-Info: <xmpp:juliet@example.com> ;purpose=impp
./rfc7081.txt:   Call-Info: <xmpp:alice@xmpp.example.com> ;purpose=impp
./rfc8688.txt:   Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
./rfc8876.txt:      Call-Info: cid:abcdef2@example.com;purpose=EmergencyCallData.cap

that is, the 5 values "icon", "call-completion", "impp", "jwscard", and
"EmergencyCallData.cap" out of the 8 RFCs that are on record.

An additional 5 values are defined:  "card" is defined in RFC 3261,
"list-management" is defined in RFC 5367, "ccmp" is defined in RFC 7082,
the pattern "EmergencyCallData.*" in RFC 7852, and "rue-owner" in RFC
9248.

So I'd say that it's time we created a sub-registry to log these values,
because there's no way to locate the specification for any particular
value that doesn't require human intervention, nor for a list of defined
values.

Dale

v2.23.0 | Report a Bug | By Email