Re: [regext] [Last-Call] Last Call: <draft-ietf-regext-epp-eai-10.txt> (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

[John C Klensin <[e-mail]>]

--On Wednesday, September 14, 2022 22:07 -0700 "Murray S.
Kucherawy" <[e-mail]> wrote:

> Rolling back the clock a bit here...
> 
> On Thu, May 26, 2022 at 11:11 AM John C Klensin
> <[e-mail]> wrote:
> 
>> First, it appears that it is making a more fundamental change
>> to EPP than just allowing for SMTPUTF8 (aka "non-ASCII" or
>> "EAI") addresses local parts.  The second paragraph of the
>> Introduction says
>>          "A new form of EPP extension, referred to as a
>>         Functional Extension, is defined and used..."
>> and Section 4 defines that mechanism.   Because there are
>> people who might look at an announcement of Last Call for an
>> internationalization-related extension and say either "someone
>> else will look at those complexities" or "oh, sure, non-ASCII
>> addresses are good", and move on, introduction of that new
>> type of extension should be highlighted in the Abstract and
>> should have been included in the Last Call so as to draw
>> attention from those who are, e.g., concerned about the
>> tradeoffs associated with adding complexity to EPP.

> Can you please elucidate a bit on what sort of callout you'd
> like to see in the Last Call for documents such as this in the
> future?  Or is it the case that the Abstract should've said
> something different and thus be automatically reflected in the
> Last Call?
> 
> I'm wondering if there's something the IESG should be
> adjusting here for future documents that touch this space.

I'm not sure because I think all of the needed mechanism are in
place if there is agreement about what we mean by "updates" (as
the IESG knows, a more basic problem).  From my perspective, the
problem (now eliminated with -16) is that,  if a base document
says, approximately, "there are three ways to extend this spec"
(as RFC 5730 does, see below), then an extension document that
says "here is extension method number four" should be shown as
updating that base spec.  How much it (or the Last Call
announcement) says beyond that is something of a judgment call.
Without going back and reviewing all of the rules, I think we've
required that updates be mentioned and described in the Abstract
and/or the body.  In this case, the update _is_ described even
though modifying the sentence quoted above to read more like
"STD  69 [RFC5730] defines three types of EPP extensions.  A
new, fourth, form of EPP extension, referred to as a Functional
Extension, is defined and used..." would have been more clear.

If a comment were not needed in the Abstract, then it would
probably be useful for the Last Call announcement to have said
"this updates RFC 5730 rather than just adding an extension to
it".

As I understand it, the position of the authors (with, I hope,
the knowledge and consensus of the WG) is that, because 5730 did
not say "there can only be three types of extensions" or
"extension types other than these three are forbidden forever",
this is not really an update and therefore does not have to be
shown as updating 5730, at least unless others decide to pick up
on the new mechanism in the future.   

I disagree because I see an extension to the list of extension
mechanisms as different from extensions that use (and cite) the
existing list of mechanisms. Had the WG, when 5730 was under
development, intended that it be possible to additional
extension mechanisms to be added without without modifying 5730,
then its Section 2.7, "Protocol Extension Framework" would read
something more like:

	"EPP provides an extension framework.  For example,
	features may to be added at the protocol, object, and
	command-response levels."

and we would have an EPP Extension Types registry, not just an
extensions registry.  That would replace the current text, which
reads:

	"EPP provides an extension framework that allows
	features to be added at the protocol, object, and
	command-response levels."

That text is the source of my "three types" comment.

There is an additional issue that I believe the IESG might
reasonably consider and decide whether some additional guidance
is needed (again, one that was discussed during that long
thread).  If there is a document that, like RFC 5730, says "here
is a list of extension types" ("levels" in the 5730 case) and a
new type is needed, I think it would be beneficial to the
community if that type were defined in a separate document
rather than embedded in the spec that uses it.  While I don't
see that as a firm requirement, a separate document would have
almost certainly encouraged the community to consider the type
of extension, whether it is needed, whether a mechanism for
adding extension types should be specified, etc.  In this case,
that change would have completely separated the issues
associated with a new extension mechanism from the EPP and
I18n/SMTPUTF8 aspects of this particular extension and, IMO,
simplified both discussions.  I do not consider that
question/issue to be moot because draft-ietf-regext-epp-eai has
now dropped the idea of adding a new mechanism.  Like the
"updates" one, the underlying issue of what sorts of things are
reasonably included in a single document and what should be
separated probably deserves consideration.

best,
   john

p.s. As I worked forward and back through this, I came to the
conclusion that there is probably an error of omission in RFC
7451.  Without that omission, the issues above are probably
fuzzier than I believe they should have been.  7451 does not
require that the type of extension (protocol, object, or
command-response) be identified in the registration application
and registry.  Had that requirement been in place, I believe
there would have been no ambiguity in the authors' minds about
whether or not the new extension type modified/updated 5730.  If
nothing else, had 7451 said "the type of extension must be
identified and it must be one of the following three values"
then this spec would have been dead in the water without
modifying 5730 and 7451.  If you would like an I-D to avoid this
type of problem in the future by making that change to 7451, I'd
be happy to whip one out.