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
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
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.
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?
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.
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.
That is correct. Business as usual.
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.
Ok, clarified.
MESSAGE URI-list service: SIP application service that receives a
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.
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?
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.
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
