![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Pasi:
2) If this was published in a more academic environment, it would be proper (and required) to cite related work, tracing the source of ideas that were not entirely new. We don't usually have extensive citations in RFCs, but in this context, perhaps it would be appropriate to mention the previous proposal for sending ACs in TLS (draft-ietf-tls-attr-cert from 1998) in the Acknowledgements section.
This takes a very different approach. Stephen and I co-authored RFC 3281, which is referenced. I do not think that Stephen's ideas about integrating Attribute Certificates into TLS had any impact on the design in the current document.
There are of course similarities that might or might not be important when considering prior art, basically the date is what you'd care about really then anyway.
FWIW, I don't think we want to start bouncing specs because they don't pay homage - in this case all the similarities are probably the only obvious ways to add authorization tokens to a TLS handshake. Such downrefs to dead documents would anyway add yet more cruft to the RFC process, so let's not.
S.
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.