Hi Scott, Thanks for the clarifications.
Paul On Fri, May 9, 2025 at 9:25 AM Hollenbeck, Scott <[email protected]> wrote: > Thanks for the comments, Paul. More below... > > > -----Original Message----- > > From: Paul Wouters via Datatracker <[email protected]> > > Sent: Thursday, May 8, 2025 9:39 AM > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > [email protected]; > > [email protected]; [email protected] > > Subject: [EXTERNAL] Paul Wouters' No Objection on > draft-ietf-regext-epp-eai- > > 24: (with COMMENT) > > > > Caution: This email originated from outside the organization. Do not > click links > > or open attachments unless you recognize the sender and know the content > is > > safe. > > > > Paul Wouters has entered the following ballot position for > > draft-ietf-regext-epp-eai-24: No Objection > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to https://secure- > > web.cisco.com/1qfD6CBlpzqrrMm9mbMwpf2gxaDjM2lW5-c0nm5Kzxleww- > > O0tTw2jhweVrQCPh8RR97yuTUbcPrbsxPixnPQesAnUDOJx20FHH1TaP5Vyf2 > > QW_TtVYCKhhPZHerBAlqfbUsELbFLRSTA4Whe8H3FHiJLS7uFgHg3LzTiZlLwaLp > > E5Tz8yJCjE43d1QAJLoG1iKZ6Ky470BlER3OJ3GtCjYqPvKEhrMFhymPJzNTAzc0 > > 1tzUc9Zx68bcyNREsvwn- > > XeQs0fUF6AqzuZBf_8OXbDE_bDNLwTh1CGUiRgtm- > > wKpJnkCtfvmvjiB0bdVI2jr/https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgrou > > ps%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://secure- > > web.cisco.com/1sn4HNjncRyoSgMZewVPhNDcPKNkhMatfSD1YO791ZhfiGO > > ajgFYXQQwk7GOnjdxQt7_eMeFs3q1WQSThSJ5mU5- > > bZY9L96QPcClR7ehdxnWnInxAKfh- > > lRI8FEcCJVxrtkf3wORltrFoDUXjfFgcCoAWECYtkP0be_jTCBiAup3C2qdmq8BO > > nYe_5Iy1LRQ74iN086OEvOYabZOASO8YclkwSwGDXI_a_DmY6SA2ZRv31B4Z > > wX0uX1_rXC6JHP72W5uNcUCIEbupyFYFkPwv5Yf133TWmqtXnwMFyhcD3E > > dReJ0bn9j- > > xJSWp9qns6wK/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf- > > regext-epp-eai%2F > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I did find the use of the "primary" attribute confusing. It seems to be > defined > > as "this is really the primary contact, use this instead of the ascii > primary > > contact". > > [SAH] It's explicitly described in Section 3: > > "The <addlEmail:email> element contains an OPTIONAL "primary" attribute > that can be used to indicate that the extension email address should be > treated as the primary email address for the extended contact object. " > > So yes, if the value of that attribute is TRUE, and the contact contains > both an ASCII address and an additional address in the extension (which can > be either an ASCII address or an SMTPUTF8 address), the address in the > extension is the one that should be considered the primary address for > contact purposes. > > > If no email address is set, and an EPP client tries to add one in > SMTPUTF8, > > should an error be thrown? Can this happen or can't the last ASCII email > > address listed not be deleted? > > [SAH] That scenario isn't possible. The email address associated with the > contact object described in RFC 5733 is REQUIRED. An email address is > always set, and the address in the base contact object can't be an SMTPUTF8 > address. > > > What is the meaning of an email attribute not using the "primary" > attribute > > that is in SMTPUTF8? It is not an alternative email to an ASCII email > address? > > But then what is it? Or is it an alternative to a combo of (ASCII + > primary > > SMTPUTF8) ? > > [SAH] If an extension address exists, and isn't marked with > primary="true", it's a second, alternative address that can be either an > ASCII address or an SMTPUTF8 address. > > > Can one delete an ASCII email so that a SMTPUTF8 email is the only one on > > record? I understand this is not supposed to happen? Should an error be > > returned for such a delete attempt ? > > [SAH] As noted above, this isn't possible. Any attempt to create a contact > object, or modify one to remove the email address, will be rejected with an > error. > > Scott >
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
