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 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.
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.
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.
Hence my confusion.
/Miguel
--
Miguel A. Garcia tel:+358-50-4804586
Nokia Siemens Networks Espoo, Finland
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
