Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-07

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
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.

[Ballot discuss]
Section 4:

  URI-list servers can use URIs
  tagged with the 'anonymize' attribute for routing SIP requests, but
  MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in
  recipient-history lists.

... seems to be missing a "to" in "MUST convert them the SIP URI"

  The order of precedence of the values of
  the 'copyControl' attribute is: "to", "cc", and "bcc".

Which order?  Is "to" the highest precedence or lowest?

[Ballot comment]
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.

REVISED IANA Last Call comments:

Action #1:
Upon approval of this document, the IANA will make the following
assignments in the "MAIL CONTENT DISPOSITION Values and
Parameters" registry located at
http://www.iana.org/assignments/mail-cont-disp
sub-registry "Mail Content Disposition Values"

Name | Description | Reference
------------------------+------------------------------+-----------+
recipient-list-history | the body contains a list of | [RFC-ietf-sipping-capacity-attribute-05.txt]
| URIs that indicates the |
| recipients of the SIP |
| request |


Action #2 (REVISED):
Upon approval of this document, the IANA will make the following
assignment in the XML namespace registry located at
http://www.iana.org/assignments/xml-registry/ns.html

ID + URI + Registration template + Reference
copycontrol + urn:ietf:params:xml:ns:copycontrol + [template from section 9.2] + [RFC-ietf-sipping-capacity-attribute-05.txt]


Action #3 (REVISED):
Upon approval of this document, the IANA will make the following
assignment in the XML schema registry located at
http://www.iana.org/assignments/xml-registry/schema.html

ID + URI + Filename + Reference
copycontrol + urn:ietf:params:xml:schema:copycontrol+ [XML from section 5] + [RFC-ietf-sipping-capacity-attribute-05.txt]

We understand the above to be the only IANA Actions for this
document.

IANA Last Call comments:

Action #1
Upon approval of this document, the IANA will make the following
assignments in the "MAIL CONTENT DISPOSITION Values and
Parameters" registry located at
http://www.iana.org/assignments/mail-cont-disp
sub-registry "Mail Content Disposition Values"


Name | Description | Reference
------------------------+------------------------------+-----------+
recipient-list-history | the body contains a list of | [RFC-sipping-capacity-attribute-05]
| URIs that indicates the |
| recipients of the SIP |
| request |


Action #2
Upon approval of this document, the IANA will make the following
assignments in the "URN Namespaces - [RFC2141, RFC3406]"
registry located at
http://www.iana.org/assignments/urn-namespaces
sub-registry "Registered Formal URN Namespaces"

Namespace + Value + Reference
urn:ietf:params:xml:ns:copycontrol + TDB + [RFC-sipping-capacity-attribute-05]


Action #3
Upon approval of this document, the IANA will make the following
assignments in the "Uniform Resource Identifer (URI) Schemes"
registry located at
http://www.iana.org/assignments/uri-schemes.html
sub-registry "Permanent URI Schemes"

URI Schema + Description + Referece
copycontrol + copy control level + [RFC-sipping-capacity-attribute-05]

The XML for this schema can be found as the sole content of Section 5.

We understand the above to be the only IANA Actions for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Mary Barnes is the WG Chair Shepherd for this document.
Yes, the Document Shepherd has personally reviewed this version of the
document and believes it is ready for forwarding to the IESG for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by WG members, with no concerns about the
depth or breadth of the review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is WG consensus behind this document and no one has
expressed concerns about its progression.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Yes. The draft has been validated for nits using idnits 1.122.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are split into normative and informative. There are two
normative reference that must be progressed prior to publication of this
document: draft-ietf-sipping-uri-services-06 and
draft-ietf-simple-xcap-list-usage-05.
Both documents have already been reviewed by the IESG, with the former
awaiting
progression of related drafts and the latter being in the RFC Editor's
Queue.
There are no normative references which are downward references.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?

Yes, there is an appropriate IANA section with the necessary
registrations
defined.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes, XML schema was validated.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
In certain types of multimedia communications, a Session
Initiation Protocol (SIP) request is distributed to a group

of SIP User Agents (UAs). The sender sends a single SIP
request to a server which further distributes the request
to the group. This SIP request contains a list of Uniform
Resource Identifiers (URIs), which identify the recipients
of the SIP request. This URI-list is expressed as a
resource
list XML document. This specification defines an XML
extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a
copy
control level similar to the copy control level of existing

e-mail systems.

Working Group Summary
The SIPPING WG supports the development and advancement of
this document.

Document Quality
This document defines no new protocol elements, but rather
registers a new disposition type, a new XML namespace, and
a new XML schema.

Personnel
Mary Barnes is the WG chair shepherd. Jon Peterson is the
responsible Area director.