Thanks for the feedback, Med. More below... > -----Original Message----- > From: Mohamed Boucadair via Datatracker <nore...@ietf.org> > Sent: Monday, May 5, 2025 10:53 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-regext-epp-...@ietf.org; regext-cha...@ietf.org; > regext@ietf.org; > jkol...@godaddy.com; jkol...@godaddy.com > Subject: [EXTERNAL] Mohamed Boucadair's 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. > > Mohamed Boucadair 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/16S- > F6PGzZftKJri4Snou35a7hu0f8BH- > NE6rlr7PY7GXgt4mw9Bei64WAr2HDhUIWHnpi_IebUsNwaWqLgsdjs_h2dhfJi > RWgG0SL4VGdSMpPoO0cgXRywpfZG8opxmDHq8dbSqR1gY8- > wJIQNrIkqqTYzkzERA1sxOvmtX3owwEqwA_nDr7df25i_7ZxDQYwU1GxUgSxR > 7W_Ko-7xJFa-w9IjpGG3TCLjyGfUQT7ilQNzrS- > kxsrjZpdV96gRScXGSDDJgwq_0Q8hDcKowIVSzi6_PxRG0gvRCWLn6EY4QxfoD > a1pE8LM9IwaZUtqEK/https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups% > 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/1_So7W79_hV1J7pmOXBbmlvD_OaSPKcmlklkozGj7F6pqeHg > PBwxC6ttc6F_cxS4nrSyoG- > 3ASW367GGmJdPAc5B5iQajdZgxFZMSIp0fG2P0VSLNq_Jv1adR3QTBNKf8y2z > s9Bs3PxFtDjgIewFUH_f5b5ZKMHWAp2ZuFc1sxc67StXqd05k_jEXUWhowHP > wpUjUEkTCuWPYP9jA798Aw5oV77UlxmjbZcjpR2Dg1y0zPXp- > 7ta0GkyDYUhIDEcUNmnc0EuBecy94NZPsF37jUQbJYlDIaw1Bg7FVmm7MXTf > Cj_rYiS3yqGmWIelIkAw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdra > ft-ietf-regext-epp-eai%2F > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi Dmitry, James, and Scott, > > Thanks for the effort put into this specification. > > Please find some very few comments: > > # Not a new behavior: Either cite the text as a quote or remove the normative > language > > CURRENT: > As described in [RFC5733], the email address associated > with the base contact object MUST be an ASCII-only address.
[SAH] We can change that. I'll change that sentence to "The syntax for the email address associated with the base contact object is described in Section 2.6 of [RFC5733]". > # Smells like a specification by examples > > CURRENT: > XML is case sensitive. Unless stated otherwise, XML specifications > and examples provided in this document MUST be interpreted in the > character case presented in order to develop a conforming > implementation. > > Why insisting on the examples needed here? Shouldn’t compliance be based in > the > first sentence? [SAH] There's no insistence on the examples. They are included only to describe syntactically valid commands and responses. The point of the text is that if you alter the character case in either the specifications or the examples, they will likely no longer be syntactically valid and a validating XML parser will be unable to process them without error. > # Check normative language use > > CURRENT: > In examples, "C:" represents lines sent by a protocol client and "S:" > represents lines returned by a protocol server. Indentation and > white space in the examples are provided only to illustrate element > relationships and are not REQUIRED in the protocol. > > This is misleading as this is about “not required”. Not sure I would use the > normative language at the first place. I see that 5733 has an a similar > instance of “not a REQUIRED feature of this protocol”, though. [SAH] I don't think it's misleading at all. The text is saying that an implementer shouldn't include the "C:" and "S:" characters when trying to process the examples, and that the white space found in the examples isn't REQUIRED. It could say "NOT REQUIRED", but I don’t think that changes the meaning. > # Capability negotiation > > CURRENT: > If both client and server have indicated support for SMTPUTF8 > addresses during session establishment, they MUST be able to process > an SMTPUTF8 address in any extended contact object during the > established EPP session. > > Is the negotiation controllable by configuration on a client/server that > support the extension must always advertise/negotiate it? [SAH] That's an implementation decision, so I imagine it could be. A server might limit extension access to certain clients based on out-of-band communications, and those communications could very well inform configuration decisions. Scott _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
