[Sipping] WGLC Review: draft-ietf-sipping-capacity-attribute-01.txt

["Mary Barnes" <[e-mail]>]

Draft:  draft-ietf-sipping-capacity-attribute-01.txt
Reviewer: Mary Barnes
Review Date: 19 Sept 2006
Review Deadline: 19 Sept 2006
Status: WGLC

Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication and there's a couple questions
for clarification.

Question for clarification:
----------------------------
1.  Why do you need both the bcc and the cc with the anonymize
attribute?  It seems that the bcc is more anonymous than the cc with the
anonymize attribute (in my mind a bcc is an anonymous cc, but I'm not an
email expert).  If there is a distinct reason, it should be clarified in
the document, likely around the same place in the text that you'll be
clarifying the purpose of the extension in general, as suggested by
Brian Rosen. 

2.  Section 9.  A new SIP option-tag is mentioned in the first
paragraph, but none is defined in this doc.  Is that a typo?

General Comments:
------------------
- Agree with the list discussion on changing the usage of the term
"capacity" to "copyControl". 

Editorial nits:
----------------
- Section 3, 3rd paragraph, 1st sentence. Either add an "and" before
"excludes" or change "excludes" to "excluding".
OLD:
    When the URI-list server expands the request for each recipient, it
   includes a new URI-list that contains only the targets originally
   listed in the "to" and "cc" capacities, excludes those listed in the
   'bcc' capacity. 
NEW:
   When the URI-list server expands the request for each recipient, it
   includes a new URI-list that contains only the targets originally
   listed in the "to" and "cc" capacities and excludes those listed in
the
   'bcc' capacity.  
 

- Section 3, 4th paragraph, last sentence.  Change "include" to "add" OR

"to any" to "with any"
OLD:
   It is not expected to have
   value other than with anonymous URIs, although technically, it is
   possible to include the 'count' attribute to any URI.
NEW:
   It is not expected to have
   value other than with anonymous URIs, although technically, it is
   possible to add the 'count' attribute to any URI.


- Section 4, 2nd paragraph, 2nd sentence.  Add "to" before "anonymize".
OLD:
   If set to a "true" value, it
   provides an indication to the URI-list server for not disclosing the
   URI itself in a URI-list sent to the recipient, but instead,
   anonymize the URI. 
NEW: 
   If set to a "true" value, it
   provides an indication to the URI-list server for not disclosing the
   URI itself in a URI-list sent to the recipient, but instead,
   to anonymize the URI. 

- Section 4, 4th paragraph, 3rd sentence.  "duplicated" -> "duplicate"

- Section 6, 1st paragraph after Figure 3, 1st sentence.  "reception" ->
"receipt"

- Section 7, 3rd paragraph. Current wording is awkward and it might be
better to reword the 1st sentence and add an Otherwise clause associated
with the SHOULD to emphasize the point.  So, I'm proposing a change
something like the following:
OLD:
   It is often desired that, if the intended recipient of the SIP
   request does not support this specification, still the SIP request
   does not fail.  In order to provide the maximum probability of
   success of those requests that include 'recipient-list-history'
   bodies, User Agents (such as URI-list services) that build SIP
   requests with the Content-Disposition header field set to 'recipient-
   list-history' SHOULD add a 'handling' parameter [4] set to
   "optional".
NEW:
   If the intended recipient of the SIP
   request does not support this specification, 
   the SIP request SHOULD NOT fail. 
   In order to ensure successful receipt of the SIP 
   requests that include 'recipient-list-history'
   bodies, User Agents (such as URI-list services) that build SIP
   requests with the Content-Disposition header field set to 'recipient-
   list-history' SHOULD add a 'handling' parameter [4] set to
   "optional".  Otherwise, the SIP request MAY fail and not be received
by 
   the intended recipient. 

- Section 8, 2nd paragraph, 1st sentence. "hand" -> "send"

- Section 8, 3rd paragraph, 3rd sentence. "was" -> "is"
OLD:
   Eavesdroppers are able to watch URI-lists contained in SIP
   requests unless the SIP message was sent over a secured channel with
   Transport Layer Security (TLS) [3] or unless the URI-list body itself
   is encrypted with S/MIME [8]. 
NEW:
   Eavesdroppers are able to watch URI-lists contained in SIP
   requests unless the SIP message is sent over a secured channel with
   Transport Layer Security (TLS) [3] or unless the URI-list body itself
   is encrypted with S/MIME [8]. 

Section 11.2 
- Rferences 10 and 11 need updating since those docs moved to SIP.



_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP