Actually, we should adopt it for ALL streams, but leave some flexibility.  I'll repeat what I said elsewhere: having a common understanding of authorship provides consistency to the reader.  There has yet to be a substantial example of where there is any difference between streams at the policy level.  The basic principles are these:

 * To be an author you have to have made a substantial contribution to
   the work.
 * No one may be an author without their consent.
 * If that group gets size XXL, use Contributors.
 * The text is the authors' responsibility.  If they can't stand up for
   what's there, they should remove themselves as authors.  That
   includes consensus text with which they disagree.
 * Don't plagiarize work.  If you had AI generate text, say so.
 * Exceptions exist, and we'll deal with them on a case-by-case basis.

To EKR's point:

I agree that they don't, and as indicated in my previous message, this limitation
just seems to be directed towards keeping this document within the scope
of RSWG. However, the better approach would be to bring this to a venue
with the right scope, which is to say to the streams.

Sorry, that's just a backdoor argument without substance.  We are VERY liberal in how drafts are handled, and  the exact oppsite with RFCs.  Readers do not care about streams.  They get what they get with drafts. But we should pride ourselves on the RFC series.  That is this organization's primary output.

Eliot


On 24.06.2026 14:27, Salz, Rich wrote:
I agree, again, with everything EKR wrote.

If the goal is to be consistent across streams, adopting this document in the smallest and least important* of streams and saying that the other streams can modify and adopt this as they see fit is not the way to achieve that goal.  Have the largest and most important* stream process it first.

*By least and most important, I am referring to the participation and readership size, as well as the impact on the industry. Nobody really cares how “x+y<z” is written in RFC source, nor should they; they care about things like the best way to use TLS, for example. Taking Eliot’s lens and thinking of the reader, this document does not belong here.

Attachment: OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

-- 
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to