Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt - forking MESSAGE

["Olle E. Johansson" <[e-mail]>]

3 okt 2013 kl. 00:44 skrev Peter Saint-Andre <[e-mail]>:

>> - A SIP MESSAGE can fork. The draft doesn't mention that,
>> something that may have impact on implementations. There's a JID on
>> one side - but a forking address on the other side of this spec. -
>> A SIP MESSAGE can be delivered inside of a dialog and outside of a
>> dialog. Inside of a dialog is maybe out of scope for this draft,
>> but in that case the remote target will be a contact address, maybe
>> even a GRUU.
> 
> Hmm, and here I thought we might be able to discuss forking only in
> the media I-D. But I think you're right that we need to discuss it
> here, too. What specification has the best coverage of forking? Or is
> this part of the "oral tradition" in the SIP community?

Forking is covered in RFC 3261. Luckily there's no "early text" or that kind of issues
with forking a message - you will only get one 200 OK back (as opposed to INVITE),
which also means you will not see how many destinations that got the MESSAGE.
You can not CANCEL a MESSAGE either. You may get authentication requests as always.

RFC 4328 states:

"When one user wishes to send an instant message to another, the
   sender formulates and issues a SIP request using the new MESSAGE
   method defined by this document.  The Request-URI of this request
   will normally be the "address of record" for the recipient of the
   instant message, but it may be a device address in situations where
   the client has current information about the recipient's location."

So if you have a subscription for registration information on the AOR,
you might select a contact/GRUU to send a message too. 

It also states:

"Note that a downstream proxy could fork a MESSAGE request.  If this
   occurs, the forking proxy will forward one final response upstream,
   even though it may receive multiple final responses.  The UAC will
   have no way to detect whether or not a fork occurs.  Therefore the
   UAC MUST NOT assume that a given final response represents the only
   UAS that receives the request.  For example, multiple branches of a
   fork could have resulted in 2xx responses.  Even though the UAC only
   sees one of those responses, the request has in fact been received by
   the second device as well.
"

All of this makes MESSAGE quite a poor solution for messages you want kept private.
You don't know where it's sent and even if there's authentication on the receiving side,
anyone that gets the unauthenticated request still can access the message unless
of course there's S/MIME involved. 

Well, there was a reason MSRP was developed later. ;-)


/O