Re: [regext] Questions about RDAP extensions and registration at IANA, role of prefix and version

"Patrick Mevzek" <pm@dotandco.com> Thu, 23 January 2020 06:10 UTC

Return-Path: <pm@dotandco.com>
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 C10B812010E for <regext@ietfa.amsl.com>; Wed, 22 Jan 2020 22:10:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=NUaZu+YK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ir52JZ7c
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 A42XviW8xlqg for <regext@ietfa.amsl.com>; Wed, 22 Jan 2020 22:10:55 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3777A120108 for <regext@ietf.org>; Wed, 22 Jan 2020 22:10:55 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 68A3121FB5 for <regext@ietf.org>; Thu, 23 Jan 2020 01:10:54 -0500 (EST)
Received: from imap1 ([10.202.2.51]) by compute3.internal (MEProxy); Thu, 23 Jan 2020 01:10:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=3OqOqt5baWOtEAbI09xESIuGPMHr95h F0cfGa7QyOxw=; b=NUaZu+YKNUKG6Fm5sfw9CodiUcxqKHS+n63igrCjUHlIhyZ ud0soYWTMKO2EOW0qjOViugh5ds0DjPUc0xLVTiHmpJtbNMvel3eRXZjLcReA2GS 2YMIsW4J6uJQCy6QFG/c067rUtEaQUyiE0PsP/iADk4gWsJi9PuUbSk/T8BW7NQo UfmW4DhS16ndJwWf4eZ8JYbB8sWfpVOVNaBQcuRfuUT/XLTR5vHeBcPUH77kQsK/ xmsWyQ9cCtwdYnPrxixuWCP8cDxOMXEKlsY4DKz8XT8qza5aBVbbMCx8TAdJMvll R0nqmRjy3hhY6sBaVGg0lO1HLweNaT6C1CVuTuA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3OqOqt 5baWOtEAbI09xESIuGPMHr95hF0cfGa7QyOxw=; b=Ir52JZ7cfoDlDtDkyfy4u3 LL5OnFDwDsWjtxU8y9Evcy7Zo1aewnBx0xWva/FfJwZ+GAxDwjQ42WkGwS9NsJiA o0t6oWLAwZ1ZRLH9SCU0lK11n2Z9XLD5Ec3HTI51y3wNkhz9lyVKLDTXoaJmzDb6 mgeD9+2fbq4uoJjXAztVkmCOSebYgaC5yNGbvIPG3DqTWSvgu+V56o+1uOfK7rB1 0iCLlI4zcoVCCroFAC3dnwOfhInRPVfq1F/MAX4EjebDytk2YtA3/Wqb9d5xUYkr qOI05TFRNWVC+O6JLVjvBur0/k7XEbTcCbMrWATl/wmxzo4p36DKoSDl21NYFonQ ==
X-ME-Sender: <xms:7jgpXgdJuy1QqG8xoSs9nw2x3eB8y3ZKZrR14kb0J65BM5fZpU-EzTJPVmE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvddugdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmseguohht rghnuggtohdrtghomheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepphhmseguohhtrghnuggtohdrtghomh
X-ME-Proxy: <xmx:7jgpXvaWfvQf1LdGuxyJ369bA3HwKPmLR1Ix_5m-leDYt5lOkejy9A> <xmx:7jgpXqGYUulIGx2Mp0AAdPbt8crjN90zHuaYEshz6Bnxh6z_-3gyAA> <xmx:7jgpXllA85lbynwx6OKStudMOkzzVH0-r_hjdRaXBNPBlMt4csc0cw> <xmx:7jgpXlVY40-jVp39J-Rx1aSy56I_wl9W-MwPVjj0x2xR5JMkNHt9bg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 110DBC200A4; Thu, 23 Jan 2020 01:10:54 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-775-g74f2d12-fmstable-20200121v1
Mime-Version: 1.0
Message-Id: <f6fd0e19-eadd-4e2d-aef7-458fdc537821@www.fastmail.com>
In-Reply-To: <0851ad33353441189ae5d5b4baa3e9fa@verisign.com>
References: <cd67ca1a-febf-4304-afdb-e70b39026cd8@www.fastmail.com> <0851ad33353441189ae5d5b4baa3e9fa@verisign.com>
Date: Thu, 23 Jan 2020 01:10:32 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/xxfJ9gB7ymYtZvt3xo040fkLo3o>
Subject: Re: [regext] Questions about RDAP extensions and registration at IANA, role of prefix and version
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: Thu, 23 Jan 2020 06:10:57 -0000

Hi Scott,

On Thu, Nov 7, 2019, at 07:04, Hollenbeck, Scott wrote:
> Patrick, my expectation is that the value registered with IANA is the 
> exact value that should appear in an rdapConformance section. The 
> purpose of these values is to clearly identify an associated 
> specification, so one should be able to extract an identifier from an 
> RDAP response, look it up in the IANA registry, find an exact match, 
> and unambiguously identify the associated specification. We clearly 
> need to clean up this part of 7483 if/when we do 7483bis.

Thanks to have shared your views because indeed, due to the under specification,
I was thinking more about "prefix" registration than "exact match".

This would be good to address in some bis process, as the current situation
is clearly not ideal and is bound to become worse.

Note that related to that there is at least one EPP server out there
(in production for a real TLD) that gives this at greeting:

<objURI>urn:ietf:params:xml:ns:contact</objURI>
<objURI>urn:ietf:params:xml:ns:host</objURI>
<objURI>urn:ietf:params:xml:ns:domain</objURI>
<objURI>urn:ietf:params:xml:ns:svcsub</objURI>
<svcExtension>
  <extURI>urn:ietf:params:xml:ns:neulevel</extURI>
  <extURI>urn:ietf:params:xml:ns:secDNS-1.1</extURI>
  <extURI>urn:ietf:params:xml:ns:idn-1.0</extURI>
<svcExtension>


See the lack of version numbers in the schema URI provided,
but not for all of them :-).

This can be deemed a direct violation of the protocol,
but registrars still have to deal with it in some way.

-- 
  Patrick Mevzek
  pm@dotandco.com