> -----Original Message----- > From: [email protected] > <[email protected]> > Sent: Wednesday, May 7, 2025 4:40 AM > To: Hollenbeck, Scott <[email protected]>; > [email protected] > Cc: [email protected]; [email protected]; > [email protected]; > [email protected] > Subject: [EXTERNAL] RE: 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. > > Hi Scott, > > Thanks for the follow-up. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Hollenbeck, Scott <[email protected]> > > Envoyé : mardi 6 mai 2025 19:39 > > À : BOUCADAIR Mohamed INNOV/NET > <[email protected]>; > > [email protected] Cc : [email protected]; > > [email protected]; [email protected]; [email protected] Objet : > > RE: Mohamed Boucadair's No Objection on draft-ietf-regext- > > epp-eai-24: (with COMMENT) > > > > > > Thanks for the feedback, Med. More below... > > > > > -----Original Message----- > > > From: Mohamed Boucadair via Datatracker <[email protected]> > > > Sent: Monday, May 5, 2025 10:53 AM > > > To: The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected]; [email protected]; [email protected] > > > 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.) > > > > > > > > > ----------------------------------------------------------------- > > > 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]". > > [Med] Thanks. > > > > > > # 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. > > [Med] I was referring to this part "examples provided in this document MUST > be interpreted"
[SAH] Maybe the normative language is misleading, but it's intended to tell readers and implementers that you can't change the character case in the examples and expect them to remain syntactically valid. > 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. > > [Med] I see. We don't need normative language for this, IMO. [SAH] Perhaps, but pretty much every EPP RFC has used this same language for the last 20 years. I'd prefer to keep this document consistent with all of the others. > > > # 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. > > > > [Med] "NOT REQUIRED" is not a normative language. More importantly, I > think normal english is sufficient here as this is about clarifying a > convention > and XML validations rules apply anyway. Please note that 8174 (which is cited > in the doc) has the following: [SAH] OK, but REQUIRED (the current text) *is* listed in BCP 14. > In many IETF documents, several words, when they are in all capitals > as shown below, are used to signify the requirements in the > specification. .. > ... > > o These words can be used as defined here, but using them is not > required. Specifically, normative text does not require the use > of these key words. They are used for clarity and consistency > when that is what's wanted, but a lot of normative text does not > use them and is still normative. [SAH] The situation here is the same situation I described above. This is "boilerplate" EPP extension text that we've been using for more than 20 years. It hasn't been problematic. > > > # 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. > > [Med] OK, thanks. > > > A server might limit extension access to certain clients based on > > out-of-band communications, and those communications could very well > > inform configuration decisions. > > [Med] Thanks. Can we indicate that, absent local policy, clients/servers that > support the extension will by default indicate support as part of extensions > negotiation? [SAH] That's already baked into EPP. It's described in Section 2.4 of RFC 5730. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
