Re: [regext] Internationalized Email Addresses and EPP

[Barry Leiba]

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

Re: [regext] proposed topics for IETF109 meeting

[James Galvin]

In case you haven’t noticed, our meeting has been scheduled for two 
hours on Wednesday, 18 November 2020, at 1200 UTC+7.


We are scheduled against the following currently:

Room 1	art	dmarc	Domain-based Message Authentication, Reporting & 
Conformance

Room 2  art regext  Registration Protocols Extensions
Room 3	int	madinas	MAC Address Device Identification for Network and 
Application Services  BOF

Room 4  ops netconf Network Configuration
Room 5  rtg bierBit Indexed Explicit Replication
Room 6  rtg spring  Source Packet Routing in Networking
Room 7	sec	ace		Authentication and Authorization for Constrained 
Environments

Room 8  tsv quicQUIC

Mark your calendar!

Jim



On 16 Oct 2020, at 17:46, James Galvin wrote:

Recall that we only requested a 1 hour meeting for IETF109.  At the 
time we had to submit the request we didn’t have too many agenda 
topics.  The list has grown since then so it’s going to be a bit 
tight it seems.  Nonetheless, we’ll make it work.


Here is the list we have so far.

* Joseph Yee - simple registration reporting
* Mario Loffredo - reverse search
* Mario Loffredo - jcard deprecation
* Jody Kolker - unrenew command in EPP
* Dmitry Belyavsky - EAI in EPP

Let me know if I’ve missed anything, or if there is something else 
you want to add.


The draft IETF agenda is supposed to be out today so we’ll be able 
to see when our meeting is during the week.  Note too that as of the 
time of this message there’s only a couple hours left on the early 
bird registration fee.  Be sure to register and pay if you haven’t 
already.


Thanks!

Jim


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] WG LAST CALL: draft-ietf-regext-unhandled-namespaces-03

[Gould, James]

Patrick, 

Thank you for your thoughts and feedback.  I provide responses to your feedback 
embedded below.

-- 

JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 

On 10/18/20, 10:07 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Fri, Oct 2, 2020, at 15:52, James Galvin wrote:
> The following working group document is believed to be ready for 
> submission to the IESG for publication as a standards track document:
> 
> 
https://secure-web.cisco.com/119Z6-9QCgolQ6IIOiTngyTDdKf1s3AaRBIxnoSkXH2U85ZP_AkwLkWZxbHfpOCtj0tOQgqGMA93ErjU_nX7UNe_uUkyJYV_6Do7PdfWfcCAJN7TaogAr1ErpuD8biWr-C7ZDwU0xROsE8h7FxzV3D01y4QmoAeeHGbG50UKbC7oFagBzR2dKXS3hv5-bVdXWwa2fkdW0SIVjPB3nL4n9CL6n1rTU5r0Z7PdqAUhJyS8zLeWg5leNiOHa686p1RLAFGuREUj-R-e-bziJjAlgVw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-unhandled-namespaces%2F

This specification will create interoperability problems as drafted.

Even if the server announces this extension, all current clients not knowing
about it will have this new behavior forced on them,
which contradicts what RFC 5730 says (see below).
So the mechanism should be that the server does not enable this behavior
until having explicit acknowledgement by the client that it is ok to do so.

Considering a default opt-in puts all currently existing EPP clients at 
risk.

JG - draft-ietf-regext-unhandled-namespaces addresses an interoperability issue 
with the server returning extensions that the client specified is not 
supported.  The  element is already a feature supported by RFC 5730, 
so this is not something "forced on them".  Consider the poll queue scenario, 
where the server does not know what the client supports when inserting the 
message, but will only know when the client consumes the message later.  When 
asking for the poll message, should the server violate RFC 5730 by returning 
the message that contains an extension the client did not explicitly include in 
the login services?   draft-ietf-regext-unhandled-namespaces provides an option 
to return the poll message without violating RFC 5730 based on what's specified 
in the login services using an existing protocol feature.  This is not a new 
feature from a protocol perspective that will cause an interoperability issue.  

Especially since this specification redefines what is in RFC 5730,
which says:
Zero or more OPTIONAL  elements that can be used to
 provide additional error diagnostic information, including:

 *  A  element that identifies a client-provided element
(including XML tag and value) that caused a server error
condition.

Note the "client-provided element" and compare to this example
in the draft:
S:  
S:
S:  
S:example.com
S:pending
S:ClientX
S:2000-06-06T22:00:00.0Z
S:ClientY
S:2000-06-11T22:00:00.0Z
S:2002-09-08T22:00:00.0Z
S:  
S:


 was not client-provided, yet it is in extValue > value 
node.
(so an existing client sticking to RFC5730 may see this content and believe
it has made an error, and not understanding anything about the content
provided since it is not at all a content coming from it, the client).

It is also not really a "server error condition".

The value/extValue of RFC 5730 have been stretched out as of their use
in so many proprietary extensions, that I do not think it is a good
idea to have  standard even doing that.

JG - Yes, the  is not being used for an client-side error condition 
in this use case and will not return client-side elements.  The  is 
being used to indicate what response extensions could not be returned in their 
standard location due to lack of support by the client.  There is no normative 
language in RFC 5730 that would prohibit the use of  for the use case 
covered in draft-ietf-regext-unhandled-namespaces.   

Going deeper, it is not even clear if RFC 5730 allows really a return code 
of
success but still have value/extValue nodes. There may be nothing at it 
in the schema, but the text says:

Success and failure results
   MUST NOT be mixed.
[..]

Zero or more OPTIONAL  elements [..] that caused a server error 
condition.

Zero or more OPTIONAL  elements that can be used to
 provide additional error diagnostic information

Note how both nodes are specifically tied to "errors".


There may be clients out there that will consider value/extValue only for 
error
return codes (>=2000) and will get confused when getting back 1000 but with 
extValue
as this draft calls for.

JG - RFC 5730 did not envision this case, which is the point with the 
standardization of draft-ietf-regext-unhandled-namespa

Re: [regext] Internationalized Email Addresses and EPP

[Gould, James]

I believe option 2 is the better route to go.  We went with option 2 to extend 
the password length in RFC 5730 with the Login Security Extension (RFC 8807).  
The use of email addresses in EPP is not isolated to RFC 5733.  The 
Organization Mapping (RFC 8543) and some additional EPP mappings registered in 
the EPP Extension Registry (Email Forwarding Mapping and NameWatch Mapping) use 
email addresses.  A new EPP extension could be applied to more than one EPP 
mapping.  The other question is whether the Internationalized Email Address 
should be a replacement for or additive to the ASCII Email Address defined in 
the mappings, based on the email address usage and the support for 
Internationalized Email Addresses in the underlying protocols and 
implementations.  An extension could support both replacement and additive 
options.   

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 

On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" 
 wrote:

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://secure-web.cisco.com/1OMe-gZOMpSdaE_x-eNaMmuku-HiFkDXVCFGDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Dmitry Belyavsky]

Let me disagree...

Login Security Extension does much more than just increasing the password
length.
Going(2) means that EAI addresses are not first-class citizens, that seems
wrong for now.
Also, the current schema definition formally allows EAI addresses.

On Mon, Oct 19, 2020 at 7:23 PM Gould, James  wrote:

> I believe option 2 is the better route to go.  We went with option 2 to
> extend the password length in RFC 5730 with the Login Security Extension
> (RFC 8807).  The use of email addresses in EPP is not isolated to RFC
> 5733.  The Organization Mapping (RFC 8543) and some additional EPP mappings
> registered in the EPP Extension Registry (Email Forwarding Mapping and
> NameWatch Mapping) use email addresses.  A new EPP extension could be
> applied to more than one EPP mapping.  The other question is whether the
> Internationalized Email Address should be a replacement for or additive to
> the ASCII Email Address defined in the mappings, based on the email address
> usage and the support for Internationalized Email Addresses in the
> underlying protocols and implementations.  An extension could support both
> replacement and additive options.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgo...@verisign.com
> 
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com 
>
> On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" <
> regext-boun...@ietf.org on behalf of barryle...@computer.org> wrote:
>
> 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://secure-web.cisco.com/1OMe-gZOMpSdaE_x-eNaMmuku-HiFkDXVCFGDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> ___

Re: [regext] Internationalized Email Addresses and EPP

[Mario Loffredo]

+1 for (1).

Best

Mario

Il 19/10/2020 11:48, Barry Leiba ha scritto:

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


--
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

Re: [regext] Internationalized Email Addresses and EPP

[Gould, James]

Dmitry,

The primary driver around the Login Security Extension was to increase the 
password length, where the other features were additive.  Going (2) means that 
the EAI addresses are first-class citizens that can be applied more broadly 
than RFC 5733 and for a broader set of use cases and to take into account the 
support for Internationalized Email Addresses in the underlying protocols and 
implementations.  I agree that the XML schema of the EPP mappings support EAI 
addresses, but the issue is how to implement EAI addresses to satisfy the use 
cases of the various EPP mappings that exist (e.g., RDAP/WHOIS display, 
Registrar usage, or in support for a Registry Service).  I view (2) as being 
the best path to support EAI addresses in EPP.

--

JG

[cid:image001.png@01D6A61C.AB84CAB0]

James Gould
Fellow Engineer
jgo...@verisign.com

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

Verisign.com

From: Dmitry Belyavsky 
Date: Monday, October 19, 2020 at 12:50 PM
To: James Gould 
Cc: "barryle...@computer.org" , "Hollenbeck, Scott" 
, "art-...@ietf.org" , 
"regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP

Let me disagree...

Login Security Extension does much more than just increasing the password 
length.
Going(2) means that EAI addresses are not first-class citizens, that seems 
wrong for now.
Also, the current schema definition formally allows EAI addresses.

On Mon, Oct 19, 2020 at 7:23 PM Gould, James 
mailto:40verisign@dmarc.ietf.org>> 
wrote:
I believe option 2 is the better route to go.  We went with option 2 to extend 
the password length in RFC 5730 with the Login Security Extension (RFC 8807).  
The use of email addresses in EPP is not isolated to RFC 5733.  The 
Organization Mapping (RFC 8543) and some additional EPP mappings registered in 
the EPP Extension Registry (Email Forwarding Mapping and NameWatch Mapping) use 
email addresses.  A new EPP extension could be applied to more than one EPP 
mapping.  The other question is whether the Internationalized Email Address 
should be a replacement for or additive to the ASCII Email Address defined in 
the mappings, based on the email address usage and the support for 
Internationalized Email Addresses in the underlying protocols and 
implementations.  An extension could support both replacement and additive 
options.

--

JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 
>

On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" 
mailto:regext-boun...@ietf.org> on behalf of 
barryle...@computer.org> wrote:

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
mailto:shollenb...@verisign.com>> 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 "w

Re: [regext] Internationalized Email Addresses and EPP

[John Levine]

In article <95c042c2-e77b-6f92-acb6-4a35663b1...@iit.cnr.it> you write:
>+1 for (1).

>> 1. Do you want the EPP standard to support non-ASCII email addresses?

Do we believe that every registry that supports EPP can handle UTF-8
addresses? If not, what happens when a regstrar sends a UTF-8 address
to a registry that can't handle it?

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

[regext] [Technical Errata Reported] RFC8521 (6310)

[RFC Errata System]

The following errata report has been submitted for RFC8521,
"Registration Data Access Protocol (RDAP) Object Tagging".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6310

--
Type: Technical
Reported by: Scott Hollenbeck 

Section: 4

Original Text
-
RDAP responses that contain values described in this document MUST
   indicate conformance with this specification by including an
   rdapConformance [RFC7483] value of "rdap_objectTag_level_0".  The
   information needed to register this value in the "RDAP Extensions"
   registry is described in Section 5.2.

   The following is an example rdapConformance structure with the
   extension specified.

 "rdapConformance" :
 [
   "rdap_level_0",
   "rdap_objectTag_level_0"
 ]

Corrected Text
--
RDAP responses that contain values described in this document MUST
   indicate conformance with this specification by including an
   rdapConformance [RFC7483] value of "rdap_objectTag".  The
   information needed to register this value in the "RDAP Extensions"
   registry is described in Section 5.2.

   The following is an example rdapConformance structure with the
   extension specified.

 "rdapConformance" :
 [
   "rdap_level_0",
   "rdap_objectTag"
 ]

Notes
-
The value of the rdapConformance tag MUST match the value in the IANA registry, 
which is "rdap_objectTag".

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--
RFC8521 (draft-ietf-regext-rdap-object-tag-05)
--
Title   : Registration Data Access Protocol (RDAP) Object Tagging
Publication Date: November 2018
Author(s)   : S. Hollenbeck, A. Newton
Category: BEST CURRENT PRACTICE
Source  : Registration Protocols Extensions
Area: Applications and Real-Time
Stream  : IETF
Verifying Party : IESG

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Gould, James]

John,

The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, 
but full support comes down to the validation of the email addresses, how the 
email addresses are stored, and what the email addresses are used for.  I would 
expect an EPP error (2004 "Parameter value range error" or 2306 "Parameter 
value policy error") if an internationalized email address is received when the 
registry does not support it.   

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 

On 10/19/20, 1:44 PM, "regext on behalf of John Levine" 
 wrote:

In article <95c042c2-e77b-6f92-acb6-4a35663b1...@iit.cnr.it> you write:
>+1 for (1).

>> 1. Do you want the EPP standard to support non-ASCII email addresses?

Do we believe that every registry that supports EPP can handle UTF-8
addresses? If not, what happens when a regstrar sends a UTF-8 address
to a registry that can't handle it?

___
regext mailing list
regext@ietf.org

https://secure-web.cisco.com/1qcDCNLyDIN3HqWMcb7-LuVNC5Wot-5j-dVjUhYeJQGItCmz7UJwVSQqf70-qTisWhxVnKCyfZ9ptN7I_n4lTGpzlFMbPxSzgj5Nn_e3ElYqv432R1Nhw-XXY11GzUB0uEiVg99Urvgm25a591Fm2eIb5nl6EwXF4Gsz3gwykYuESAqBwN0J0V_0vTr4jv9EppVLjSHsBaZD5bf7wWWpfnxJakllfHlP0CfCvXDvlkrkdnmyX2hRgf3bU6-qkgBIz9wXxTYSABJTQzLUSwxkGMyuZMQojvjnBBCU2P1kcXJk/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[John Levine]

In article <5f5d3bae-b38c-4663-800b-3f5918990...@verisign.com> you write:
>
>The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, 
>but full support comes down to the validation of the
>email addresses, how the email addresses are stored, and what the email 
>addresses are used for.  I would expect an EPP error (2004
>"Parameter value range error" or 2306 "Parameter value policy error") if an 
>internationalized email address is received when the
>registry does not support it.   

That makes sense, but it also seems needlessly cruel. I expect
registrars would build ad-hoc lists of who handles EAI and who
doesn't, to provide better reports to their users, which would
then inevitably get out of date.

If we do this it really would be nice if there were a signal for who
handles EAI and who doesn't.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Gould, James]

John,

The signal would be handled via support for an EPP extension XML namespace in 
option 2, an operational practice XML namespace in what I would call 2b, or 
most likely a new contact XML namespace (contact-1.1) in option 1 for RFC 5733. 
 The XML namespace would be reflected in the EPP greeting services and login 
services.   

-- 
 
JG



James Gould
Fellow Engineer
jgo...@verisign.com 


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

Verisign.com 

On 10/19/20, 2:28 PM, "John Levine"  wrote:

In article <5f5d3bae-b38c-4663-800b-3f5918990...@verisign.com> you write:
>
>The registry can support the receipt of UTF-8 addresses based on the EPP 
RFCs, but full support comes down to the validation of the
>email addresses, how the email addresses are stored, and what the email 
addresses are used for.  I would expect an EPP error (2004
>"Parameter value range error" or 2306 "Parameter value policy error") if 
an internationalized email address is received when the
>registry does not support it.   

That makes sense, but it also seems needlessly cruel. I expect
registrars would build ad-hoc lists of who handles EAI and who
doesn't, to provide better reports to their users, which would
then inevitably get out of date.

If we do this it really would be nice if there were a signal for who
handles EAI and who doesn't.


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Gould, James
> Sent: Monday, October 19, 2020 2:50 PM
> To: jo...@taugh.com; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
>
> John,
>
> The signal would be handled via support for an EPP extension XML
> namespace in option 2, an operational practice XML namespace in what I
> would call 2b, or most likely a new contact XML namespace (contact-1.1) in
> option 1 for RFC 5733.  The XML namespace would be reflected in the EPP
> greeting services and login services.

I'm more a fan of using an extension with a new namespace than I am a fan of 
trying to update 5733. An extension would be more easily consumed by other 
extensions that use email addresses vs. having to also update all existing 
extensions that use email addresses.

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Dmitry Belyavsky]

On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott  wrote:

> > -Original Message-
> > From: regext  On Behalf Of Gould, James
> > Sent: Monday, October 19, 2020 2:50 PM
> > To: jo...@taugh.com; regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and
> EPP
> >
> > John,
> >
> > The signal would be handled via support for an EPP extension XML
> > namespace in option 2, an operational practice XML namespace in what I
> > would call 2b, or most likely a new contact XML namespace (contact-1.1)
> in
> > option 1 for RFC 5733.  The XML namespace would be reflected in the EPP
> > greeting services and login services.
>
> I'm more a fan of using an extension with a new namespace than I am a fan
> of trying to update 5733. An extension would be more easily consumed by
> other extensions that use email addresses vs. having to also update all
> existing extensions that use email addresses.
>

Adding support of an extension is harder than just allowing EAI email
addresses, both for registries and registrars.
Also, we get some fuzziness on implementation level. E.g., can we set ASCII
email via this extension?


-- 
SY, Dmitry Belyavsky
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext