IETF Logo Mail Archive

Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt

Patrik Fältström <patrik@frobbit.se> Thu, 05 January 2012 06:49 UTC

Return-Path: <patrik@frobbit.se>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BCF21F87A5 for <provreg@ietfa.amsl.com>; Wed, 4 Jan 2012 22:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.309
X-Spam-Level:
X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTFHD58ZPXsW for <provreg@ietfa.amsl.com>; Wed, 4 Jan 2012 22:49:42 -0800 (PST)
Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB321F87A2 for <provreg@ietf.org>; Wed, 4 Jan 2012 22:49:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 573F712B714C7; Thu, 5 Jan 2012 07:49:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at frobbit.se
Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMJpAalDcoEZ; Thu, 5 Jan 2012 07:49:41 +0100 (CET)
Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 10C6D12B714C0; Thu, 5 Jan 2012 07:49:41 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Patrik Fältström <patrik@frobbit.se>
In-Reply-To: <CB2A85EE.20A23%michael@mwyoung.ca>
Date: Thu, 05 Jan 2012 07:49:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8DCAD5F-5774-4E63-8165-F3E25D8EFD85@frobbit.se>
References: <CB2A85EE.20A23%michael@mwyoung.ca>
To: MICHAEL YOUNG <michael@mwyoung.ca>
X-Mailer: Apple Mail (2.1251.1)
Cc: provreg@ietf.org
Subject: Re: [provreg] Domain check in draft-obispo-epp-idn-00.txt
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 06:49:42 -0000

On 5 jan 2012, at 04:44, MICHAEL YOUNG wrote:

> Sorry do you mean if you were designing this from scratch this is what you
> would do? Or do you mean this is how you read one of the existing
> proposals (and by that I mean any of the ones mentioned so far)?

If we designed epp from the beginning:

- We would not have the ability for registries to invent their own extensions without IETF review (i.e. like other protocols)

- We would have optimized a few of the commands (specifically create) so that it is closer to the business models

Example of the 2nd are all the registries that require delegation at time of registration (something that should be forbidden, but now some registries are like that), that required creation of contact objects and host objects before the domain object is created and glued together. If at that point in time the create fails, the creation of the other objects would have automatically been undone. Maybe as a transaction, I do not know. We should have thought about it harder.

  Patrik

> Michael
> 
> 
> 
> 
> On 12-01-04 10:34 PM, "Andrew Sullivan" <ajs@anvilwalrusden.com> wrote:
> 
>> On Wed, Jan 04, 2012 at 07:15:49PM -0500, Michael Young wrote:
>> 
>>> the use cases. Somewhere in all that I noted you were ok with the
>>> check ext being optional :-)
>> 
>> Actually, you misread, then.  I think servers (implementing this
>> extension) MUST support the extension to check.  Clients MAY send it
>> or not (which means that implementation is for practical purposes
>> optional for them.
>> 
>> Best,
>> 
>> Andrew
>> _______________________________________________
>> provreg mailing list
>> provreg@ietf.org
>> https://www.ietf.org/mailman/listinfo/provreg
> 
> 
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
>

v2.23.0 | Report a Bug | By Email