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

Peter Saint-Andre <> Thu, 17 October 2013 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6912821F9D17 for <>; Wed, 16 Oct 2013 20:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.924
X-Spam-Status: No, score=-101.924 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4XWCHqHUuerJ for <>; Wed, 16 Oct 2013 20:21:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 71EB021F9CA8 for <>; Wed, 16 Oct 2013 20:21:37 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 53C5D4101A for <>; Wed, 16 Oct 2013 21:27:59 -0600 (MDT)
Message-ID: <>
Date: Wed, 16 Oct 2013 21:21:36 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt - forking MESSAGE
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Oct 2013 03:21:47 -0000

On 10/03/2013 12:32 AM, Olle E. Johansson wrote:
> 3 okt 2013 kl. 00:44 skrev Peter Saint-Andre <>im>:
>>> - 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.
> "

Thanks for the clarifications! I'll work to incorporate some of those
insights into the -im document.

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

"If at first you don't succeed..."

Mind you, we've had our share of failed extensions in the XMPP commuity,