Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-rcd-06
Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 18 August 2023 21:58 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 8EA4EC15107E for <sipcore@ietfa.amsl.com>; Fri, 18 Aug 2023 14:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.102
X-Spam-Level:
X-Spam-Status: No, score=-7.102 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 w2v7AwqMIiCl for <sipcore@ietfa.amsl.com>; Fri, 18 Aug 2023 14:58:50 -0700 (PDT)
Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2072.outbound.protection.outlook.com [40.107.212.72]) (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 E9813C14CF0D for <sipcore@ietf.org>; Fri, 18 Aug 2023 14:58:49 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BicjKgM0AJPAobikZGaA8GqlO2pF8vYP1vzXYH/lRZ2C4KGjKuEYHbIryNF4xYsPcN1Ff06VTfW2Bc+Jzkc6fPpJmluVxuXg2z6qbb483cz3p5RLuNFM5p+xu+FCM4WoO89qUCCURSu/s7N6Mx+NzF3nNBnyQuBt+yhoGtBHNilUkuQ4kygwGK3/bbt1zrrIRslvhaf4Em2COea2PxM3brqgzCisdfOpT4vl9LwK9wIzjG2vJ3WPy+MQVKVX6pZrPccfZQVkWIj6d8QzGscOWrAgOmUzj257cikk3F0I1REggt+tzDet0QbKJb3FAAqjR+N+vja6y0Q0Hc4xOrzUxA==
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=r0ZITrV490XFFCEZmCXayusWBOrct0aNUaU61N3Opo4=; b=T+MSmZ4SqIgDOJgOqQW2YrQa3Sq7ZRSadZjgT2SY8nYfqKM6aaCAZducoNwTIAv8MXCuxi1CXPIutnrDCeD/fsrTG+pAphXMhOUz+3F/TIEBPocZUb8N9jRZkbcAgdXHx2CWwJHHzBf1I87y3h+p+nZVTPGuVkUPSZ+0SdREuk9775z0vuIcFZfOK+O0SpIEaUB28gnCNe9HqBzf6cLmcGOVp5lA2CN6YdJiNgV+ZXe9tKPlY58b4EDIJTqbUbsrR9X0caVPWeK5JZvySQrSsl7QzFRB76BY7yMkANCj9n54qP5F26bLdSQZbNfax2hx3FDi/3OP2z+j8nhXA4RzOw==
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=r0ZITrV490XFFCEZmCXayusWBOrct0aNUaU61N3Opo4=; b=KVCHoBOVeLmoi14ZhdxJo//tykq5nVstCGMvIbenq/NH+o0fSBh2eIzLcjV7dAcCAOvxHWK2lKTabSJalUYqKumHQDZMFwyDIcR/FfHPCX1yGUHN2YQ5RLudLgvnPym2ub/uK9/CgshXLmGot8LvvRu2r5TSA2So/LJY+2jG45o=
Received: from BN8PR07CA0009.namprd07.prod.outlook.com (2603:10b6:408:ac::22) by PH8PR12MB7280.namprd12.prod.outlook.com (2603:10b6:510:220::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6678.31; Fri, 18 Aug 2023 21:58:48 +0000
Received: from BN1NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:408:ac:cafe::29) by BN8PR07CA0009.outlook.office365.com (2603:10b6:408:ac::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.20 via Frontend Transport; Fri, 18 Aug 2023 21:58:47 +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 BN1NAM02FT061.mail.protection.outlook.com (10.13.3.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6699.16 via Frontend Transport; Fri, 18 Aug 2023 21:58:47 +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 37ILwjHK018454 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 18 Aug 2023 17:58:46 -0400
Message-ID: <0833a831-eece-541f-e0b9-5b5f97a50f19@alum.mit.edu>
Date: Fri, 18 Aug 2023 17:58:45 -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: Chris Wendt <chris-ietf@chriswendt.net>
Cc: sipcore@ietf.org
References: <da9ba37b-52a0-c8db-252b-8a6977140581@nostrum.com> <088772af-222e-1fdd-0a00-e6c49edd3d3d@alum.mit.edu> <80453399-F6B0-42F4-9C0F-04A229D33EE8@chriswendt.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
In-Reply-To: <80453399-F6B0-42F4-9C0F-04A229D33EE8@chriswendt.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: BN1NAM02FT061:EE_|PH8PR12MB7280:EE_
X-MS-Office365-Filtering-Correlation-Id: f76e316f-7db4-4d49-1020-08dba0364c56
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 4JjbIC0f/W1oII5JiHORbFXOHbZDSf3IS5MYblARd3mdkw3eswHALTw7T4Bhq0sVnwMaMcTOL4owNz7YeIWSolTexCIyvx7fypAgXia+DsGYAJt7VV0kmg7aKvbkiOWiJdofDJO3fFofE/480i3Y9KaS9GUyXvrXkZP1ATJYpNstpLsvkxrRI7/jKZ/kuH8kP1NCApOcQlcDip+LkVnAmJuBPdqXuzFpsyz57eg8bA79JHi38O3fhb19aFSLeGMUbkm/O9udO1mdOvTMRLobmrxkKtzz0aX//cdbPwKwSIHvVR/qYnatPQXiEfF/rT8DcNP0zk4a6sf1IPSkLHwXyqiivjKZ6pSonpDsg1CccvxEaspWPVZz/9i9kmOYSrnATGL5BOpMlkmw54qqyzm9NkqjbVpdn+y4kD82cNfNZgvKyzUTYi20GgHJL6fHRmufDH6U4/+DzlJzkJOkGvN8Mt9dYGdVIadAfXvrN72iDG2OJIUu5yVUt6CRr+GUbh7f1wibE2l6/KhfEIlAHrB4T/tJOA9wsvnbB7BXgzR7nH7xc/Luble9U7KX4Eztfd3/124ufCC5VeEaoYOJCYrsBljt2Y03Fki/kF91Q9AF7b6ZlvymYCutLxEakA5zhsoj9ZMYA+76BXNgyWy1VmcZyG9KZZh4b2FaYqcVEwK8UALFXU4RgMPbgs/ju5P/O7aODjxyGi2NbJ3jDmIGhjL7OGYOAnbXV3njzpsCMkXQN7Pj+/b0pDSR9o4dBTdByHV6
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)(39860400002)(346002)(396003)(136003)(1800799009)(451199024)(186009)(82310400011)(46966006)(36840700001)(41320700001)(31696002)(86362001)(31686004)(40480700001)(83380400001)(8676002)(8936002)(53546011)(4326008)(2906002)(41300700001)(26005)(336012)(36860700001)(956004)(47076005)(2616005)(75432002)(5660300002)(82740400003)(478600001)(7596003)(356005)(70206006)(316002)(6916009)(70586007)(786003)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Aug 2023 21:58:47.1662 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: f76e316f-7db4-4d49-1020-08dba0364c56
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: BN1NAM02FT061.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR12MB7280
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/xI4LigNUxiyBkqvgScQfdOhjw08>
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-rcd-06
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: Fri, 18 Aug 2023 21:58:52 -0000
Hi Chris, A few followups below. I've removed everything I agreed with or had no comments on. On 8/18/23 12:09 PM, Chris Wendt wrote: >> * Section 3 - jcard vs >> >> This section also explains why it is defining "jcard" rather than using "card". But something isn't clear to me about this: >> >> Is the intent that "jcard" replace the use of "card", or are the two intended to coexist and be used for carrying differing data? If they are to coexist, how are they to be reconciled? > > The intent was to coexist, the text in 3261 is a bit loose, vcard and LDIF formats are referenced as examples. > I think the point might be that this document is saying that jcard references the RCD flavor of jcard defined in this document. If we agree with that interpretation and using jcard for this document definition only vs jcards more generally (where i think “card” could be used), i can make that explicit. Can you add some words explaining the relationship, and how a recipient should proceed when receiving both? (Especially, if both contain a field with similar semantics.) > I would also be open to using something like “rcd-jcard” if we want to make the distinction more clear. I don't have an opinion on this. >> Also, is there significance to "purpose=jcard" and "call-reason" appearing with the same URI, vs appearing with separate URIs? >> >> Perhaps call-reason should only be allowed alongside certain values of purpose. > > This was the intent, purpose is associated with URI before it, and call-reason is a related but separate parameter. > The intent was that the RCD info would be contained on the same Call-Info header, but similar to above i can clarify that and make that restriction if we agree on this. > >> >> (Some of this ambiguity should have been specified in 3261 in the base definition of Call-Info. But it wasn't, so its up to explicit usages to pick up the slack.) > > agree Can you add some text to explain this in the context of this document. (Extra credit for coming up with general words that apply to all uses of Call-Info with arbitrary parameters.) >> * Section 7: >> >> I'm dubious of using a null data: URI with purpose=icon. ... You cleaned this up with your followup message. I think we should not assume the null data URI will work with all purpose values. Safer to assume its only valid with those that define how it works. But I'm interested in hearing if others think I'm being overly paranoid. > >> >> * Section 8.2 - Usage of multimedia data: >> >> I'm troubled by this section. I'm especially confused about which of these "requirements" apply to the sender vs. the receiver. What are receivers to do when they are unable to understand or render the data they receive? What should senders do in order to best support an arbitrary recipient? >> > > I know this is an often debated thing in IETF, but we wanted to provide some guidance. “icon” in 3261 basically says nothing about formats, i’d prefer not getting into codec debates etc :) but i think the text represents a baseline that most would not debate at this point since it’s all widely supported in OS’s/browsers/many devices. I can put some text to clarify your specific questions above and make it very optional support, we are just trying to give some baseline guidance. Further clarification would be good. Also, is it recommended to provide multiple URIs with alternative formats and the same purpose? If so, is it to be assumed that all have the same semantics and the recipient can whichever supported one it prefers? (Similar to multipart/alternative.) Thanks, Paul
- [sipcore] WGLC: draft-ietf-sipcore-callinfo-rcd-06 A. Jean Mahoney
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Keith Drage
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Brian Rosen
- [sipcore] Establishing an IANA registry for Call-… Paul Kyzivat
- Re: [sipcore] Establishing an IANA registry for C… Brian Rosen
- Re: [sipcore] Establishing an IANA registry for C… Keith Drage
- Re: [sipcore] Establishing an IANA registry for C… Paul Kyzivat
- Re: [sipcore] Establishing an IANA registry for C… Keith Drage
- Re: [sipcore] Establishing an IANA registry for C… Brian Rosen
- Re: [sipcore] Establishing an IANA registry for C… Paul Kyzivat
- Re: [sipcore] Establishing an IANA registry for C… Olle E. Johansson
- Re: [sipcore] Establishing an IANA registry for C… worley
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- [sipcore] Review of draft-ietf-sipcore-callinfo-r… Paul Kyzivat
- Re: [sipcore] Review of draft-ietf-sipcore-callin… Chris Wendt
- Re: [sipcore] Review of draft-ietf-sipcore-callin… Paul Kyzivat
- Re: [sipcore] Review of draft-ietf-sipcore-callin… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… A. Jean Mahoney
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… Chris Wendt
- Re: [sipcore] WGLC: draft-ietf-sipcore-callinfo-r… A. Jean Mahoney