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?
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.
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?
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.
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.
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.
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art