Leslie, You wrote:
*> *> *> The quoted requirement is not something that you can split *> and interpret separately as you have done in your comment. *> *> Yes, RFC Editor certainly routinely catches issues of readability, *> greater and lesser. AUTH48 is always (at least, for me :-) ) *> an exercise in learning how unclearly one writes ;-) And, *> there was a notable instance when the RFC Editor caught the fact *> that my document had 2 non-sentences trailing at the end of *> a section -- leftovers from previous edits. I had not caught *> that. The IETF-wide last call had not caught that. The IESG *> review had not caught that. Oops on all of us :-) *> *> But. *> *> "that may change technical ... wording" is key. Too often *> "clarity" breaks the intended meaning. *> *> A simple sample, from my own experience: *> *> ORIGINAL: *> 2.2.4 S-NAPTR and Successive Resolution *> *> *> As shown in the example NAPTR RR set above, it is possible to have *> multiple possible targets for a single application service+protocol *> pair. These are to be pursued in order until a server is *> successfully contacted or all possible matching NAPTR records have *> been successively pursued to terminal lookups and servers contacted. *> That is, a client must backtrack and attempt other resolution paths *> in the case of failure. *> *> *> AUTH-48: *> 2.2.4. S-NAPTR and Successive Resolution *> *> As shown in the example set above, it is possible to have multiple *> possible targets for a single application service+protocol pair. *> These are to be pursued in order until a server is successfully *> contacted or all possible matching NAPTR records have been *> successively pursued to terminal lookups and contacted servers. That *> is, a client must backtrack and attempt other resolution paths in the *> case of failure. *> *> *> ISSUE: *> The binding of "all" has failed, in rewriting "servers contacted" *> to "contacted servers". *> *> NEW: *> 2.2.4. S-NAPTR and Successive Resolution *> *> As shown in the example set above, it is possible to have multiple *> possible targets for a single application service+protocol pair. *> These are to be pursued in order until a server is successfully *> contacted or all possible matching NAPTR records have been *> successively pursued through terminal lookup and server contact. That *> is, a client must backtrack and attempt other resolution paths in the *> case of failure. *> *> The original sentence did not make sense (to me), while your final corrected sentence does make sense. If we had not made the AUTH48 change, the original nonsensical sentence would have persisted. I expected you to object to the removal to "NAPTR RR" from the first sentence; I myself would agree that this removal was erroneous editing. Bob Braden _______________________________________________ Techspec mailing list [email protected] https://www1.ietf.org/mailman/listinfo/techspec
