[regext] Fwd: Re: WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03
Hi authors, I provided feedback but I haven't received any response yet, but never mind. I note that both the points were addressed by either version 04 or the reply to James's feedback. Best, Mario Messaggio Inoltrato Oggetto: Re: [regext] WG LAST CALL: draft-ietf-regext-epp-registry-maintenance-03 Data: Mon, 5 Oct 2020 14:54:32 +0200 Mittente: Mario Loffredo A: James Galvin , regext@ietf.org Hi all, I have a couple of comments about this document: 1) Don't understand which maintenance notifications should be returned by an info command including the element. I mean, only those about both ongoing and future events or also about past events? In the latter case, could it be helpful to add optional attributes to the element which allow clients to specifiy a preferred time interval? For example, "createdAfter" and "createdBefore". 2) The document makes no assumption on which child elements should be presented in the response to an info request including the element. However, the example in section 3.1.3 seems to suggest that servers should return a subset of the full information. Should the document define the minimum information which servers are required to provide and clients could expect? Best, Mario Il 02/10/2020 22:57, James Galvin ha scritto: The following working group document is believed to be ready for submission to the IESG for publication as a standards track document: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ This WG last call will end at close of business, Friday, 16 October 2020. Please review this document and indicate your support (a simple “+1” is sufficient) or concerns with the publication of this document by replying to this message on the list. The document shepherd for this document is James Galvin. Regards, Antoin and Jim ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext -- Dr. Mario Loffredo Systems and Technological Development Unit Institute of Informatics and Telematics (IIT) National Research Council (CNR) via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Mobile: +39.3462122240 Web: http://www.iit.cnr.it/mario.loffredo ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03
On Thu, Oct 22, 2020, at 08:47, Gould, James wrote: > I do need to clarify one > thing, there was no specific changes needed on the client-side to > support draft-ietf-regext-unhandled-namespaces other than ensuring that > the draft-ietf-regext-unhandled-namespaces XML namespace is included in > the login services. There was no specific changes needed on the client-side... for YOUR client. Great for you, but from that you can not draw a conclusion that your draft creates no problem whatsoever. Please take into account there are other clients out there, that may work differently and do different assumptions. Your draft changes the assumptions in RFC 5730. And hence may break existing clients. By saying that there was no problem for one client is not a proof that interoperability was not broken. > Clients should be capable of parsing and marshaling the > element regardless of whether or not > draft-ietf-regext-unhandled-namespaces is supported. This is unrelated. You are changing the text from RFC 5730 that says explicitly this content is client provided. You are now redefining what is in RFC 5730 by saying "any content is fine here". > The > approach taken with draft-ietf-regext-unhandled-namespaces enables the > information to be returned without the chance of breaking a validating > client that doesn't support the service, This is untrue, as you change the semantics of RFC 5730 at least twice (content of extValue, and possibly having value/extValue with NON error codes) Your draft *clearly* creates a _risk_ for any existing client starting to break once a server enables this feature. Saying that one client works fine is not a measure of interoperability risks when it is deployed. -- Patrick Mevzek p...@dotandco.com ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Internationalized Email Addresses and EPP
Hello all,
Otion 1 is ideal and option 2 are reasonable.
Since not many registries and registrars support EAI services and few
registrants use EAI address in the near future, I think that option 2 might be
the current direction.
Best Regards
Jiankang Yao
From: Barry Leiba
Date: 2020-10-19 17:48
To: Hollenbeck, Scott
CC: art-...@ietf.org; regext@ietf.org
Subject: Re: [regext] Internationalized Email Addresses and EPP
Hi, Scott,
An interesting question...
I think it depends upon how you want this to appear from an EPP point of view:
1. Do you want the EPP standard to support non-ASCII email addresses?
2. Do you want to *extend* EPP to support non-ASCII email addresses,
as an option for those who implement the extension?
For (2), then the EPP extension would be the easiest option, where the
extension would "update" 5733 and say that the extension changes the
definition to allow non-ASCII email addresses. The extension would be
at Proposed Standard, and 5733 would be at Internet Standard as it is
now.
For (1), the best way would be to revise 5733 and change the
definition of email address syntax, republishing it at Proposed
Standard and "obsolete" 5733. The protocol (the new RFC) would then
be back at Proposed Standard. You could then do a status change later
to move the new RFC to Internet Standard (without publishing yet
another revision).
So... does the working group want it to appear that support for
non-ASCII email addresses is an optional extension, or part of the
base EPP?
Barry
On Wed, Oct 14, 2020 at 7:54 AM Hollenbeck, Scott
wrote:
>
> Barry, Murray:
>
> We have a question about IETF process as it related to updating an Internet
> Standard document. RFC 5733 ("Extensible Provisioning Protocol (EPP) Contact
> Mapping", part of Standard 69) was published in August 2009. It includes a
> normative reference to RFC 5322 for the definition of email address syntax.
> RFC 6530 ("Overview and Framework for Internationalized Email") was published
> in 2012. The regext working group is discussing how we can best update the
> email address syntax specification in RFC 5733 to add support for the local
> part of internationalized email addresses to EPP. The EPP XML Schema already
> "works" as it should, so that doesn't need to change. It's just that pesky
> normative reference to RFC 5322 that isn't updated by RFC 6530. We think we
> have a couple of options:
>
> Create an EPP extension by writing an Internet-Draft that would explicitly
> add support for internationalized email address without touching anything
> associated with 5733.
>
> Write another document that updates 5733 to include the reference to 6530, if
> it's possible to update an Internet Standard that way.
>
> Submit an errata report to note the additional normative reference to 6530,
> though this isn't a technical or editorial error.
>
> There may be other possibilities. What are your thoughts on the best way to
> proceed? I personally think that the first option is the easiest and
> cleanest, and it's the way we've added additional functionality in the past.
> I'm wondering if there's an easier way, though.
>
> Scott
>
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
