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

["Gould, James" <[e-mail]>]

Yes, a specification can be updated with a new version without requiring a change to the XML schema or the namespace.  Text changes occur more frequently to XML schema changes.  Backward compatible XML schema changes occur more frequently to non-backward compatible changes that may require bumping the namespace version.  It has been common practice to not change the namespace for I-D mappings and extensions, as was the case for the draft versions of the EPP RFC’s, and the draft versions of the DNSSEC extension (RFC 5910) once the namespace was set.  Gavin has taken a different approach to the registry fee extension, where the namespace changes for each change to the XML schema in the draft; although the namespace will not change with every change to the draft.  For our custom extensions, we attempt to keep all changes backward compatible so that existing client implementations don’t break.  I-D's are little bit more challenging to control the impact of changes, since they are community driven.  Draft and namespace versioning strategies are certainly something worth a discussion to come up with a best practice.  Poll messaging is even more interesting in how to introduce new poll messages, that may or may not be implemented by clients, without breaking the protocol by sending poll messages that are not included in the login services of the client.


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Apr 7, 2015, at 10:07 AM, Hollenbeck, Scott <[e-mail]<mailto:[e-mail]>> wrote:

Jim Gould can address the specific question about version numbering for this particular extension, but yes, it's entirely possible for a document to change (necessitating a change in a document version number) without the XML Schema and/or namespace version number changing.

Scott

-----Original Message-----
From: Patrick Mevzek [mailto:[e-mail]]
Sent: Tuesday, April 07, 2015 9:57 AM
To: Hollenbeck, Scott
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] FW: [IANA #814918] INSERT “Extensible
Provisioning Protocol Mapping: Suggestion"

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 <[e-mail]> 2015-03-23 19:05
Submitted for DE evaluation.

Scott

-----Original Message-----
From: Amanda Baber via RT [mailto:[e-mail]]
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., [e-mail]

TLDs: Any

IPR Disclosure: None

Status: Active

Notes: None
-----END FORM-----

—


JG





James Gould
Distinguished Engineer
[e-mail]

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
[e-mail]
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
_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext