Gen-ART Last Call review of draft-ietf-sip-uri-list-message-02.txt

[Spencer Dawkins <spencer at mcsr-labs.org>]

Document: draft-ietf-sip-uri-list-message-02.txt
Reviewer: Spencer Dawkins
Review Date: 2007-11-28
IETF LC End Date: 2007-12-10
IESG Telechat date: (not known)

Summary: This document is on the right track for publication as a Proposed 
Standard, but some open issues remain (see comments).

Comments:

I have a lot of comments, but most are about the document, not about the 
protocol.

I have substantive comments (s/Spencer:/), plus comments about clarity and 
nits that are not part of the Gen-ART review, but are included for editor 
convenience.

My biggest concern is about the interaction of "replying to all other 
recipients" with forking proxies located downstream (maybe this isn't a 
problem, and if it is, it may not be a big one, but I'd like to see some 
discussion about it - there's not any that I could find).

There's a lot more text about requests than about one-to-many responses - 
responses aren't included in the terminology section at all, for example. 
Are the parts of the spec that covers responses as baked as the parts that 
cover requests?

I have some fairly dramatic (but not complex) suggestions about document 
structure (for example, move the 2119 language in the introduction to its 
own section, located somewhere after the 2119 boilerplate.

Thanks,

Spencer

Abstract

  This document specifies a mechanism that allows a SIP User Agent
  Client (UAC) to request a SIP URI-list (Uniform Resource Identifier
  list) service to send a SIP MESSAGE request to a set of destinations.

Spencer (clarity): this sentence is correct but doesn't parse well for me. 
Suggest "This document specifies a mechanism that allows a SIP User Agent 
Client (UAC) to send a SIP MESSAGE request to a set of destinations, by 
using a SIP URI-list (Uniform Resource Identifier list) service."

Spencer: would the name "SIP URI-list exploder service" more clearly match 
similar functionality in e-mail, etc.?

  The client sends a SIP MESSAGE request that includes the payload
  along with the URI-list to the MESSAGE URI-list service, which sends
  a similar MESSAGE request to each of the URIs included in the list.

Spencer (clarity): "similar" isn't precise - the document later defines 
"similar" as "contains a copy of the body included in the original MESSAGE 
request", so maybe s/similar/copy of the body included in the original 
MESSGAGE request/ here, and maybe even dropping "similar" later in the 
document?

1.  Introduction

  RFC 3261 (SIP) [RFC3261] is extended by RFC 3428 [RFC3428] to carry

Spencer (clarity): I appreciate your clues on RFC references ("SIP"), and 
suggest that you provide "(SIP extension for instant messaging)" for RFC 
3428 (even *I* remember what 3261 is, but was guessing at 3428 until I 
looked).

  instant messages in MESSAGE requests.  One of the aspects of MESSAGE
  requests according to RFC 3428 [RFC3428] is the lack of support for

Spencer (clarity): this text confuses me (it seems to say that 3428 
explicitly says there's no support for this, but I can't find that anywhere 
in 3428 - the closest thing is in the second paragraph of section 2, which 
is describing the generic pager model, not MESSAGE). Suggest replacing with 
"SIP-based messaging, as described in RFC 3428, does not provide a mechanism 
to send the same request to multiple recipients, or replying to all 
recipients of a SIP MESSAGE request. This memo addresses these functions".

  sending the same request to multiple recipients and replying to all
  recipients of a SIP MESSAGE request.  This memo addresses these
  functions.

Spencer: I am surprised to see requirements expressed using 2119 language in 
the Introduction (and before the 2119 boilerplate, which is in the 
Terminology section). My suggestion is to move the rest of this section to a 
new section, following Terminology.

  A first requirement can be expressed as:

     REQ-1: It MUST be possible for a user to send an instant message
     request to an ad-hoc group, where the identities of the recipients
     are carried in the message itself.

  One possibility to fulfill the above requirement is to establish a
  session of instant messages with an instant messaging conference

Spencer: should this have an informative reference to RFC 4975? and maybe 
say "MSRP session" explicitly? unless you are talking about something 
else...

  server.  While this option seems to be reasonable in many cases, in
  other situations the sending user just wants to send a small page-
  mode instant message to an ad-hoc group without the burden of setting
  up a session.  This document focuses on sending a page-mode instant
  message to a number of intended recipients.

  A second requirement addresses the "Reply-to-All" functionality:

     REQ-2: It MUST be possible for the recipient of a group instant
     message to send a message to all other participants that received
     the same group instant message (i.e., Reply-To-All).

Spencer: RFC 3428 explicitly allows proxies to fork MESSAGE requests (in 
section 6) and normal proxy processing applies (you get one response back 
from the proxy, even if there were multiple successful deliveries). Will 
this mechanism meet this requirement, even if there are forking proxies 
downstream from the URI-list service? (I don't see the word "fork" in this 
document at all - should I be worried?)

2.  Terminology

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in BCP 14, RFC 2119
  [RFC2119] and indicate requirement levels for compliant
  implementations.

  MESSAGE URI-list service:  SIP application service that receives a

Spencer (nit): it would be nice to be consistent between "SIP URI-list 
service", "MESSAGE URI-list service", and any other variants you find... are 
these all the same thing, in this document?

Spencer: should there be some reference to the respond-to-all functionality 
in this definition?

     MESSAGE request with a URI-list and sends a similar MESSAGE
     request to each URI in the list.  In this context, similar
     indicates that some SIP header fields can change, but the MESSAGE
     URI-list service will not change the instant message payload.
     MESSAGE URI-list services behave effectively as specialised B2BUAs

Spencer (clarity): this is a useful hint - perhaps it could be stated 
explicitly in the early parts of the document (Abstract, Introduction)?

     (Back-To-Back-User-Agents).  A server providing MESSAGE URI-list
     services can also offer URI-list services for other methods,
     although this functionality is outside the scope of this document.
     In this document we only discuss MESSAGE URI-list services.

3.  Overview

  A UAC creates a MESSAGE request that contains a multipart body
  including a list of URIs (intended recipients) and an instant
  message.  The list of URIs is formatted according to the XML Formats

Spencer (nit): this text would be easier to read if you either put quotes 
around document titles or just used the references with no titles 
("according to [RFC4826]"). Your choice.

  for Representing Resource List [RFC4826] and extended with the
  attributes defined in the XML Format Extension for Representing Copy
  Control Attributes in Resource Lists
  [I-D.ietf-sipping-capacity-attribute].  The UAC sends this MESSAGE
  request to the MESSAGE URI-list service.  On reception of this
  incoming MESSAGE request, the MESSAGE URI-list service creates a
  MESSAGE request per intended recipient (listed in the URI-list) and
  copies the instant message payload to each of those MESSAGES.  The
  MESSAGE URI-list service also manipulates the XML resource list
  according to the procedures indicated in the XML Format Extension for
  Representing Copy Control Attributes in Resource Lists
  [I-D.ietf-sipping-capacity-attribute], and attaches the result to
  each of the MESSAGE requests, along with the instant message payload.
  Then the MESSAGE URI-list service sends each of the created outgoing
  MESSAGE request to the respective receiver.

4.  URI-List document

  As described in the XML Format Extension for Representing Copy
  Control Attributes in Resource Lists
  [I-D.ietf-sipping-capacity-attribute], each URI can be tagged with a
  'copyControl' attribute set to either "to", "cc", or "bcc",
  indicating the role in which the recipient will get the MESSAGE
  request.  Additionally, URIs can be tagged with the 'anonymize'
  attribute to prevent that the MESSAGE URI-list server discloses the
  target URI in a URI-list.

Spencer (clarity): the previous text largely restates what's in the Overview 
section, with some additional detail, but not a lot. Could it be one place 
or the other?

  Nevertheless, the XML Formats for Representing Resource Lists

Spencer (nit): I don't get "Nevertheless" here. Is it needed?

  [RFC4826] document provides features, such as hierarchical lists and
  the ability to include entries by reference relative to the XCAP root
  URI, that are not needed by the MESSAGE URI-list service defined in
  this document, which only needs to transfer a flat list of URIs
  between a UA (User Agent) and the MESSAGE URI-list server.

Spencer: I'm confused here. Are you telling people they don't need to 
implement parts of the specification? ([RFC4826] is a Proposed Standard - 
what happens if a UAC DOES send a URI-list with a hierarchy?) Maybe this is 
explained sufficiently at the end of Section 6, but at the very least, 
there's duplicated text between this paragraph and section 6.

6.  Procedures at the User Agent Client

  Typically, the MESSAGE URI-list service will copy all the significant
  header fields in the outgoing MESSAGE request.  However, there might
  be cases where the SIP UA wants the MESSAGE URI-list service to add a
  particular header field with a particular value, even if the header
  field wasn't present in the MESSAGE request sent by the UAC.  In this
  case, the UAC MAY use the "?" mechanism described in Section 19.1.1
  of RFC 3261 [RFC3261] to encode extra information in any URI in the
  list.  However, the UAC MUST NOT use the special "body" hname (see
  Section 19.1.1 of RFC 3261 [RFC3261]) to encode a body, since the
  body is present in the MESSAGE request itself.

Spencer: is it clear what response is returned to a UAC that does use the 
"body" hname?

  The XML Format for Representing Resource Lists [RFC4826] document
  provides features, such as hierarchical lists and the ability to
  include entries by reference relative to the XCAP root URI.  However,
  these features are not needed by the multiple MESSAGE URI-List
  service defined in this document.Therefore, when using the default
  resource list document, UAs SHOULD use flat lists (i.e., no
  hierarchical lists) and SHOULD NOT use <entry-ref> elements.

Spencer: see previous concerns about similar text above, but now I'm 
wondering why this is SHOULD/SHOULD NOT - I'd be less concerned if it was 
MUST/MUST NOT.

7.1.  Determining the intended recipient

  Section 4.1 of the Framework and Security Considerations for SIP URI-

Spencer (nit): In addition to my previous suggestion about quoting document 
titles, etc. I would also love to see the document titles omitted when the 
same document is referenced twice in two consecutive sentences :-) - just 
"[ref]" would be sufficient.

  List Services [I-D.ietf-sipping-uri-services] discusses cases when
  duplicated URIs are found in a URI-list.  In order to avoid
  duplicated requests, MESSAGE URI-list services MUST take those
  actions specified in Framework and Security Considerations for SIP
  URI-List Services [I-D.ietf-sipping-uri-services] into account to
  avoid sending duplicated request to the same recipient.

7.2.  Creating an outgoing MESSAGE request

        Failing to copy the From header field of the sender would
        prevent the recipient to get a hint of the sender's identity.
        Note also that this requirement does not intend to contradict
        requirements for additional services running on the same
        physical node.  Specifically, a privacy service (see RFC 3323
        [RFC3323]) can be co-located with the MESSAGE URI-list service,
        in which case, the privacy service has precedence over the

Spencer: does "has precedence over" mean "is invoked before"? If not, I'm 
not sure what it does mean.

        MESSAGE URI-list service.

7.3.  Composing bodies in the outgoing MESSAGE request

  When creating the body of each of the outgoing MESSAGE requests, the
  MESSAGE URI-list service tries to keep the relevant bodies of the

Spencer: "tries to keep"? something like "keeps, except for the following 
exceptions"?

  incoming MESSAGE request and copies them to the outgoing MESSAGE
  request.  The following guidelines are provided:

  o  If a MESSAGE URI-list service includes a URI-list in an outgoing
     MESSAGE request, it SHOULD use S/MIME (RFC 3851) [RFC3851] to
     encrypt the URI-list with the public key of the receiver.

Spencer: I note that this is an S/MIME SHOULD in 2007... mumble. 



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf