IETF Logo Mail Archive

Re: [eppext] New draft for keyrelay available

Antoin Verschuren <ietf@antoin.nl> Thu, 05 February 2015 14:49 UTC

Return-Path: <ietf@antoin.nl>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E26C1A8848 for <eppext@ietfa.amsl.com>; Thu, 5 Feb 2015 06:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.185
X-Spam-Level:
X-Spam-Status: No, score=0.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 eX8Fa2vzIaNr for <eppext@ietfa.amsl.com>; Thu, 5 Feb 2015 06:49:46 -0800 (PST)
Received: from walhalla.antoin.nl (walhalla.antoin.nl [88.159.164.218]) by ietfa.amsl.com (Postfix) with ESMTP id E3B931A885D for <eppext@ietf.org>; Thu, 5 Feb 2015 06:49:42 -0800 (PST)
Received: by walhalla.antoin.nl (Postfix, from userid 5001) id 24CAB280813; Thu, 5 Feb 2015 15:49:42 +0100 (CET)
Received: from [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2] (unknown [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id CA2C7280345 for <eppext@ietf.org>; Thu, 5 Feb 2015 15:49:39 +0100 (CET)
From: Antoin Verschuren <ietf@antoin.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_097F4798-3A6F-4A7C-B7E0-0D499A31D572"; protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <A7557B58-74DA-44EC-96FB-26576A14CD24@antoin.nl>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Date: Thu, 5 Feb 2015 15:49:37 +0100
References: <C80127C588F8F2409E2B535AF968B768B927CDA8@kambx2.SIDN.local> <0ED7237B-F4E8-45D7-971F-1625350DB0FC@verisign.com> <C80127C588F8F2409E2B535AF968B768B9280B52@kambx2.SIDN.local> <472EF001-1A03-4C50-A7DB-3D6B766B3BA8@verisign.com> <20150119094734.GA27180@miek.nl> <AF040383-7DED-4DDA-A52A-F40978697DF9@dnsbelgium.be> <C80127C588F8F2409E2B535AF968B768B9285C2F@kambx2.SIDN.local> <831693C2CDA2E849A7D7A712B24E257F49F33387@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <46F2F7EA-7FD4-4D47-B80D-CCC795277512@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F3353E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <ABCBA930-3045-438C-A526-B6B824390048@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F338CE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <C80127C588F8F2409E2B535AF968B768B928BC13@kambx2.SIDN.local> <831693C2CDA2E849A7D7A712B24E257F49F33CD7@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <9DA4482A-EF0F-4D66-A941-9472F16403E3@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33D6D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <6BA91560-54! 25-4BAC -A 17A-25D13EF88A8F@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F33F4C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <BF69A00E-EBD5-435A-8BF5-1C77A44E4545@verisign.com> <831693C2CDA2E849A7D7A712B24E257F49F34147@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <AF85EB99-3250-4BBD-9106-59400D8AF911@antoin.nl> <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
To: "eppext@ietf.org" <eppext@ietf.org>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3AFB9@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/9SecmvRuUFgSllsg08cWdYZt0jk>
Subject: Re: [eppext] New draft for keyrelay available
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2015 14:49:47 -0000

Like I said, I believe the <relay> command falls into a 4th category of EPP commands which I'd like to call "Communication Commands” or "Transient Commands” (name to be discussed).
So we will have session management commands, query commands, object transform commands and communication commands.
We didn’t see the need for this category back then. That is the innovative idea of relay.
Communication commands don’t touch objects, so there is no risk of inconsistency in the registry.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392
xmpp:antoinverschuren@gmail.com




Op 5 feb. 2015, om 14:16 heeft Hollenbeck, Scott <shollenbeck@verisign.com> het volgende geschreven:

>> -----Original Message-----
>> From: Antoin Verschuren [mailto:antoin@antoin.nl]
>> Sent: Thursday, February 05, 2015 7:45 AM
>> To: Hollenbeck, Scott
>> Cc: Gould, James; Rik Ribbers; Miek Gieben; Maarten Bosteels;
>> eppext@ietf.org
>> Subject: Re: [eppext] New draft for keyrelay available
>> 
>> Scott,
>> 
>> What do you considder a duplication?
> 
> The exact same message being sent or received more than once. This introduces a risk of inconsistency between client and server if there isn't a way to provide command idempotency, which is one of the reasons I prefer an approach that involves creating a transient object. Note that Section 2 of RFC 5730 includes this statement about EPP commands:
> 
> "EPP commands fall into three categories: session management commands, query commands, and object transform commands."
> 
> Which of these categories does the <relay> command fall into? The draft describes it as a "transient" command, and there's no mention of "transient" commands in 5730.
> 
> Scott

v2.8.7 | Report a Bug | By Email