Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

Tom Harrison <tomh@apnic.net> Wed, 17 June 2020 23:44 UTC

Return-Path: <tomh@apnic.net>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAF3A0CEB for <regext@ietfa.amsl.com>; Wed, 17 Jun 2020 16:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=apnic.net
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 i5v7-CRgC36H for <regext@ietfa.amsl.com>; Wed, 17 Jun 2020 16:44:08 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320043.outbound.protection.outlook.com [40.107.132.43]) (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 05BE83A0CE8 for <regext@ietf.org>; Wed, 17 Jun 2020 16:44:07 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XOc815AhKc3W5QPm54/lxwE1rmHHWWg72xOr7j00WFYxHRi45vL/eMuSAtW8L8CpCklZ6KKDnvNNpOlgegGFtUQUEAIY2D3xzuG7LWKCy9NSgHZSb7x0eSDk2QzpyOTFRzDlnnRHxS6d5tneFvbWhI+2jh5a6Ztf7EnKeFG5Oa/TQbtFyOWmE2mlqgA/Rlb62G+t0jKNHJlHV5hQrb6f9R317F4OTTo/X87GmtVUF9qfsIYO5Y/wrfgtmmU465OmrB10pz1/ycenOy7htIwiPL0/quNJMT3R2hkU9hqaGVslcF7jC2J+LWJHQoZsfnrLYocskcWh9GObkhgF55c10Q==
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-SenderADCheck; bh=e7zeOsdD0Ro7IbmO6dm1eOqECDczHEpJQJRoUrY6n3g=; b=E8NPOF7ZzlwMtf12dEENjVAkSLzyw/gSS7emcvchUvof6BBsGmq2NHhTQPmS4qwcHZc/9C+dVNm1kW7p7M5DSQjHDkDT4P+vP2qpZqzNOnd/viYt3elhjNB80Ac551DcNKjOQzKM9A/8RBcF7JVeFFUSK6+S1u5AH3H+27zT7lRbPchJWAo2vP4rmul+eRQSuaO/m2WU6FNuHHSJb3nuWHlZYYAXz1uivqJQ+a9atOsxXlgkbc51aetOO90IgAe5lQsZlPxA+N/gneuQxdGpop03nhhyYFOn9Ug1VuDhyJ/S+C9gUSvCJnAwv2W+n90u2UmQ8v6FyzE3twt/oJKdXw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=apnic.net; dmarc=pass action=none header.from=apnic.net; dkim=pass header.d=apnic.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e7zeOsdD0Ro7IbmO6dm1eOqECDczHEpJQJRoUrY6n3g=; b=CIl6M6VUQbpD7fkMi/ZZir6peGjqEZH4CaJcx5evJnfI6HvTAEvdIjq0/+VoZI8McLn6jn480jUjrk1ocjum8bgSrOZwJoiL/XnPW+yxjMD47geXdtv+3glQEzTDVEYN1ThTUKciwqL5bkTFfbsW1AahSZyAg8GP/YukKBG2lZA=
Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=apnic.net;
Received: from SG2PR04MB3000.apcprd04.prod.outlook.com (2603:1096:4:7a::9) by SG2PR04MB4091.apcprd04.prod.outlook.com (2603:1096:0:2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Wed, 17 Jun 2020 23:44:05 +0000
Received: from SG2PR04MB3000.apcprd04.prod.outlook.com ([fe80::ec05:eeab:9365:77d1]) by SG2PR04MB3000.apcprd04.prod.outlook.com ([fe80::ec05:eeab:9365:77d1%5]) with mapi id 15.20.3088.029; Wed, 17 Jun 2020 23:44:05 +0000
Date: Thu, 18 Jun 2020 09:44:00 +1000
From: Tom Harrison <tomh@apnic.net>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Message-ID: <20200617234400.GH27861@tomh-laptop>
Mail-Followup-To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
References: <159162988692.27209.10007278285596026415@ietfa.amsl.com> <ea6ab7f4-1540-0367-b3cb-b2abd2187752@iit.cnr.it> <5d79521690f0478fb51764fb90159538@verisign.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5d79521690f0478fb51764fb90159538@verisign.com>
X-ClientProxiedBy: SYBPR01CA0209.ausprd01.prod.outlook.com (2603:10c6:10:16::29) To SG2PR04MB3000.apcprd04.prod.outlook.com (2603:1096:4:7a::9)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (121.45.128.163) by SYBPR01CA0209.ausprd01.prod.outlook.com (2603:10c6:10:16::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Wed, 17 Jun 2020 23:44:05 +0000
X-Originating-IP: [121.45.128.163]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 8bb7813b-a73a-49cc-b3d5-08d813185259
X-MS-TrafficTypeDiagnostic: SG2PR04MB4091:
X-Microsoft-Antispam-PRVS: <SG2PR04MB409186BC891EB313D5798519C09A0@SG2PR04MB4091.apcprd04.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-Forefront-PRVS: 04371797A5
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: qZd/jO2OY95be6QkGRnbBJS+FXXKW03EtL2E/8mLgk7VqUw2K6IO15mCFkHg3gIKUOJdypwS76JrrsdPFEqtnuBPbggF4fpwn/Ictn0bpDySKDdhWoWb8VBnihS2U6nXI8SU1q84kw8oL4yQHHEGdem1j9RPtA0dc5fMRu6r2op8BNeYdzuuURaGbSu+DM0TCLPOqjUh12gFbpUJmGrtUkALxFtMD2lg1vR1SbOAfA9Az3aLTlejklkPkc4r5f3MPtkZVYcp+W5lVHBymd8ggdAh243IXcBtam9/AhNY4ll/2amDR5NPxn05zQhXCnMjezkCpMzQj0MXERoNIyEqYQ==
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR04MB3000.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(7916004)(136003)(376002)(39840400004)(346002)(366004)(396003)(316002)(2906002)(6486002)(66946007)(54906003)(6666004)(8676002)(66476007)(66556008)(86362001)(956004)(9686003)(8936002)(33656002)(186003)(16526019)(6496006)(4326008)(1076003)(508600001)(52116002)(5660300002)(26005)(33716001)(83380400001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: oPWXb/O0RMqDx66b53FfLlOs+Bth1C9zR/3V2h2hSvAVVcbPCrCYdsisNwjNJtXRe3slK5Hf4SpFxGg8LvRsFrQUlpFo/DsB8dmmfIopXKsVP23zemEwJI3n7JlSSwf+hpUPBX+XbXqPIAYlEaK0Bg8VO31IP0i05P0yT05abct/oRwQa81W2p2knL8NrCI7iLac5IrmhID0x0Ato7yvyGIzb63E3SstrWdc5UsKQ7zNRjgVemVv+xSESDlPUHjLPbckmgmPyjOIozCp1rhNtgaYRXw3CoR2RLiBMZk38i8n+rUutbhhIMwhMXfR+nZvYxLYrw7s/aKAe2gcB+jjX2mCpkZUBl2paOHt90BF+3SoRuUEYmQO+Bwfd/BMLmC1TlyPcHdVZP9W5xj1T9ZJY0lENO9KeZKBrzIi1T4dVXooJSoB/EgEErAjP8eKgpm4CsabGAVdbet1khp0jfwPPFl5iPFnLDNHFPnGZ59K0LgTvYWD6PlG+Bq9hNxnx4Cb
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 8bb7813b-a73a-49cc-b3d5-08d813185259
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Jun 2020 23:44:05.5667 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: TxuuCo53sC7fJJwjW6SjY7gU3pHtRktqGzA0fQhD4N6WQudhEFna/x//l7RLRAEP
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR04MB4091
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/8v8jW4G-feA3b4SfBZpdMM9v4wk>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 23:44:10 -0000

On Wed, Jun 17, 2020 at 01:23:45PM +0000, Hollenbeck, Scott wrote:
> From: regext <regext-bounces@ietf.org> On Behalf Of Mario Loffredo
>> 5) Section 4.4 - The following sentence  seems to be inconsistent
>> with the content of some figures (e.g. Fig. 15, 17, 23, ...) where
>> a "lang" element is included in jCard
>> 
>>    The "lang" attribute may appear anywhere in an object class or data
>>    structure except for in jCard objects.
>  
> [SAH] Agreed. I'll strike "except for in jCard objects".

The motivation for including "except in jCard objects" originally was
to make it clear that an implementor couldn't include the lang
attribute as defined in this section in a jCard object.  To preserve
that aspect while making it clear that the language-related content
defined in jCard may be used, I think the following would work better:

    The "lang" attribute as defined in this section may appear
    anywhere in an object class or data structure, except for in jCard
    objects.  To avoid any doubt, language-related tags and parameters
    defined by jCard itself may be used in jCard objects.

though the wording is a little awkward.    

>> 7) Section 10.2.3 - The definition of "last changed" event type
>> seems to be inconsistent with "upDate" defined in RFC
>> 5731,5732,5733. For example, I report an extract from RFC5731 here
>> in the following:
>> 
>>    -  An OPTIONAL <domain:upDate> element that contains the date and
>>       time of the most recent domain-object modification.  This element
>>       MUST NOT be present if the domain object has never been modified.
>> 
>> So, should we redefine the "last changed" event accordingly? Should
>> we change all the examples where "last changed" date is equal to
>> "registration" date?
> 
> [SAH] I think we can leave this one alone. The meaning seems clear
> to me since we also have the registration event. We could change the
> examples, but before I do that I'd like to know what people have
> implemented. Do servers return this value for an object that has
> been registered, but never updated?

We return this value for objects that have been registered, but not
updated, mainly because distinguishing these two dates in our systems
for some objects is non-trivial.  I think the current text supports
this approach, even given the presence of the 'registration' event
type (and regardless of whether those events are included in the
response), and that the current text is fine.  (We do intend to
include 'registration' events at some point, and would prefer to
continue including 'last changed' events alongside them even when the
values are the same, so that things continue to work as they did
previously for existing clients.)

-Tom