Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
Note: This ballot was opened for revision 07 and is now closed.
(Jon Peterson) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) (was Discuss) No Objection
(Lars Eggert) No Objection
Comment (2008-07-11 for -** No value found for 'p.get_dochistory.rev' **)
Miguel's affiliation and email address have recently changed. It'd be good to update those, so that follow-up emails from the RFC Editor reach him.
(Russ Housley) No Objection
(Cullen Jennings) No Objection
(Chris Newman) (was Discuss) No Objection
Discussion was held on this topic. Given the context it appears less serious here than in the email space. The author proposed a resolution to add text to describe BCC issues and I think that would be a good idea. Rather than wait for the loop to be closed on specific text I trust the author to use his best judgement either now or during AUTH48 and will clear my discuss so this can proceed. Previous discuss text: There is a profound and often-misunderstood security consideration with 'bcc'. It is very important that the BCC recipient is aware of the fact it is a bcc and does not reply to the message without clear knowledge it will be exposing information. See RFC 2822 security considerations for a discussion of BCC security implications. I'm a bit concerned that just changing the disposition type rather than also changing the media type means that a client unaware of sensitive 'bcc' semantics might accidentally reply to a 'bcc' without knowing it. This is a serious issue as in some countries people can lose face and lose major contracts and jobs over such etiquette breaches.