Re: [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)

Chris Wendt <chris-ietf@chriswendt.net> Fri, 18 March 2022 14:16 UTC

Return-Path: <chris-ietf@chriswendt.net>
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 6AC0E3A0ABB for <sipcore@ietfa.amsl.com>; Fri, 18 Mar 2022 07:16:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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=chriswendt-net.20210112.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 COZUXfN1kCbM for <sipcore@ietfa.amsl.com>; Fri, 18 Mar 2022 07:16:44 -0700 (PDT)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 B8AAD3A0A9C for <sipcore@ietf.org>; Fri, 18 Mar 2022 07:16:43 -0700 (PDT)
Received: by mail-ua1-x92b.google.com with SMTP id a20so3263854uaq.11 for <sipcore@ietf.org>; Fri, 18 Mar 2022 07:16:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YvSmZdRX8HpbT+J+A7dssJKBvMhSArhSdBzOtlCJhVQ=; b=pt2k+hGHrh0tokrDd/RG7A/zyPe/2SQ5QnwwbybRMmRGkjc/sVtWQzU6TqSHz4YEU9 tXaTAxtdPf8oliTZyv/QGcheqpDVTXda+BeqU+Gs4QDkFOmKwenxGBEiAG7TmTCUGEi7 gVM/j0Kn/zQUdt0UBoZ7AWqC0A3x4L27Wrr0gNSN8L+inQCzJYR6+RFlsWLcjCNPAmOo GhRB407WJJ9RuD7LGfldqScXhDd1LcnObxwypCrlmtg0mtLWP9lsqJ0bfALp9CdR6wM7 eHfm/ijqv02g02Q/ijoHLcjQeaSpZHSvEyMCKF2g4y2nnOUH/obkEZ1cGVKXrOGluB+R ROEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YvSmZdRX8HpbT+J+A7dssJKBvMhSArhSdBzOtlCJhVQ=; b=Uc2UtCNDmWnBvuELo024xjt1eFHP1H4oKcbK5XJsWvR6oQgezcZyRjcDm6I3unhhRa h/NPs02OK7qtNfWHnlyWq3E9MdgBq7tXXQp3iDYXOdkivstipPhbQOek5LK4x2lArkWh uj8l+fqcpgoI3byzmF5/hr7zl1pGHRAvnwq1fVDtCzA/abOgXyIErUox7Df5FubhAhDt OUV5AUtsXvWdXc+toM2NDqox8/j4FPmX/6G5AT2nrWm0qzSSihsAnUVR6Na+nkSjCEFA +F8ctFDytEReaQFB84Agqmze7xsSV6dqBMnuudr7xlIAWwJGW3TWwn+tyYJjYJx/arNy 4LqQ==
X-Gm-Message-State: AOAM530JtFIW3PudDUPovo/ye9R+0awUsc45d21WqrBU2Fmaaz2qKAXi 1h5im1AF6jSO9PgS7SzjsZhmWGWExUEOLtML
X-Google-Smtp-Source: ABdhPJxFOXZtbrina55SE5/cNh0v8SaihrS8hCWt7E9OjVH6k6Alh4jaybJcUlPLM2NGkzFLSQ/1NQ==
X-Received: by 2002:a9f:35f0:0:b0:34c:2205:fe50 with SMTP id u45-20020a9f35f0000000b0034c2205fe50mr3417193uad.2.1647613001751; Fri, 18 Mar 2022 07:16:41 -0700 (PDT)
Received: from smtpclient.apple (c-69-242-46-71.hsd1.pa.comcast.net. [69.242.46.71]) by smtp.gmail.com with ESMTPSA id i25-20020a67f599000000b00324e5b9e509sm94661vso.25.2022.03.18.07.16.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Mar 2022 07:16:41 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
From: Chris Wendt <chris-ietf@chriswendt.net>
In-Reply-To: <CACgrgBbUASA4HTukPwZL9V=8XOMTx_keZcDh-pVc0eSJYtVS8w@mail.gmail.com>
Date: Fri, 18 Mar 2022 10:16:35 -0400
Cc: SIPCORE <sipcore@ietf.org>, stir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <86BE36F5-7CFE-48BE-B0A7-7458B67EB208@chriswendt.net>
References: <CACgrgBbUASA4HTukPwZL9V=8XOMTx_keZcDh-pVc0eSJYtVS8w@mail.gmail.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
X-Mailer: Apple Mail (2.3696.80.82.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/GkG7ZtNkDy8-_B5t0kVzG2B6QCE>
Subject: Re: [sipcore] draft-ietf-sipcore-callinfo-04 (call-reason)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 18 Mar 2022 14:16:49 -0000

Hi Henning, 

This is good feedback, you are correct there really hasn’t been a lot of discussion on the callinfo-rcd draft, most of the mind share has been toward the passport-rcd, now that i think that document has mostly stabilized on issues not related to your comments or the specifics of how we do callinfo, it’s a good time to engage on that and appreciate you starting the discussion.

I’d be curious to think what others think about using Subject for call-reason vs callinfo.  

I think the thought process as you sort of indicate sort of went a bit back in forth about whether jcard would be the extensible object we all put information about caller into, we seemed to have backed off of that for what has emerged to be the initial minimum use of RCD which is name, TN, icon, call reason.  The first three is info about the caller, the call reason is info that is likely specific to the call intent, not information about the caller. So in that sense Subject may make sense because after all that is what it was created for, but also we weren’t sure if there would be other categories of information that we may want to extend in call-info. For example, URL to relevant info about the intent of the call, or other call specific info.

Beyond your point, but related and maybe just validation for me, do we want to protect call-reason as part of RCD?  I think we sort of said, yes why not protect/sign it because we view RCD as an extensible set of claims, as long as we make that a claim that is not part of the “rcd” claim that is specifically about the calling party identity, which we did with “crn”.

I do also think we need to address when callinfo and other SIP headers/parameters are used to carry info vs in RCD claims.  Should they be mutually exclusive, that you should either do one or the other depending if you want the signature/integrity protection for your use-case?

-Chris

> On Mar 17, 2022, at 11:49 PM, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
> 
> There was a brief discussion on this in August 2020, but now that the draft is stabilizing, I'd like to comment on the call-reason parameter. I'm not sure I found all the discussions, with only an August 2020 discussion (from Paul Kyzivat and Chris Wendt) popping up. In any event, as drafted, this seems to be exactly duplicating the Subject header. Having two header fields that do pretty much the same thing seems unwise. 
> 
> There was discussion on structured content, but this doesn't seem possible to add without breaking backwards-compatibility. You really don't want to add JSON to an existing string, or other parameters.
> 
> There seems to be no obvious reason why systems that drop Subject would treat call-reason with more care (or deliver it to the UA). Indeed, richer information is likely to make the handling more challenging - the more stuff the UA can embed, the more likely that this will cause security concerns. (You really don't want to include full HTML with JavaScript here...)
> 
> It is also a poor addition to the callinfo header, as the RCD will likely be generated by a trusted entity, such as the carrier or the enterprise PBX, while the call-reason has to be generated, on a call-by-call basis, by the UA, either via human input or via the robot generating the (hopefully wanted) calls.
> 
> I think there are three reasons that Subject has not seen much use:
> 
> (1) For person-to-person phone calls, there seems to be little appetite to add more overhead to making calls. If I want to text ahead ("I'll call you shortly about the vet"), people will likely do that instead. Call-reason or Subject are not substitutes for texting-ahead.
> 
> (2) For enterprise-to-consumer calls, this seems like an opportunity for potential abuse and spam.
> 
> (3) SIP headers provided by the end system or end user don't seem to survive the paranoia of B2BUAs and various other in-call entities.
> 
> All of these would likely apply to call-reason, with the additional issue of who-generates-what added for complexity. If the landscape has changed, i.e., there's a willingness to deliver information UA-to-UA, then this would apply to the Subject header as well.
> 
> Henning
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore