Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
RFC 5364

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' **)
No email
send info
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

Comment (2008-07-28)
No email
send info
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.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection