Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt - forking MESSAGE
Peter Saint-Andre <stpeter@stpeter.im> Thu, 17 October 2013 03:21 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6912821F9D17 for <stox@ietfa.amsl.com>; Wed, 16 Oct 2013 20:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.924
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XWCHqHUuerJ for <stox@ietfa.amsl.com>; Wed, 16 Oct 2013 20:21:41 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB021F9CA8 for <stox@ietf.org>; Wed, 16 Oct 2013 20:21:37 -0700 (PDT)
Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 53C5D4101A for <stox@ietf.org>; Wed, 16 Oct 2013 21:27:59 -0600 (MDT)
Message-ID: <525F57C0.3020809@stpeter.im>
Date: Wed, 16 Oct 2013 21:21:36 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: stox@ietf.org
References: <20130930215620.31558.59064.idtracker@ietfa.amsl.com> <524A7056.20900@gmail.com> <EBF04D25-027D-4C5C-BF14-0D51A215587D@edvina.net> <524CA1CD.2060301@stpeter.im> <31791EBC-47AE-4CF4-B3DB-D9991CDF51A4@edvina.net>
In-Reply-To: <31791EBC-47AE-4CF4-B3DB-D9991CDF51A4@edvina.net>
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-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=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 <stpeter@stpeter.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. Indeed. > 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, too. Peter
- [Stox] I-D Action: draft-ietf-stox-im-04.txt internet-drafts
- Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt Daniel-Constantin Mierla
- Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt Olle E. Johansson
- Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt Peter Saint-Andre
- Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt … Olle E. Johansson
- Re: [Stox] I-D Action: draft-ietf-stox-im-04.txt … Peter Saint-Andre