Re: [eppext] FW: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"

Patrick Mevzek <pm@dotandco.com> Tue, 07 April 2015 13:56 UTC

Return-Path: <patrick@shaktot.patoche.org>
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 0FD701B35DB for <eppext@ietfa.amsl.com>; Tue, 7 Apr 2015 06:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, 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 ZaoBdGYI-_MH for <eppext@ietfa.amsl.com>; Tue, 7 Apr 2015 06:56:43 -0700 (PDT)
Received: from shaktot.patoche.org (shaktot.patoche.org [212.85.152.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1C61B35DC for <eppext@ietf.org>; Tue, 7 Apr 2015 06:56:42 -0700 (PDT)
Received: from shaktot.patoche.org (localhost.localdomain [127.0.0.1]) by shaktot.patoche.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t37DuVfZ017131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Apr 2015 15:56:32 +0200
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id t37DuVdV017130; Tue, 7 Apr 2015 15:56:31 +0200
Date: Tue, 7 Apr 2015 15:56:31 +0200
From: Patrick Mevzek <pm@dotandco.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Message-ID: <20150407135631.GA32612@home.patoche.org>
References: <RT-Ticket-814918@icann.org> <A973DE55-D717-4973-9C8B-733CF04742DD@verisign.com> <rt-4.2.9-2033-1427129077-1113.814918-9-0@icann.org> <831693C2CDA2E849A7D7A712B24E257F49F89B7A@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F89B7A@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Scanned-By: shaktot_dot_patoche_dot_org on 212.85.152.86
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/YJv8IdXOK0Y1ifzV1ejubuy5UBk>
Cc: "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] =?utf-8?b?Rlc6IFtJQU5BICM4MTQ5MThdIElOU0VSVCDigJxFeHRl?= =?utf-8?q?nsible_Provisioning_Protocol_Mapping=3A_Suggestion=22?=
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: Tue, 07 Apr 2015 14:24:05 -0000

Hello,

I've stumbled upon something, maybe irrelevant, maybe interesting in
general for the WG.

The PDF quoted has a "Version 1.4" in preamble with also a nice summary
at beginning with differences for each version.
However the namespace is 
http://www.verisign-grs.com/epp/suggestion-1.1

Does that mean that the document changed without a change in namespace
version?
Or that the 1.1 namespace version was published after version 1.4 of the
document?

To be more generic, if not done already, shouldn't the WG eventually
give some guidance to authors and/or mandate a change of namespace
version when documentation does change? With some related issues:
- what for simple bugfixes or erratas?
- what if the server/client behaves in practice differently from what
  was documented?
- also, should the WG discuss how to handle transitions from one
  version to another?
I'm aware of specific cases in the past, like for example a switch
from one version to another where the server was allowing either one,
of course with different capabilities…
(this also creates the problem of namespace in polling messages… what
is they are retrieved by registrar long after the fact, hence the
namespace does not exist anymore or if the registrar did not choose
the given namespace at login, should he still get it in its polling
message?)

Hollenbeck, Scott <shollenbeck@verisign.com> 2015-03-23 19:05
> Submitted for DE evaluation.
> 
> Scott
> 
> -----Original Message-----
> From: Amanda Baber via RT [mailto:iana-prot-param-comment@iana.org] 
> Sent: Monday, March 23, 2015 12:45 PM
> Cc: Hollenbeck, Scott
> Subject: [IANA #814918] INSERT “Extensible Provisioning Protocol Mapping: Suggestion"
> 
> #11 of 18.
> 
> -----BEGIN FORM-----
> Name of Extension:
> “Extensible Provisioning Protocol Mapping: Suggestion"
> 
> Document Status: 
> Informational
> 
> Reference: 
> http://www.verisigninc.com/assets/epp-sdk/EPP-Suggestion-Mapping.pdf
> 
> Registrant Name and Email Address:
> VeriSign Inc., epp-registry@verisign.com
> 
> TLDs: Any
> 
> IPR Disclosure: None
> 
> Status: Active
> 
> Notes: None
> -----END FORM-----
> 
> —
> 
> 
> JG
> 
> 
> 
> 
> 
> James Gould
> Distinguished Engineer
> jgould@Verisign.com
> 
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
> 
> VerisignInc.com
> 
> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”
> 
> Download BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png
> 
> image/png 4KiB
> Image not shown because display is disabled in system configuration.
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext

-- 
Patrick Mevzek
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.  -- George Bernard Shaw