Re: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

Stephan Wenger <stewe@stewe.org> Mon, 20 November 2023 20:51 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A613C151543 for <avt@ietfa.amsl.com>; Mon, 20 Nov 2023 12:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, 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 (1024-bit key) header.d=steweorg.onmicrosoft.com
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 wp8PKIhD23Wd for <avt@ietfa.amsl.com>; Mon, 20 Nov 2023 12:51:49 -0800 (PST)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2123.outbound.protection.outlook.com [40.107.92.123]) (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 5019AC1522AF for <avt@ietf.org>; Mon, 20 Nov 2023 12:51:48 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bRJs2mgVPK4xC3RwbLpgfT8bz124nTbzNw+nKY0mgIhF96R/big0czQFOrbwt+pmul9L0HIQ/Gojg2KIHAVAPfzPqS8smWnbI7vC5uSq9tOM2pzzgdXyM66fx5OOy7JPjCeSkcOqCsA7pShMhLa0n6E39xj5FclTinavIPzS686ZMKcqve2LR0jTfvxtUK5WdHV1KsuGA3KB8ZQi16UBiafymJCB1SV0Wt5Dhekca+O4mg2Q6LjuqT4rbOYk5hdtnb3Wehv7KRoTkP8Bjdba/4XxxodgkxgZMdiDn3ewpGskP+wjrcIcr6vWi3oAkKIPyD5lh4B98gANhzPXK3y+gA==
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=VzfKFRLRX/R8N1co2u5Fa76mYVu7P0doKOpv/Nv8fF4=; b=QDDFdGS1I/wM5IGm4/IzJXPB6sYU4VDT8nSLjnr2J3rvd53PixozbdPW8fsTlG9pV86nVLmK6Q+aEBHXrqOa0ODWoI2UY/HfPZIRX9ikp6SIkcpVF73AOnKD7muh3Xcq3EgC2TuQn/kC9WJtKjYaLZdwSDPZKt4Wx02TmEbrEwL7O6uDJehKLUja/eNkRFDtJEhGxvxPcRZAGOmePykOhoJJum5xtRP4P9gtrddxy1lC5dKg1QQm96exa7SmJ6QHzrace3qqSEYwz2ALgAVf9G0NS5qmOxfUSTlpsHnYQz5xFeZK1JiMS3saV1D9yhEXPyLUYcajXduHms5Q0xU0ww==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=stewe.org; dmarc=pass action=none header.from=stewe.org; dkim=pass header.d=stewe.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=steweorg.onmicrosoft.com; s=selector2-steweorg-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VzfKFRLRX/R8N1co2u5Fa76mYVu7P0doKOpv/Nv8fF4=; b=VxrSbU+xgvT8w8sZo1NVGvvzK+ZTvQz9hqXgKq2My5KS6E8sTzfIhZeuB7Ud6pajXouzd7KD+/nIzuDEViDQ8aOC6OaYMIjAa8yCc+gHp5eOI8FdUSKBzUw39brY5bnHN30aEJ38acuB7kWwNWbIPJmsIppEJ+y3cZionGTmlSc=
Received: from PH0PR17MB4908.namprd17.prod.outlook.com (2603:10b6:510:d6::23) by SJ0PR17MB4661.namprd17.prod.outlook.com (2603:10b6:a03:372::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7025.16; Mon, 20 Nov 2023 20:51:40 +0000
Received: from PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::b12:ea4:48af:1a6d]) by PH0PR17MB4908.namprd17.prod.outlook.com ([fe80::b12:ea4:48af:1a6d%7]) with mapi id 15.20.7025.013; Mon, 20 Nov 2023 20:51:40 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Xavier De Foy <Xavier.DeFoy@InterDigital.com>, Hyunsik Yang <Hyunsik.Yang@InterDigital.com>
CC: IETF AVTCore WG <avt@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Thread-Topic: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00
Thread-Index: AQHaEZvdMBAgO2ARZkm55GlmK+gzaLBvNYAZgBRskoCAACElWg==
Date: Mon, 20 Nov 2023 20:51:40 +0000
Message-ID: <PH0PR17MB49084B0FD1B25CE36F25D15DAEB4A@PH0PR17MB4908.namprd17.prod.outlook.com>
References: <CAKKJt-exSpN4g27V-9HzEBpi6iheLFgNiOFNwGtuKygx_Gub+Q@mail.gmail.com> <PH0PR17MB4908653D008509165D8E6A37AEA9A@PH0PR17MB4908.namprd17.prod.outlook.com> <DS7PR10MB486342FC390519E143A477EDE5B4A@DS7PR10MB4863.namprd10.prod.outlook.com>
In-Reply-To: <DS7PR10MB486342FC390519E143A477EDE5B4A@DS7PR10MB4863.namprd10.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=stewe.org;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PH0PR17MB4908:EE_|SJ0PR17MB4661:EE_
x-ms-office365-filtering-correlation-id: fe75bc63-6318-47ab-6fe4-08dbea0a7eeb
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: N7zMpqVdh0C7gFsw48B5sYNVwJNAP6mHrkrcrYBDlrjQP2LMWXqMwu095gQDMbuFpLfuSh2YsNF7zp4NQFsltcELTglyeHIGHNsbURMzyJVluLCZ22hVCGn5rlsKOrWO1x4M5h0EYspLDcq2vKXuV+j134ORWQb8A5to+IIsxzxp1uMRGcSaqECjbdtevC/LDHCmSCfzGppsNr0zYFctNuCErJTumJ8HEabHASqevRouixDdP20dmj6PzHwzq0DXM7+SXW/UETkBdcfH2+YjtubcBYIvf/LPPq0tJdhk4kLIPRnisozJPrwLqbnXvRT3xTvlETZm3JCR+tzaAyMGspehMblf6+qBkKw/4nhpltHSbZucxfbXSxZNSv8oy7U2PrDT49UyVtP0GTAgOZusyjGEa1qGVIkWWeZTcKOmKsti/Uge1D+ZmCwTzbvQfbrZOhw1zPN8lKuTIJLPWdkQ1qPRjF96uNfh5kV+fFOpQNL5PjqPpgEXux6+ph7OCLJWrpaVQCUhhZuPDCWhlsAczx2OuYlvYTmbZijFcbd0GpOLsQTAyPoUogUoJtibbwB/WAAZjEKQAvTanHlylbTOQIzkY8qE/rMGeOWzp4PxbEW6XGlJRXKg7OAgLc5PhzmMJ06obN939o1KEyRW2UCJYQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR17MB4908.namprd17.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(39830400003)(396003)(366004)(346002)(136003)(376002)(230373577357003)(230473577357003)(230922051799003)(186009)(1800799012)(64100799003)(451199024)(1690799017)(83380400001)(122000001)(71200400001)(478600001)(7696005)(6506007)(53546011)(966005)(38070700009)(55016003)(66476007)(66556008)(64756008)(66446008)(54906003)(316002)(66946007)(8676002)(4326008)(8936002)(110136005)(166002)(76116006)(9686003)(38100700002)(86362001)(30864003)(2906002)(33656002)(5660300002)(41300700001)(16799955002)(52536014)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: sd5wbzFhSWDdVwBvfgNz4YVI+m7fzwAflpUc2Yu+03bKriHSfWVQ5RF5PUCBNl1LKDhZYW8ysjCfs9WSpNMaiT5sE5FMoSN7CMU2usRtktnK6a57ew4v0+ROBHHRgX8SYzAyXa3f7Dp8rW7itbq03PJRNLJ94+s9E4p5W+QBh9W4JHP/7XTQkGeBQSOKJqpAS3eJMPjSO+3+W7GBaRemPqh5vY5f49+AzWLsm0n7GF10gMFqLJOXRtLJvpMYRYxlYZPKlUlAOuxDIrJcLcfDEGCMCO7QBYv0mD3YrPlg8d9AEOmGio+5hUeNyTEmtJTaCaosvdTwNUOL39KZPtk5GCtWmpJenBdfF5p4OChDCDrsxw6wBQQggIr6j9tDMGrXn6DXtdAgGIYClBnPnsb1h/MkKMIQWODvg0HGPglJBmFmN7acsJj+YOp+GF1y9ZvvIlTEkJf5lS5/8t8EglQOeN+9X+7bxBY9RnQRKiM9djgMYf5RXe4pqWfx1XRulX3vcCJmfaf38+9AduTK/GQGzov21DxNUWg27Dirntt5jGtyf1UgPEQfU8eIe+zEe4NOuCo8mugtBNEkTZrcb6oSeifB51TCzys8Wo6FgBJOebKPrZs+abg8fgg/9RIDdmYwOQoK49OYw9nvXezJmOxuLnK/wWA1lRqmx++zjGaKtzpLLUDH+V4lLSwhHo7wrwuIbfiqN0PfAEpBxGNYf/eMM7g+n4Yb3DwEqfNu4kIcx33S4m//d4deEukxuY93w6cIVoKwylp25/s3ecuUhq7IvCKdZgWi79C1i0NVKi2BQHjlGlp4lTMrZOjEx/5+n7XD4Sl994lmE+iJbiBjhCLjXcwaO+0dzJTWzuKc5x2W7h6A4xLCa6wgh2j7Q3xfrIE0HD+z3Cutnur7S5MMeISvnRBxCLx8X4dK0XSrpsN0rzrYLeSAbLrGUOEagq2obLaQyA/TJNyYfYOTykOFToe7tys0P7CCsaDuN1ZvxN3xnvn7fcJGLirU8zYp2WufDjb6y67iySja6baE2jMHHEijlcSov9pbgVgQfmEmMfOF+OhY+brpPIySQ1qm/275qZsP996lnJO0Jim/RTP0i2NCjGIbpuXu7whJErvD5ROm6d1iQc/+P/01NDRVXsgXXrEGNjHRKSF56rcqKBM6RAyFnqK9Wcv8OcmIUJUJWplX8iw7K2Ov9VPUdO1l5H5A8I0fmwi1cEYSixZYrcGJQLgHku7HgRe942LdyMQVQXfwdDWEEttCGIftGW+XRHer40l2WvA6stSv5hFgRrylWEKDLAVpvHim9dlmwq6ci+drzKn/VK2WMl2UsnVXFtiRF7FyEWwAdZSPByyD2q/tmLnj891/xaXGrI5pGKJOt7etNty8Da2ZaQLSKfMwqR7oJ9Op9M7Dlf2+burKVPUjgeOjuFTEO3xpugPUBrnNoUkKf4vnQyYcyud6kbBevteR82ghb8Kz1S0oPovFPzUqRfPbzY4iaWYPAbgBm4ywyJaKEpxSQiM6BQtZHpQ1uYxY/HPNeUDGfgc7C2BAfzweWc1VoKtP6vHbP7ZMOrk2HUP1PgM8pooxQnl8CVej1YeJw4wDghPUtYGGYlgVBiNCI0Wh349DjYX6m3nFVIzao5JuMmTDuOqjhOkdNeg5hQVeDOaE
Content-Type: multipart/alternative; boundary="_000_PH0PR17MB49084B0FD1B25CE36F25D15DAEB4APH0PR17MB4908namp_"
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR17MB4908.namprd17.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fe75bc63-6318-47ab-6fe4-08dbea0a7eeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2023 20:51:40.2902 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ldFdTI/ZQ/MW/dlZLfghARrWrLR1LfUEqds5It7j6kWxr/zHNbMBvY1pGatV/J3L
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR17MB4661
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/H_r6JfSPnNPgkhOfiHWF1Pjkfdw>
Subject: Re: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2023 20:51:53 -0000

The FDIS should be fine and using it will not delay your thing, as, typically, these normative reference documents come into play only at WGLC the earliest,
S.


From: Xavier De Foy <Xavier.DeFoy@InterDigital.com>
Date: Monday, November 20, 2023 at 10:52
To: Stephan Wenger <stewe@stewe.org>, Hyunsik Yang <Hyunsik.Yang@InterDigital.com>
Cc: IETF AVTCore WG <avt@ietf.org>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: RE: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00
Thanks Stephan,

  After discussing with our colleagues involved in MPEG, we would like to propose to share the FDIS draft (of 23090-31) that will be available in January. This appears to strike a good balance between a version that is stable and agreed on in MPEG, while being available in time to help AVTCORE reviewers.

  We plan to send you the references to the document once it is available (if you agree with this proposal).

  Best Regards,

Xavier.


From: Stephan Wenger <stewe@stewe.org>
Sent: Tuesday, November 7, 2023 2:02 PM
To: Hyunsik Yang <Hyunsik.Yang@InterDigital.com>; Xavier De Foy <Xavier.DeFoy@InterDigital.com>
Cc: IETF AVTCore WG <avt@ietf.org>; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Subject: Re: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00


As a follow-up regarding the (unavailable 23090-31): please send the FDIS of the version you are citing to me, and I will make it available per the second paragraph of the section “Document access” of this page: https://www.iab.org/wiki/index.php/ISO_liaison_relationship
(I mentioned that FCD to Spencer, but that was in brain-fog.  It’s the FDIS or FDAM that we need for an approved ISO deliverable.)
Stephan

From: avt <avt-bounces@ietf.org<mailto:avt-bounces@ietf.org>> on behalf of Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com<mailto:spencerdawkins.ietf@gmail.com>>
Date: Tuesday, November 7, 2023 at 09:00
To: Hyunsik Yang <Hyunsik.Yang@interdigital.com<mailto:Hyunsik.Yang@interdigital.com>>, Xavier De Foy <Xavier.DeFoy@interdigital.com<mailto:Xavier.DeFoy@interdigital.com>>
Cc: IETF AVTCore WG <avt@ietf.org<mailto:avt@ietf.org>>
Subject: [AVTCORE] My notes for https://datatracker.ietf.org/doc/html/draft-hsyang-avtcore-rtp-haptics-00

Hi, Hyunsik and Xavier,


Thank you for submitting this draft to AVTCORE. I do have some suggestions, but overall, I think it's quite good. and very close to being adoption-ready.



Most of my suggestions are opportunities for clarifications.


Please feel free to ask for clarifications, or reply, on the AVTCORE mailing list.



Best,



Spencer


1.       One major point, but fortunately, it's only a process point you're addressing early - this spec uses [ISO.IEC.23090-31], which is not freely downloadable by just anyone. The good news is that Stephan Wegner, the IETF liaison manager for JTC1/SC 29, has experience with obtaining copies of JTC1/SC 29 specifications for reviewers - he told me you should send him the FCD, and he will distribute it to only those IETF people who have need to know.


1.       Nit: please expand acronyms on first use, especially in the Abstract, and especially "MIHS!"


1.       Nit: please update the Conventions section to reflect BCP14, and include RFC2119 and RFC8174 as a Normative References, as


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.


[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.


[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.


1.       In Section 3, terminology, this might be clearer:


This document uses the definitions of the MPEG Haptics Coding standard [ISO.IEC.23090-31]. Some terms from that document are provided here for convenience.


1.       For Section 4.1, please add "hmpg" to the Definitions section, with its expansion


1.       For Section 4.2, please add "independent", "sync", "dependent", "non-sync", "time-independent", and "time-dependent" to the Definitions section


1.        For Section 4.3, I'm puzzled by the use of SHOULD, for a new specification that hasn't been deployed. Upon reflection, I don't think the considerations in this section need to be normative at all. Here's my suggestion:


The following considerations apply for the streaming of MIHS over RTP:


If a media sender sets durations with the same value for all non-zero duration MIHS units between initialization MIHS units, this will make the decoder more robust to RTP packet loss.


If a media sender sends one, or a few, MIHS silent units at the beginning of a haptic silence, and does not send subsequent consecutive silent units, this will allow the sender and receiver to save network resources.


If a media receiver receives a MIHS silent unit, the receiver can assume that silence is intended until the reception of a non-silent MIHS unit. This will make the decoder more robust to RTP packet loss.


EDITOR'S NOTE: these considerations may need to be re-evaluated depending on the finalization of the haptics coding specifications in MPEG.


1.       For Section 5.2, each of the field descriptions includes both the description of the field, and language about the way different values are processed by the receiver. I suggest moving the language about processing to section 5.3. So, for example,


D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit included in the RTP payload is, when its value is one, dependent (i.e., "non-sync") or, when its value is zero, independent (i.e., "sync"). In case of congestion, a receiver or intermediate node MAY prioritize independent packets over dependent ones, since the non reception of an independent MIHS unit can prevent the decoding of multiple subsequent dependent MIHS units.


would be split into


D (Dependency, 1 bit): this field is used to indicate whether the MIHS unit included in the RTP payload is, when its value is one, dependent (i.e., "non-sync") or, when its value is zero, independent (i.e., "sync").


in Section 5.2, and


In case of congestion, a receiver or intermediate node MAY prioritize independent packets over dependent ones, since the non reception of an independent MIHS unit can prevent the decoding of multiple subsequent dependent MIHS units.


1.       In Section 5.3, there's a mention of "aggregation". This would be clearer if the text said


Editor's Note: consider if it would be useful to add the ability to aggregate multiple MIHS units in a single RTP payload - for instance, to aggregate multiple MIHS units with different layer values into a single RTP payload.


1.       In Section 5.3, there's a figure that contains the payload structure type values. It would be good to also provide a figure that contains the MIHS Layer values, with a pointer from the description in Section 5.2.


1.       In Section 5.3.2, it would be good to point out that the use of MIHS Unit Fragmentation in RTP means that a media receiver can receive some fragments, but not other fragments, and the missing fragments would not be retransmitted by RTP. If there is any danger of an actuator behaving oddly because it interpreted a partial MIHS Unit Fragment, you might want to mention that, as guidance to implementers.


1.       In Section 6, is it correct to say


"This section specifies the optional parameters.described in [ISO.IEC.23090-31]"?


1.       In Section 6.1, I suggest moving this text to the end of Section 6:


The receiver MUST ignore any parameter unspecified in this memo.


1.       In Section 6.1, this looks a lot like an IANA Considerations section, but the information here is much abbreviated, compared to https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations. Since Section 10, IANA Considerations, just says "see Section 6", I'd suggest adding all of the attributes used in those registrations, especially since https://datatracker.ietf.org/doc/html/draft-ietf-mediaman-haptics-05#name-subtype-registrations says those registrations are also provided as examples. Alternatively, you could move the rest of Section 6 (including 6.1 and 6.2) into the IANA Considerations section, where IANA would be looking for what you want them to know, anyway.


1.       In Section 6.2 - I know this is going to be complicated, but I'll do my best. 🙃


My understanding - please correct me - is that most or all of these optional parameters are described in [ISO.IEC.23090-31], including values, and all that we're doing here is naming the parameters in a way that SDP would understand. So I THINK all that's required in this document, is to say (for example)


Corresponding parameter in [ISO.IEC.23090-31]

SDP Parameter Name

…

…

avatar type

hmpg-avtypes

…

…


If the IETF will not define new SDP parameters without a change to [ISO.IEC.23090-31], that should be about right. The other option would be to include values for each SDP parameter name from [ISO.IEC.23090-31], for the convenience of the reader.


If the IETF wants to use existing parameters that are already defined in [ISO.IEC.23090-31], we can update this RFC, or we could create an IANA registry for these parameters, with


Change controller: ISO/IEC JTC1/SC 29/WG 7 (MPEG 3D Graphics and Haptic Coding)


HOWEVER, if the IETF wants to use NEW parameters that are defined in revisions to [ISO.IEC.23090-31], using an IANA registry for these parameters becomes much more appealing.


If the IETF ever decides to define new parameters that aren't already in a JTC1/SC 29/WG 7 specification, using an IANA registry is almost certainly the Right Thing To Do.


I note that our AD, Murray Kucherawy, is a backup Designated Expert for https://www.iana.org/assignments/media-types/media-types.xhtml, and you're already talking to Stephan Wegner, the IETF liaison manager for JTC1/SC 29 about availability of [ISO.IEC.23090-31] for reviewers, I'm sure AVTCORE has the wisdom I lack, to work through all the details here!

[Banner]

[Banner]<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>

Defining the XR Experience: Enabling the Immersivity Ecosystem<http://www.interdigital.com/white_papers/defining-the-xr-experience-enabling-the-immersivity-ecosystem-?utm_source=signature&utm_medium=Email&utm_term=xr&utm_content=banner&utm_campaign=defining_the_xr_experience>
This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.