Re: [nfsv4] My probable non-participation in IETF114 meeting -- missing agenda items
Rick Macklem <rmacklem@uoguelph.ca> Tue, 02 August 2022 00:36 UTC
Return-Path: <rmacklem@uoguelph.ca>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE01EC1BED20 for <nfsv4@ietfa.amsl.com>; Mon, 1 Aug 2022 17:36:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uoguelph.ca
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 mnmD54eFM4Rd for <nfsv4@ietfa.amsl.com>; Mon, 1 Aug 2022 17:36:50 -0700 (PDT)
Received: from CAN01-YT3-obe.outbound.protection.outlook.com (mail-yt3can01on2080.outbound.protection.outlook.com [40.107.115.80]) (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 B49A0C15A727 for <nfsv4@ietf.org>; Mon, 1 Aug 2022 17:36:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lAZKGYo01pU2N0qEbjNub5603lgFcPt6m66URuLLt6O7yYoWa0mO+5NC1rhce1GJcQuqiK45Huhagl+1lhxaW+CDwQvG0dktHBtogrVONj/0IpM5recgOmiTRO7XcY++xXhr750Cy6nd48JcnarruVzN/vwvJPS6piKOIi1HqYR2VsWIypc8738jhU/Dz5U8rWDlTVXr9VU30G3rVQqonbn3QKZ+qRV/e/FO0cIGGLCy/o/rn89F+xRqct400OpPwfQaonrbRspoOOQ3tndyszZnoUBy36Nsb1jNwjedH+x51W8rFu6t9IMwdZqp6XfODKf7yQemif2uCAiE1JI2Mg==
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=0fG02DR1jP7jC6x3GsoWIh41r+cUFv7c4NV4UF5lDAA=; b=bop4sLhtP4kuoQhOYGBCDzzqTICqdyO/dnoVoK8HXkng69mcf9Dv19V47XUhRTA3Df31qRR5Vw6Tnu3k/N5vzudFmu/kA58yZVkeH6wusdJbq0jP+qoJnGkkyEhbOh295WWQwQrYafMBmnHtzhfOtvBOXrIDmU3LTe4HhJZlBhA5sBcwrTAiEoQEY3ZlcML7JUcxJSN+/RTaooegTduL/v8wgfvrbNTTrWkQQMXWFUNDSgpwNjvg8aVHghsLvKBAsJd3EoBLx//PuMkt2wt4ZgDDGyjZe/uYsEajZJ/rBN1fNNOM6I9XfDYM2R/h8o0SCxMTGggvEyawz17A45ictA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0fG02DR1jP7jC6x3GsoWIh41r+cUFv7c4NV4UF5lDAA=; b=CUBVOWrbNu6zZB07U6sf867H2gOGzr48Dgfag8Cefm4A7DzzgmZjpQudLdFE3aBoPy99Lohi8Hgbs8SWczKhPr1IBch8iEoXS4GDHXUrsOqBIeoGYB3fY1VO7iKEeBnz7E0sMqGzG+BT31Y3wKUU6/u9Zz6pkldmOuEAleGmVyP0ZpQC7rlT4lBOCbJaX4z4DiZrUwaEWOweHmLEZJ5/ZI/oyLVj6sfOg41rTtvC2/oEahcf/qq/ZeIlg/GUc+jle81atCLSMJ7S6jLaanlep7h1Q6fC4NSOlc4IHSgUqcq7S37BO8jSM30CUN/c9XuMym5/z0SZtzegewMxT0O8lQ==
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:81::14) by YQXPR01MB6236.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:2b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5482.11; Tue, 2 Aug 2022 00:36:47 +0000
Received: from YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM ([fe80::51a6:243b:f3db:61fe]) by YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM ([fe80::51a6:243b:f3db:61fe%9]) with mapi id 15.20.5482.016; Tue, 2 Aug 2022 00:36:47 +0000
From: Rick Macklem <rmacklem@uoguelph.ca>
To: "Black, David" <David.Black=40dell.com@dmarc.ietf.org>, David Noveck <davenoveck@gmail.com>
CC: NFSv4 <nfsv4@ietf.org>
Thread-Topic: [nfsv4] My probable non-participation in IETF114 meeting -- missing agenda items
Thread-Index: AdiapeJPGDuOG31eRCOPOq4dar4KOwH5BeYWANjpVFAABlm1FA==
Date: Tue, 02 Aug 2022 00:36:47 +0000
Message-ID: <YQBPR0101MB97426A8AF9FAF18186C495B8DD9D9@YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM>
References: <MN2PR06MB5597E737F236E8E35C02380FE18C9@MN2PR06MB5597.namprd06.prod.outlook.com> <20220726022100.GD30255@kduck.mit.edu> <CADaq8jfb0Ecbh-3AUW=wMJCT4yu1GwUX+y50cYNrZfRRHc8Dhg@mail.gmail.com> <MN2PR19MB4045F9FDDDD501D798B3B8A9839A9@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB4045F9FDDDD501D798B3B8A9839A9@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_Enabled=true; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_SetDate=2022-08-01T21:28:23Z; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_Method=Privileged; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_Name=Public No Visual Label; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_ActionId=1bb410ca-1d02-4f8e-a5e6-4b9f5e0d70ba; MSIP_Label_dad3be33-4108-4738-9e07-d8656a181486_ContentBits=0;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=uoguelph.ca;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f782d019-9bd2-44ce-fcb1-08da741f1535
x-ms-traffictypediagnostic: YQXPR01MB6236:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ZUTTVsx2dGfWtKvi0S1THw7TN+jwW4OTewUlvTEljTsJFAUCweDsqIulNsnmlcqheiFo4uqxk3BSD7cgGO4wkjEmuYDPqN+FaCfbvtk1w+XIM4N6yqon9bWmYZsCVxXztK0+nkOwcdnsy1lIpLJTKEFwkfkg/Bkgd8kQYYaDDNbSaLl+yU4hDe2/Ouo5HEohqQfXvEjHJIyuOA7CfDaXTKY0XHz3Y707WDoqguLKXbln5PgURMp5TBc6RZ2cJB6clazMF+4ulePhwwiy8KhU1UC2DFR5mXtwtWOMeo6OTZzayC5Qv/sGHfH40dWBYTNR5YmyEqgIwu9viBny3HA+h82z5juiv5QRRWKt088GGqru4jt7LHcUwEj3CUAYKpjDOHfXOy7itoNXaasUEQNAijvVE+Rcl/Tg7215MrFNUErK6FH74aesCLQ3yIV98k/rB6WRAKteR13103yOQBehI18IUygKvznRjnYnauEaAHbku0Yg+HnuqWxLZi1A/Y0/FkRWlyFHRMu+fWTi9DH9qo5vR7UJCL2g/K9S+pnzEIOYBg3R91acO6SWhPKdfw7xp7CODTyRbuNwe0P7/A2V5PHi4mMYTAspvnoa8MeM9tw8bJQgW18jnQcfHmb9Cd/J8AIDZ1A09KQgVXwbchG35/x7vxPHLqivnFOlVuruFKBIdyZfMyzAOUocjnvdA5yt7wUJ7PNfFMqJODceIguqzWSxhp3evbN1XKriSwz8aJ8hvR4UDnL/Yd/Nw9fWUgEL1DUWG5AILXyluvJQ3Q5isfnAl+LMMfmV092GZLErHqyVe3JVf4O+x9ySYXjWiXvkl/R/j0gSwVcar8mdcsSi1g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(4636009)(396003)(366004)(346002)(376002)(39860400002)(136003)(83380400001)(66946007)(91956017)(66556008)(2906002)(41320700001)(186003)(8936002)(66446008)(33656002)(52536014)(4326008)(76116006)(8676002)(66476007)(64756008)(5660300002)(316002)(786003)(55016003)(478600001)(71200400001)(966005)(9686003)(53546011)(110136005)(86362001)(41300700001)(6506007)(7696005)(38100700002)(122000001)(38070700005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: eIcOt4GVAR37os7+Y8A2VhjdaSUZ+/4X5NfTqRRQmYWSXuklUBLWhqzLgx1OKc0fWaEK2T1EeiYddluFGV9uSTHjwoNEQ/E7nDoBNKXzfEuAI0YUfqhG7Su75UPwKfFR16EA/VHA7PE1vei99eS08V9xChpPnsfFtqcF+SasmKYp61TwWL6HQeYoHrgElvAoMgxdPekM4HWDl9clcsmCseEiA5DMjcyaNoPvNr3zpCLFX6lLqd6Au+hr+NCBWPeDDxCAsEUrYHxACmn3I4imGLarIpXx1mIzcYAKXiEQPauLqDX4Ly3l37yX6DXBkhBXTS6g77M72w8pXf21Glk0oQ3we/BYMgUFbEUAfTpiEcj6m4IFxmeCtFaI5CEO4vSCE6DT6m/DYojIv6KYJfOyiEPE71ntImgm2t8XyOBmc5Q8hEgtxz1Icbe1pH5zJkIrOqOREkiXXqxGx03EALK3VaXf9YDvztJt6ncyx00BuBGX2+t/PMH8B4XRpqyReP8teqEDC0vzxtg1MBvuGUUJNw+oc51+EZuqZzY7kWaC+k7ptSfaYh5vDnhqR9eMsJU0VS3qufsCSLY3eOfaWgjRu04lLsZQApOi6Iki/l8DeLuH3F+zELgj9ZswzcP+LvXyhsy/XE/Z4Pn4nkqihxvlZdgAZjMi9iTa7odL0+kLRg/P4lja/QGCwYPSUQqz0mKz6NRImbwFIznAWNEVf+cHgP7PBz0jfDLYxPvcUajHBus4l3HJPBrVLUQ0g1raiaLVzwEfNIOvYkxp8k/NJQM2B4KBa1jHtlfR6Mbw2zCLhY8+iWVu3fr+wAacIEjuGS5LUS+sMtkJr8tw2I5KsBbqtbjd5EX+8SpicnBu75lAhlFm5gs00BT9gOW12zbJYcNud0y188esNugQCaUCDECik46BY4hkD4CJpGqT2hhKmRQu5S0jXSdZOXV1KAxCIjH6NK2Ou7q7o5mpQ/8krlE4mw7YPyzAXlcWByUPk4fFfYYNkjeE22j/XpU7Q6/hM6tY8dywH71wnep3JG+7x4me9G9ovcouT/QLMewOMAPpx54UhoP0XHxDrjAFxunv6iumvHt14pVK0JCTVu0WcJtUkZifQuhGJaW1ATSUBisH+Hq5I7Gnw660bGkSgioqAvNUiTEy0avc117+vJijA04ypLqhqzNEogdesc65skObbL89WQTa8mICPFDeryIY6u290VBKlyXCfB1KGXt3+TcY2PoQ/oAyrQ9iO6M88sjpkFKFubq5QimXP9X6ABaect82kCCIDtTbphrPAT6Tob31Rkt/nsGp2PUSFxJSOqYtkrnuES1TgO3Zduq3bmC5WH8jKCRRzfrbjqsJo50GNGr6J9P2UK9/H8lxgcjydPNsmWsVG9YmbhHrGqbY3fiIue27D8tO88Y/Zwo4CshH772LOXYxrwtIGbQevMg1qCLwe778LE0FA5aLBTxnMaH6x6lLMbTSPJ5S0eQa3xLALnsbE07i0wPqFqR7P71iQ2jlNy27PRLEvGe59+CTxVK+VP2XVhzMx/U6ZnUKQvKC60btMpX42QZtsXS1oIaLYFMGoxGRSOh5WzhRv0BlNR0hQcdoJusgctNfgdB/0Zs+xYq0D+4U3nn3hIDnX2FZnTSrq2NBDXBKvth9YgHVedx13kao
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: uoguelph.ca
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: YQBPR0101MB9742.CANPRD01.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f782d019-9bd2-44ce-fcb1-08da741f1535
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2022 00:36:47.4858 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: RrEGfqp36xbJ0u47uO5uBXIEezsWE3HYhcntSpZ+oree2OGbPYQRJUxaYQyUCozKaAJUpz/5MSmH0JI0X04VWg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB6236
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/PHOkrlzGF8-6L9TrwLwSu6v9zWg>
Subject: Re: [nfsv4] My probable non-participation in IETF114 meeting -- missing agenda items
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 00:36:56 -0000
Black, David <David.Black=40dell.com@dmarc.ietf.org> wrote: >Dave, > >> The core issue derives from the following text in RFC7530: > >[ … SNIP …] > >> The above text was suggested by David Black based on discussions with internationalization experts, and had no problems getting accepted by the IESG. > >In light of what has (not) transpired since then … > >> The first method references RFC 3490, now obsolete, so cannot be transferred to a new NFSv4 internationalization document >> >> This reference should, almost certainly, not have appeared in RFC7530, but I'm not sure how it was approved. >> >> It seems very unlikely that the first method was ever implemented by any NFSv4 server, despite the fact it is recommended above. > >… while I could patch the text to deal with RFC 3490 being obsolete, I think "running code" wins this one … i.e., I suggest that the WG proceed to: > >> - eliminate the use of method one. > >That creates a small item to deal with, as method 2 contains a "MUST" >requirement that would apply to all implementations: > > >> As a result, the domain string returned on a GETATTR of >> the user id MUST be the same as that used when setting the >> user id by the SETATTR. > >I would expect server implementations to do exactly that, but it'd be good >to check - would compliance with that "MUST" be a problem for any >known implementations? > >If so, please explain how the GETATTR and SETATTR user id values could >differ. For the FreeBSD name<->id mapping daemon, the domain string is considered to be case independent. ie. UoGuelph.ca is considered the same as uoguelph.ca I think I did this because that is how DNS host domain names have traditionally been handled. rick Thanks, --David From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of David Noveck Sent: Thursday, July 28, 2022 9:57 AM To: Benjamin Kaduk Cc: Noveck, David; NFSv4 Subject: Re: [nfsv4] My probable non-participation in IETF114 meeting -- missing agenda items [EXTERNAL EMAIL] The core issue derives from the following text in RFC7530: string sent SHOULD be in the form of one or more U-labels as defined by [RFC5890 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR6jQoVSp$>]. If that is impractical, it can instead be in the form of one or more LDH labels [RFC5890 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc5890__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR6jQoVSp$>] or a UTF-8 domain name that contains labels that are not properly formatted U-labels. The receiver needs to be able to accept domain and server names in any of the formats allowed. The server MUST reject, using the error NFS4ERR_INVAL, a string that is not valid UTF-8, or that contains an ASCII label that is not a valid LDH label, or that contains an XN-label (begins with "xn--") for which the characters after "xn--" are not valid output of the Punycode algorithm [RFC3492 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3492__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR8HVeyrh$>]. When a domain string is part of id@domain or group@domain, there are two possible approaches: 1. The server treats the domain string as a series of U-labels. In cases where the domain string is a series of A-labels or Non-Reserved LDH (NR-LDH) labels, it converts them to U-labels using the Punycode algorithm [RFC3492 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3492__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR8HVeyrh$>]. In cases where the domain string is a series of other sorts of LDH labels, the server can use the ToUnicode function defined in [RFC3490 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3490__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVRw5pOT9y$>] to convert the string to a series of labels that generally conform to the U-label syntax. In cases where the domain string is a UTF-8 string that contains non-U-labels, the server can attempt to use the ToASCII function defined in [RFC3490 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc3490__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVRw5pOT9y$>] and then the ToUnicode function on the string to convert it to a series of labels that generally conform to the U-label syntax. As a result, the domain string returned within a user id on a GETATTR may not match that sent when the user id is set using SETATTR, although when this happens, the domain will be in the form that generally conforms to the U-label syntax. 2. The server does not attempt to treat the domain string as a series of U-labels; specifically, it does not map a domain string that is not a U-label into a U-label using the methods described above. As a result, the domain string returned on a GETATTR of the user id MUST be the same as that used when setting the user id by the SETATTR. A server SHOULD use the first method. The above text was suggested by David Black based on discussions with internationalization experts, and had no problems getting accepted by the IESG. . The first method references RFC 3490, now obsolete, so cannot be transferred to a new NFSv4 internationalization document This reference should, almost certainly, not have appeared in RFC7530, but I'm not sure how it was approved. It seems very unlikely that the first method was ever implemented by any NFSv4 server, despite the fact it is recommended above. The basis of the recommendation is quite unclear and it is not easy to determine a situation in which the use of the first method would be needed/desirable. Further, the use of "SHOULD" leaves unanswered the question of what are valid reasons to bypass the recommendation. The existing handling is not transferrable to other NFSv4. We need to do one of the following: - eliminate the use of method one. - provide an alternative the process in method 1 that does not depend on RFC3490. On Mon, Jul 25, 2022, 10:21 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote: Hi David, On Mon, Jul 18, 2022 at 01:05:25PM +0000, Noveck, David wrote: > > * draft-ietf-nfsv4-internationalization is now expired. In order to get it anywhere wglc, I have to address the issues in section 12. > > I haven't been able to get idna information from the working group or the internationalization people. Please provide viable sources on email. Ifno willing experts are to be found, will need to do further research and may have to update 7530 to not support idna, if that is possible. While I don't consider myself an internationalization person, I do know a few who would probably qualify. Please forgive my only sporadic attentiveness to this list -- is there a clean summary of the open issues that I could send to people and ask for help? Thanks, Ben _______________________________________________ nfsv4 mailing list nfsv4@ietf.org<mailto:nfsv4@ietf.org> https://www.ietf.org/mailman/listinfo/nfsv4 [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/nfsv4__;!!LpKI!gD1BRtFwwUpp8etNt74yc4T_v57MvYaRpGrXsWpU9X61X1wbdZB1UvN3ftbQldXRpIblsAw3UTPVR46uD3g8$>p
- [nfsv4] My probable non-participation in IETF114 … Noveck, David
- Re: [nfsv4] My probable non-participation in IETF… Benjamin Kaduk
- Re: [nfsv4] My probable non-participation in IETF… David Noveck
- Re: [nfsv4] My probable non-participation in IETF… Black, David
- Re: [nfsv4] My probable non-participation in IETF… Rick Macklem
- Re: [nfsv4] My probable non-participation in IETF… Black, David
- Re: [nfsv4] My probable non-participation in IETF… David Noveck
- Re: [nfsv4] My probable non-participation in IETF… David Noveck
- Re: [nfsv4] My probable non-participation in IETF… Chuck Lever III
- Re: [nfsv4] My probable non-participation in IETF… Chuck Lever III