A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists
draft-ietf-simple-event-list-07

On Oct 13 Sam Hartman agreed that SMB's Discuss concerns had been
satisfied, so it was ok to advance the document.  I sent the approval request
on 13 Oct.

[Ballot discuss]
Old discuss text:
Section 5.2 (and similar text in section 5.3) says that "The optional "name" attribute contains a human readable description or name for the resource list."  If the name is supposed to be human-readable, there are internationalization considerations to be addressed.  For example, what language is used to represent the description?

I noticed that this has been address (language tagging has been added), but the reference being used for the language tag (RFC 1766) has been obsoleted by RFC 3066 (which, BTW, is itself in the process of being obsoleted).  The ref to 1766 needs to be updated to point to 3066 or the LTRU WG I-D that's intended to replace 3066.

Old discuss text:
Has the MIME type registration in section 8.2 been reviewed on the ietf-types list?  Harald's archives seem to be unavailable at the moment so I can't check.

I just did check -- there's nothing in the archives.  Please either confirm that a review request was made (a pointer to the message would help) or submit the request for review.

[Ballot discuss]
7.1: there is no standardized mechanism to upload a necessary shared
secret.  There needs to be a mandatory-to-implement scheme.t of the
user before transferring such secrets.

[Ballot comment]
No further objection. I agree with Russ's comment about 'multipart/encrypted' - RFC3261 does not describe the use of that MIME type for SIP; it uses 'application/pkcs7-mime' for encrypted MIME bodies.

[Ballot comment]
Do you really use multipart/encrypted?  S/MIME does not use this
  MIME type.

  Section 6, number 11 references RFC 2633 for multipart/signed. I think
  this should reference RFC 1847 (security multiparts).

  Section 6, number 13 discusses "application/signed". I think that this
  should be "multipart/signed".

  Section 7.3 says that the initiator in an exchange will indicate support
  for encryption by saying "multipart/encrypted" or "multipart/signed."
  The exchange may not proceed if the policy for the listener indicates
  that encryption is required, but the initiator does not indicate support
  for encryption. Do you really use multipart/encrypted?  S/MIME does not
  use this MIME type.  Also, there are multiple ways to handle signing, so
  indicating "multipart/signed" precludes the use of the other approaches,
  especially "application/pkcs7-mime" used in S/MIME.

[Ballot discuss]
Please reference the most recent S/MIME documents.  Specifically,
  [12] should refer to RFC 3851.

  Section 7.3 says that the initiator indicates support for encryption
  by saying "multipart/encrypted" or "multipart/signed."  The exchange may
  not proceed if the policy for the listener indicates that encryption is
  required and the initiator does not indicate support for encryption.  If
  the listener is going to say stop the exchange when there is no
  indication of support for "multipart/encrypted," two parties that support
  encryption via S/MIME may not be able to proceed.

  Section 7.2 says:
  >
  > ...  Implementations MUST NOT attempt to perform this type of
  > optimization unless adequate access to complete authorization
  > policy can be guaranteed. ...
  >
  I find the use of "this type of optimization" somewhat ambiguous.
  The two preceding paragraphs provide the context.  The situation is:

    a) A resource list server (RLS) often provides information to
      multiple subscribers at the same time.
    b) The same resource may be present in several notification lists.
    c) Two users subscribe to the same notification list.

  And, the concern is:
 
    d) A RLS implementations may attempt to minimize network load by
      maintaining only one notification list for each resource.
    e) Since all users would get the same information for a given
      resource, only a allowed/not allowed authorization policy can
      be supported.

  If I got this wrong, then I the text needs further clarification.

  If my analysis is correct, then I think that the quoted sentence
  should be replaced with something like:
 
    ...  Implementations MUST NOT use a single notification list for
    each resource unless all users have the same authorization. ...

[Ballot comment]
Purely editorial, but since the draft looks likely to be edited anyway, I believe it would
be useful to clarify this statement in the Introduction:

  this specification defines an extension to
  RFC 3265 [2] that allows for requesting and conveying notifications
  for lists of resources.  A resource list is identified by a URI and
  it represents a list of zero or more URIs.  Each of these URIs is an
  identifier for an individual resource for which the subscriber wants
  to receive information.  In many cases, the URI will be a SIP URI
  [1]; however, the use of other schemes (such as pres: [9]) is also
  foreseen.


"the URI" in the final statement is ambiguous; a reader could conclude
that it meant the "resource list URI" or the "URI (which is) an identifier
for an individual resource.  Making it crystal clear would be good.

[Ballot discuss]
7.1: there is no standardized mechanism to upload a necessary shared
secret.  There needs to be a mandatory-to-implement scheme;
additionally, implementations MUST seek the explicit consent of the
user before transferring such secrets.

[Ballot discuss]
The schema in section 5.1 is broken.  This line:



is missing a quote character to close type="xs:string".  It should be:



The example given in the same section (and I see others in other sections) is also broken.  The xmlns declaration in the  element says that the namespace URI is "urn:ietf:params:xml:ns:rmli", but the namespace URI listed in the schema is "urn:ietf:params:xml:ns:rlmi" ("rmli" vs. "rlmi").  Please change "rmli" to "rlmi".

Both of these can be addressed in an RFC Editor note.

Section 5.2 (and similar text in section 5.3) says that "The optional "name" attribute contains a human readable description or name for the resource list."  If the name is supposed to be human-readable, there are internationalization considerations to be addressed.  For example, what language is used to represent the description?

Has the MIME type registration in section 8.2 been reviewed on the ietf-types list?  Harald's archives seem to be unavailable at the moment so I can't check.

[Ballot discuss]
The schema in section 5.1 is broken.  This line:



is missing a quote character to close type="xs:string".  It should be:



The example given in the same section (and I see others in other sections) is also broken.  The xmlns declaration in the  element says that the namespace URI is "urn:ietf:params:xml:ns:rmli", but the namespace URI listed in the schema is "urn:ietf:params:xml:ns:rlmi" ("rmli" vs. "rlmi").  Please change "rmli" to "rlmi".

Both of these can be address in an RFC Editor note.

Section 5.2 (and similar text in section 5.3) says that "The optional "name" attribute contains a human readable description or name for the resource list."  If the name is supposed to be human-readable, there are internationalization considerations to be addressed.  For example, what language is used to represent the description?

Has the MIME type registration in section 8.2 been reviewed on the ietf-types list?  Harald's archives seem to be unavailable at the moment so I can't check.

[Ballot discuss]
The schema in section 5.1 is broken.  This line:



is missing a quote character to close type="xs:string".  It should be:



The example given in the same section (and I see others in other sections) is also broken.  The xmlns declaration in the  element says that the namespace URI is "urn:ietf:params:xml:ns:rmli", but the namespace URI listed in the schema is "urn:ietf:params:xml:ns:rlmi" ("rmli" vs. "rlmi").  Please change "rmli" to "rlmi".

Both of these can be address in an RFC Editor note.

Section 5.2 (and similar text in section 5.3) says that "The optional "name" attribute contains a human readable description or name for the resource list."  If the name is supposed to be human-readable, there are internationalization considerations to be addressed.  For example, what language is used to represent the description?

[Ballot comment]
Section 5.4 says that 'This attribute contains one of the values "active", "pending", or "terminated"'.

This attribute definition in the schema could (should?) thus be defined as an enumeration to ensure that the allowable values are limited to those described in the text:

[Ballot discuss]
The schema in section 5.1 is broken.  This line:



is missing a quote character to close type="xs:string".  It should be:



The example given in the same section is also broken.  The xmlns declaration in the  element says that the namespace URI is "urn:ietf:params:xml:ns:rmli", but the namespace URI listed in the schema is "urn:ietf:params:xml:ns:rlmi" ("rmli" vs. "rlmi").  Please change "rmli" to "rlmi".

Both of these can be address in an RFC Editor note.

Section 5.2 (and similar text in section 5.3) says that "The optional "name" attribute contains a human readable description or name for the resource list."  If the name is supposed to be human-readable, there are internationalization considerations to be addressed.  For example, what language is used to represent the description?

[Note]: '- SIMPLE doc handled by TSV because it modifies SIP.
- Critical for 3GPP2 - deadline was in August; moved back a mo. or so' added by Allison Mankin

[Note]: '- SIMPLE doc handled by TSV because it modifies SIP.
- Critical for 3GPP2 - deadline was in August; moved back a mo. or so ' added by Allison Mankin

IANA Last Call Comments:
Upon approval of this document the IANA will register a
New SIP Option Tag: eventlist, a new MIME type for Resource
List Meta-Information and a URN Sub-Namespace for
URI: urn:ietf:params:xml:ns:rlmi.