Subject: [Gen-art] Re: Gen-ART Last Call review of draft-ietf-sip-uri-list-message-02.txt

From: Miguel Garcia <[email-masked]>
Date: Thu, 20 Dec 2007 09:43:03 +0200

Spencer:

Thanks for the review. I have edited all your comments now. I will be 
submitting a new version of this draft tomorrow.

Prelminary new version available at:
http://people.nokia.net/~miguel/drafts/draft-ietf-sip-uri-list-message-03.txt

Track changes:
http://people.nokia.net/~miguel/drafts/draft-ietf-sip-uri-list-message-03-from-2.html

See some inline discussion.

/Miguel

Spencer Dawkins wrote:
> 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."

changed as requested.

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

We discussed this in the past and th conclusion for all these set of 
drafts was to use the term "URI-List service". Changing the name in one 
draft only will make the draft to be out of sync with the rest.

>   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?

Ok, the "similar" comes from the fact that the MESSAGE sent by the 
URI-List service is not totally equal. For example, there might be 
recipient-history-list body that is not the equal to the history-list 
body. But I get your point, and the text has to say that the payload is 
the same. I will try to avoid the term "similar" as much as possible.

> 
> 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).

OK, done.

> 
>   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".

Done.

> 
>   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.

Honestly, I don't like the uppercase MUST in requirement specifications, 
because it does not much RFC 2119. So, rather than moving the text, I am 
going to turn the two capital MUST into lowercase must.

We could create a new "Requirements and background discussion" section, 
but then it is mostly an introduction, so I think the text can be kept 
where it is now.
> 
>   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...

Yes, I will add the informative reference to MSRP.

>   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?)

No. Forking is when a proxy receives a request addressed to a user and 
the proxy has several contacts for that given user. So, forking requires 
one user several contacts. Here we want something different, we want one 
message addressed to several users.

To be honest with you, I will find offending to describe what forking is 
in this document, when it is already described in RFC 3261, which is a 
normative reference for this document. This means, the reader has to be 
familiar and understand RFC 3261.

> 
> 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 

Yes, a MESSAGE URI-List service is a specialized instance of a SIP 
URI-List service. I'll change the definition accordingly.

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

The functionality is explained in the requirement. Honestly, I don't 
have a reference to add here.

> 
>      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)?

Well, we have removed the "similar" term in the abstract and 
introduction, so now we have the definition of the MESSAGE URI-List 
service and what "similar" means. We can use it from here onwards.

> 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.

Ok, I prefer the former. The latter is wrong... but that is another story.

> 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?

I think the text should be in both places, one is the general overview, 
the other is the detail section about URIs.

> 
>   Nevertheless, the XML Formats for Representing Resource Lists
> 
> Spencer (nit): I don't get "Nevertheless" here. Is it needed?

Perhaps not. Removed.

> 
>   [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.

The procedures are covered in Sections 6 and 7. Especially, the last 
paragraph in Section 7 has an answer to your concerns.

> 
> 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 server MAY ignnore it. I'll add it to Section 7 (server procedures).
> 
>   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.

I don't recall the reason why this is SHOULD/SHOULD NOT, perhaps Gonzalo 
remembers. I am suspecting that the idea is that, according to this 
specification, you MUST/MUST NOT, but if future need arises, the 
normative text can be safely relaxed. So, if you have a very good reason 
for not doing what is written... then the level should be SHOULD/SHOULD 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.

No, I refuse to write a document that reas: "According to [xxx] and 
[yyy]". This is not proper way of writing formal documents. When we have 
a document number (RFC), we can write "According to RFC xxx [xxx] and 
RFC yyy [yyy]". In the meantime, in the lack of such RFC number, we only 
have the title of the spec.

> 
>   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.

"has precedence over " means that "is invoked, and the other is never 
invoked". I guess it is clear from the context... if the server has to 
anonymize the From header, then it really anonymizes the From header, no 
matter what this specification says.

> 
>         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"?

sounds much better.

> 
>   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.

We have what we have.

Thanks for the review.

       Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 20 Dec 2007 17:01:03 -0600

Hi, Miguel,

Thanks for the quick response while I can still remember what I was thinking 
when I did the review. I think we're almost completely good. There are some 
places I'm not sure I commented clearly - let me try again.

Thanks,

Spencer

>> 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?)
>
> No. Forking is when a proxy receives a request addressed to a user and the 
> proxy has several contacts for that given user. So, forking requires one 
> user several contacts. Here we want something different, we want one 

Well, sure. Please don't include a forking tutorial :-)

Here's what I don't understand. If I put four AORs in the URI-list and send 
it to the URI-list service, where the message is sent out as four messages 
(one per AOR) - do I have this right so far? - and then a proxy forks one of 
the AORs to three three contacts, how does one of the other recipients know 
where to "Reply-To-All" including the forked recipient?

If this "just works" - perhaps because the Reply-To-All from one of the 
receipients also carries a URI-list and is also sent to the URI-list 
service, so the reply to the forked AOR is ALSO forked by the proxy and goes 
to the right place - that's fine. I just didn't get this from reading the 
document.

I was especially confused by this text,

   If the UAS supports this specification and the MESSAGE request
   contains a body with a Content-Disposition header field as per RFC
   2183 [RFC2183] set to 'recipient-list-history', then the UAS will be
   able to determine who are the other intended recipients of the
   MESSAGE request.  This allows the user to create a reply request
   (e.g., MESSAGE, INVITE) to the sender and the rest of the recipients
   included in the URI list.

which made me think the recipient was sending directly to the sender and to 
all of the other recipients. If that's not the case, perhaps the last 
sentence could explicitly mention the use of the URI-list service when doing 
Reply-to-All.

> The functionality is explained in the requirement. Honestly, I don't have 
> a reference to add here.

My apologies for saying this unclearly. What I'm saying is that the 
Reply-To-All functionality is not mentioned in any definition in the 
terminology section - I should not have said "reference to", I should have 
said "should there be some mention of".

It looks like a term, but there's no definition for it. In 03, it's only 
used twice, int the (now non-2119) requirements in the Introduction. Maybe 
it's worth rephrasing without appearing to use a term?

>> wondering why this is SHOULD/SHOULD NOT - I'd be less concerned if it was 
>> MUST/MUST NOT.
>
> specification, you MUST/MUST NOT, but if future need arises, the normative 
> text can be safely relaxed. So, if you have a very good reason for not 
> doing what is written... then the level should be SHOULD/SHOULD NOT.

I'm confused about what value SHOULD/SHOULD NOT has here - the text is 
saying that the sender ought to do something, but might not, so the receiver 
has to be prepared to do something sensible if the sender does something it 
shouldn't do.

If the intention is to be able to relax this in the future, it seems more 
reasonable to say SHOULD/SHOULD NOT for the sender, but the receiver MUST 
process requests that violate the SHOULD/SHOULD NOTs (for whatever reason). 
That would allow you to relax the normative text for the sender in the 
future, without suddenly breaking at the receiver.

Hence my confusion.

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

Well, sure, and it's not your job to slay the S/MIME dragon, but IIRC Sam 
was saying in Vancouver that he wants to stop making recommendations that no 
one plans to follow. I think you can ignore this comment unless 
Russ/Cullen/Sam raise the issue during AD review and IESG evaluation.

Thanks,

Spencer

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 21 Dec 2007 09:28:42 +0200

Spencer:

Thanks for the review. Inline discussion.

Spencer Dawkins wrote:
> Hi, Miguel,
> 
> Thanks for the quick response while I can still remember what I was 
> thinking when I did the review. I think we're almost completely good. 
> There are some places I'm not sure I commented clearly - let me try again.
> 
> 
> Thanks,
> 
> Spencer
> 
>>>
>>> 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?)
>>
>> the proxy has several contacts for that given user. So, forking 
>> requires one user several contacts. Here we want something different, 
>> we want one message addressed to several users.
>>
>> To be honest with you, I will find offending to describe what forking 
>> is in this document, when it is already described in RFC 3261, which 
>> is a normative reference for this document. This means, the reader has 
>> to be familiar and understand RFC 3261.
> 
> Here's what I don't understand. If I put four AORs in the URI-list and 
> send it to the URI-list service, where the message is sent out as four 
> messages (one per AOR) - do I have this right so far? - and then a proxy 
> forks one of the AORs to three three contacts, how does one of the other 
> recipients know where to "Reply-To-All" including the forked recipient?

Why do the other recipient need to know that one of the AORs forked? 
This is the same case in a regular one-to-one MESSAGE. If I send you a 
MESSAGE and it forks to your laptop and your cell phone, I don't really 
care about it, as long as you get the MESSAGE.

I don't see the point we are trying to achieve with this forking stuff.

Any recipient knows all the AORs that receive the message. This is the 
only requirement we have (REQ-2). Whether one of the MESSAGE requests 
forked or not is irrelevant.

> service, so the reply to the forked AOR is ALSO forked by the proxy and 
> goes to the right place - that's fine. I just didn't get this from 
> reading the document.

That is correct. Business as usual.

> which made me think the recipient was sending directly to the sender and 
> to all of the other recipients. If that's not the case, perhaps the last 
> sentence could explicitly mention the use of the URI-list service when 
> doing Reply-to-All.

Ok, clarified.

> terminology section - I should not have said "reference to", I should 
> have said "should there be some mention of".
> 
> used twice, int the (now non-2119) requirements in the Introduction. 
> Maybe it's worth rephrasing without appearing to use a term?

Better. I have added a definition of Reply-To-All in the definition. It 
is used a few times later, so better to promote the term to the 
definitions section.

>> I don't recall the reason why this is SHOULD/SHOULD NOT, perhaps 
>> Gonzalo remembers. I am suspecting that the idea is that, according to 
>> this specification, you MUST/MUST NOT, but if future need arises, the 
>> normative text can be safely relaxed. So, if you have a very good 
>> reason for not doing what is written... then the level should be 
>> SHOULD/SHOULD NOT.
> 
> saying that the sender ought to do something, but might not, so the 
> receiver has to be prepared to do something sensible if the sender does 
> something it shouldn't do.

Remember here that the receiver has a full implementation of resource 
lists. We are saying that for the time being, there is no usage for some 
of the extra capabilities that resource lists offer. Still, due the full 
implementation of resource lists, the receiver is able to receive a 
hierarchical list and parse it.

> If the intention is to be able to relax this in the future, it seems 
> more reasonable to say SHOULD/SHOULD NOT for the sender, but the 
> receiver MUST process requests that violate the SHOULD/SHOULD NOTs (for 
> whatever reason). That would allow you to relax the normative text for 
> the sender in the future, without suddenly breaking at the receiver.

But the receiver does not have to violate anything. Simply, there is no 
use case for hierarchical lists, so it will simply ignore the hierarchy. 
It is not a violation.

/Miguel

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 21 Dec 2007 07:44:36 -0600

Hi, Miguel,

I think we're good, at this point. My biggest concern was about the 
interaction of URI-lists with forking, because I did not understand from the 
text that Reply-to-All also used URI-lists to return the replies. With this 
clarification, I'm a lot more comfortable with the specification.

Thanks!

Spencer

>>>> 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?)
>>>
> Why do the other recipient need to know that one of the AORs forked? This 
> is the same case in a regular one-to-one MESSAGE. If I send you a MESSAGE 
> and it forks to your laptop and your cell phone, I don't really care about 
> it, as long as you get the MESSAGE.
>
> Better. I have added a definition of Reply-To-All in the definition. It is 
> used a few times later, so better to promote the term to the definitions 
> section.
>
>>
>> process requests that violate the SHOULD/SHOULD NOTs (for whatever 
>> reason). That would allow you to relax the normative text for the sender 
>> in the future, without suddenly breaking at the receiver.
>