Thursday, November 10, 2022< ^ >
Meetecho has set the subject to: REGEXT IETF113
Room Configuration
Room Occupants

[16:49:46] <zulipbot> (James Galvin) @meetecho - presentation laptop is not working.  the trackpad is non-responsive.
[16:50:00] <zulipbot> (James Galvin) can you help?
[16:50:13] <zulipbot> (Lorenzo Miniero) James: that's not a presentation laptop actually
[16:50:26] <zulipbot> (Lorenzo Miniero) It's the laptop from where you see remote presenters and queue (same thing that's displayed on the 2nd screen)
[16:50:45] <zulipbot> (Lorenzo Miniero) Trackpad is disabled on purpose since it's not meant to be used for anything else than that
[16:51:02] <zulipbot> (James Galvin) ok.  then how do we get our slides on the in room screen?
[16:51:38] <zulipbot> (Lorenzo Miniero) You need to join a Meetecho session with a different laptop: sharing a slide deck from there will show it to the screen in the room and remote attendees
[16:51:51] <zulipbot> (James Galvin) we are sharing in the room
[16:51:52] <zulipbot> (James Galvin) no, that is not working
[16:52:08] <zulipbot> (Lorenzo Miniero) Make sure your laptop is muted as otherwise the remote feed could cause echo
[16:52:21] <zulipbot> (James Galvin) never mind - it just started
[17:00:48] <zulipbot> (James Gould) Go Rick!
[17:02:02] <zulipbot> (Jody Kolker) hi is the meeting starting?
[17:04:00] <zulipbot> (James Galvin) yes, just started!  are you hearing?
[17:04:13] <zulipbot> (Jody Kolker) sorry can't hear.  Must be my machine.
[17:04:13] <zulipbot> (Andrew Newton) All good here
[17:09:26] <zulipbot> (James Gould) I don't believe the simple registration reporting is ready for WGLC
[17:13:05] <zulipbot> (Andrew Newton) I second moving the redacted draft up in the queue
[17:16:34] <zulipbot> (Scott Hollenbeck) I've read it
[17:18:07] <zulipbot> (John Klensin) I've read it too, think it needs work, and note with concern that none of the authors appear to be present in this meeting.
[17:23:37] <zulipbot> (Marc Blanchet) I'm having a problem identifying a type of email address as SMTPUTF8, which is just the SMTP signalling. I think EAI is a more appropriate name to designate that type of email.
[17:24:10] <zulipbot> (Pete Resnick) @**Marc Blanchet** Yeah, a terminology scrub of the document would be good.
[17:27:00] <zulipbot> (Pete Resnick) I agree with John that thinking of an EAI address as a "second" email address is kind of goofy. This is a separate thing, that can be used when you use the SMTPUTF8 protocol instead of SMTP.
[17:27:39] <zulipbot> (Pete Resnick) (That is, it's a second mail protocol you're using, not a second email address.)
[17:27:52] <zulipbot> (John Klensin) @Marc: As you probably know, the EAI WG explicitly agreed the calling this stuff "EAI" was a bad idea.  "Non-ASCII" would be fine.
[17:29:12] <zulipbot> (John Klensin) @Pete: yes.  Although if one of those non-ASCII things is to be used, it is better to think about it as primary and the ASCII one as secondary/backup
[17:29:12] <zulipbot> (John Klensin) +1 to Victor.
[17:30:45] <zulipbot> (Marc Blanchet) Agree with Pete way of describing it (supporting another SMTP protocol)
[17:30:46] <zulipbot> (James Gould) cardinality is associated with the provisioning of the values
[17:31:56] <zulipbot> (Andrew Newton) So it's not second email address, it's a different protocol address?
[17:32:09] <zulipbot> (Murray Kucherawy) That's what I understood Pete to be saying.
[17:34:20] <zulipbot> (Pete Resnick) @_**John Klensin|355** [said](
@Pete: yes.  Although if one of those non-ASCII things is to be used, it is better to think about it as primary and the ASCII one as secondary/backup
I think you could say that you *always* use what's in that field if you're using SMTPUTF8 and *never* use the ASCII email address. If you support the extension, then you must fill in that field, even if it's with an identical ASCII-only address.
[17:34:20] <zulipbot> (James Gould) The existing draft can accept an ASCII or an EAI address in the existing fields.  The difference is to be able to support an alternate value, where one of them must be an ASCII value during the transition period.
[17:35:12] <zulipbot> (James Galvin) @pete yes, that makes sense and responds to the issue I have in mind.
[17:35:42] <zulipbot> (Pete Resnick) I'll repeat at the mic
[17:37:03] <zulipbot> (Andrew Newton) @jamesg, what is the length of the transition period?
[17:37:18] <zulipbot> (Marc Blanchet) I'd say a few months ;-)
[17:37:44] <zulipbot> (James Gould) Not all clients (registrars) will support SMTPUTF8, so the server (registry) needs to be able to support a mix.
[17:37:44] <zulipbot> (James Galvin) length of time is a policy concern.  have to think about how to say that in the  document
[17:38:23] <zulipbot> (Murray Kucherawy) Does the document need to prescribe a transition period, or just a transition plan?
[17:38:23] <zulipbot> (James Gould) The policy is out-of-scope for the draft, so it would be delegated to server policy and the draft can state that.
[17:38:36] <zulipbot> (James Galvin) clearly we have some discussion to be had about how to do what we want.  I think we have agreement on the action.
[17:38:49] <zulipbot> (James Galvin) two actions I think.  please confirm:
[17:38:49] <zulipbot> (Pete Resnick) @**Murray Kucherawy** I don't think it needs to define a transition. You either support the new stuff, or you don't.
[17:39:17] <zulipbot> (James Galvin) 1. describe this as support for two email protocols, not two email addresses.
[17:39:18] <zulipbot> (Andrew Newton) Do all EPP systems fall under the same policy? If they don't, then the transition period is typical of most Internet transition periods.
[17:39:30] <zulipbot> (John Klensin) The earlier comment about the "transition period" being likely to be "forever" is likely important here.    The problem is language and local MUAs, etc., not protocols
[17:40:04] <zulipbot> (James Galvin) 2. Priority should be for the non-ascii email if both are present.
[17:40:17] <zulipbot> (James Galvin) there is some discussion to be had about exactly how to get number 2 covered.
[17:40:30] <zulipbot> (Gustavo Lozano) Additional addresses linked to contact may have downstream effects on policies (gTLDs and ccTLDs). Policies usually talk about sending an email to the registrant, contact X or Y, and it's well-understood that only one email address exists for the contact. If we have multiple email addresses linked to a contact, which is going to be considered authoritative from a policy perspective.
[17:40:45] <zulipbot> (James Gould) We do have a -17 available to post matching the proposal if there is desire to post it to start the discussion in the WG
[17:41:38] <zulipbot> (Viktor Dukhovni) Addresses are used not just within RRR context, but also (4th?) parties trying to reach a domain contact, and their needs and preferences for the preferred address form will vary.
[17:41:38] <zulipbot> (Pete Resnick) @**James Galvin** Again, frame it in terms of protocol: If both sides support the extension, use the SMTPUTF8 protocol. If not, don't.
[17:42:18] <zulipbot> (Pete Resnick) If you use the protocol, then you're going to use the address in the non-ASCII address field.
[17:42:31] <zulipbot> (John Klensin) @Victor: And _that_ is the important issue and has been, at least for me, from the beginning
[17:42:31] <zulipbot> (Marc Blanchet) when people refer to policy, I think they are referring to ICANN policies, but EPP and SMTP is used outside of ICANN, so those policies that may have timing/effects that should not be taken into account.
[17:42:44] <zulipbot> (Dmitry Belyavskiy) @Pete Reznik it's exactly what the current version says :)
[17:42:57] <zulipbot> (Pete Resnick) (s/non-ASCII/ASCII-or-non-ASCII, I suppose)
[17:43:23] <zulipbot> (John Klensin) @Marc:  Yes, and that reinforces the "forever transition" positin.
[17:43:48] <zulipbot> (Dmitry Belyavskiy) @Viktor Dukhovni it's sort of irrelevant in the GDPR era :)
[17:44:01] <zulipbot> (James Galvin) @pete.  I agree.  i think we can make this work.
[17:44:14] <zulipbot> (Eduardo Alvarez) for anyone interested, we've seen about 21.6% (7.6M) of MX servers found in second level registrations in gTLDs successfully support EAI (SMTPUTF8) as measured by ICANN’s support survey tool (code available at )
[17:44:27] <zulipbot> (Andrew Newton) Regarding transitions, Gopher is still in regular use on the Internet, and in fact, a new implementation surfaced just 2 years ago.
[17:44:28] <zulipbot> (James Gould) I'll repeat: We do have a -17 available to post matching the proposal if there is desire to post it to start the discussion in the WG
[17:45:11] <zulipbot> (Jim Reid) Andrew, I hear telex machines are making a comeback too. 😀
[17:45:24] <zulipbot> (Murray Kucherawy) Thanks, James, good stuff
[17:46:17] <zulipbot> (James Galvin) so Jim please send in your -17 and we'll got from there on the list.  thanks!
[17:46:35] <zulipbot> (Richard Wilhelm) fwiw... I captured a lot of notes about that discussion... so if you came to the mic pls feel free to review and make sure that I captured your "vibe" correctly...  and if I missed something in the chat... pls add!
[17:47:14] <zulipbot> (Andrew Newton) is the more specific domain relationship about reverse DNS?
[17:47:47] <zulipbot> (Murray Kucherawy) Let me rephrase my answer: If the chairs think that the edits to be made as a result of this discussion are significant enough that we can no longer legitimately say the previous consensus covers the new text, then I should return it to the WG with the intent to do a second Last Call on it.  Otherwise we can probably continue with it from where it is.
[17:48:00] <zulipbot> (Pete Resnick) (BTW: I will forgive Dmitry for changing my family name. You could use Ру́сский. 😉
[17:48:26] <zulipbot> (Pete Resnick) Rēznik
[17:51:03] <zulipbot> (John Klensin) Perhaps fortunately, neither I nor anyone living knows what my family name "really" is, nor the language and script in which it should be written.
[17:51:26] <zulipbot> (Pete Resnick) Резник
[17:51:39] <zulipbot> (Murray Kucherawy) I suppose it's a coincidence that SANA is an anagram of NASA.
[17:52:50] <zulipbot> (Andrew Newton) If we adopt this work, will Elon Must buy the REGEXT wg? 😀
[17:53:03] <zulipbot> (Murray Kucherawy) $8 per draft.
[17:53:03] <zulipbot> (Pete Resnick) Perhaps my internationalized email address should be "Резник@ ἐπιστήμη.net"
[17:53:33] <zulipbot> (Murray Kucherawy) ($4 for Experimental)
[17:53:47] <zulipbot> (John Klensin) Make him buy the whole IETF at $8 per draft, present and past.
[17:54:19] <zulipbot> (Andrew Newton) RFCs limited to 280 characters.
[17:58:09] <zulipbot> (James Gould) Very interesting use case
[17:58:39] <zulipbot> (Scott Hollenbeck) I agree, this is worth doing
[17:59:29] <zulipbot> (Mario Loffredo) Happy to know that JSContact is used in another RDAP context :-)
[17:59:55] <zulipbot> (Richard Wilhelm) Also agree that this is worth doing
[18:00:17] <zulipbot> (Jody Kolker) +1
[18:01:00] <zulipbot> (Jody Kolker) I would be interested in the TTL work.
[18:01:48] <zulipbot> (Paweł Kowalik) +1 for TTL work
[18:02:01] <zulipbot> (Richard Wilhelm) same here...  (re TTL)