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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/ ---------------------------------------------------------------------- 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. # 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? # 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. # 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? Cheers, Med _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
