Subject: [regext] Picking XML namespaces

From: Martin Thomson <[email-masked]>
Date: Sun, 4 Nov 2018 12:38:48 +0700

Folks,

I'm seeing an increase in EPP registrations for the XML namespace and
schema registries.

In the past, the names this group have selected are quite generic.

I would like to request that this group include a label in the names
that it uses.  Other users of these registries carefully scope the
names they use to avoid conflict, but this group has not done that.

I realize that there is an established pattern here that would need to
change, which is a little disruptive, but I think that it would be
respectful to other users of the registry to start using scoped names
for new registrations.

That is, in the most recent document I've been asked to review:

urn:ietf:params:xml:ns:changePoll-1.0

becomes

urn:ietf:params:xml:ns:epp:changePoll-1.0

And future documents follow the same pattern.  This is consistent with
other uses of this registry.

---

From: "Gould, James" <[email-masked]>
Date: Sun, 4 Nov 2018 11:49:12 +0000

Martin,

I was involved with the namespace feedback with the launch phase extension.  The agreement was to scope the namespaces for new extensions going forward if there was not a negative impact.  The org, orgext, and fee extensions that are going through the IESG now can support the scoping without impact, and have been scoped. The scoping of the namespace for changepoll does have a negative impact, so I am requesting to move forward with the urn:ietf:params:xml:ns:changePoll-1.0 namespace.

Thanks,

Jim

Sent from my iPhone

> On Nov 4, 2018, at 1:39 AM, Martin Thomson <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Nov 2018 08:54:12 +0700

On Sun, Nov 4, 2018 at 6:49 PM Gould, James <[email-masked]> wrote:
> The scoping of the namespace for changepoll does have a negative impact,

Hi James,

Can you substantiate this claim?  Understand that I am not familiar
with the work here.

---

From: "Gould, James" <[email-masked]>
Date: Mon, 5 Nov 2018 05:29:30 +0000

Martin,

Yes, there are Production systems in place that use this namespace.  Scoping the namespace at this stage would cause Production interoperability issues.  Let me know if you need any additional information.

Thanks,

Jim

Sent from my iPhone

> On Nov 5, 2018, at 8:54 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 06 Nov 2018 06:17:13 +0100

On Mon, Nov 5, 2018, at 06:29, Gould, James wrote:
> Yes, there are Production systems in place that use this namespace.  
> Scoping the namespace at this stage would cause Production 
> interoperability issues.  Let me know if you need any additional 
> information.

I completely disagree with this reasoning, irrespective of the specific document as I would say the same thing for the same case.

This is only a draft, implementations are bound to change.
As a developer myself, I implemented a lot of drafts in their early versions, for "free" and it would have been the same thing for "just" namespaces changes. So I can totally understand the difficulty to change things at the last time, but then it is the game to play if we want global standards, their limits and edge cases appear when they are really implemented (hence the Implementation Status section in documents), and hence implementations are bound to need updates when the standard "matures"  and gets input from other parties.

Current deployments should not forbid making the document better and hence creating at the end a better standard for everyone.

If we do otherwise we just re-inforce something that I am seeing more and more which is converting this working group as a pure rubberstamping "authority"  were documents come already finished or close to finished or not really open to changes because it won't suit the original author.

It would be then too easy for anyone to come and then just refuse changes because it is already deployed as is.

Also, it was always sold that the greeting+login exchange enables client and server to autonegiotate extensions, including those that change the namespace (like the fee one with many different namespaces - even if just different on the version part - and many registries today exposing more than one).

Now what I can agree on is why setting the line at this document instead of any other one?
As soon as we have identified a problem regarding the namespaces used, I think all documents not yet being an RFC should be modified to adhere to the new convention. I see no sensible reason to say to do it for some but not others.

So my opinion is to change the namespace everywhere and not let any new extenson become an RFC without this change.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 6 Nov 2018 06:08:43 +0000

Patrick,

Thank you for your viewpoint on this.  I agree with you in theory but I disagree with you in practice. The EPP RFCs that exist today don't include any form of epp scoping, so the inflight extensions are simply following that pattern.  The request from IANA to scope the namespaces, that was first raised with draft-ietf-regext-launchphase, should be and is being incorporated.  Examples include draft-ietf-regext-org, draft-ietf-regext-orgext, draft-ietf-regext-epp-fees, draft-ietf-regext-allocation-token, draft-ietf-regext-bundling-registration, and the new extensions, that now include the epp namespace scoping.  We do need to be careful to also consider the impact of making a change against following a new scheme.  In the case of draft-ietf-regext-launchphase that became RFC 8334, draft-ietf-regext-change-poll, and in the future draft-ietf-regext-verificationcode, the operational impact was and is too high in making the namespace change.  I believe that there needs to be a compelling reason to make the change, such as an IANA namespace conflict, to justify making the namespace change on extensions that will have operational impact.  I understand the method for supporting namespace changes on the client-side and the server-side, but the production and interoperability impacts need to be considered when incorporating a new scheme.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

Verisign.com <http://verisigninc.com/> 

On 11/6/18, 12:17 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 06 Nov 2018 07:52:18 +0100

On Tue, Nov 6, 2018, at 07:08, Gould, James wrote:
>
> I believe that there needs to 
> be a compelling reason to make the change, such as an IANA namespace 
> conflict, to justify making the namespace change on extensions that will 
> have operational impact. 

As far as I know there is no real conflict whatsoever for any of the current XML namespaces used by every draft on EPP extensions, so by this same argument
(since multiple other documents could be said as already implemented "somewhere"
and hence having an operational impact for at least one actor)
you could arrive at the conclusion that not a single document we have on the table should be updated regarding the namespace it uses.

Also by the same single argument, any draft that kind of have an Implementation Status may be said to be operational in some way by some actor and hence any single change in it could be rebuffed by saying "We can not change it, it is operational already".

And I would still disagree.

Like I said, I believe that most arguments there could be used in the same way for any
of the documents, so they should apply uniformly. Either no document is updated in that regard or all are, whether they are already implemented somewhere or not.

But after having expressed my concerns, I will not push further on this and just remain in agreement with Martin's first message on the issue.

-- 
  Patrick Mevzek
  [email-masked]