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" 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. > > > # 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: 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. > > # 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? > > Scott ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
