From nobody Tue Nov 4 15:53:41 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E071A1A83 for ; Tue, 4 Nov 2014 15:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ad1XNNv63Gm3 for ; Tue, 4 Nov 2014 15:53:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DC01A0394 for ; Tue, 4 Nov 2014 15:53:36 -0800 (PST) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA4NrYan006817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2014 17:53:35 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] From: Ben Campbell Content-Type: text/plain; charset=us-ascii X-Mao-Original-Outgoing-Id: 436838014.408434-038e0f674af6164c9f169a2798e772de Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Message-Id: Date: Tue, 4 Nov 2014 17:53:34 -0600 To: draft-ietf-stox-groupchat.all@tools.ietf.org, stox@ietf.org X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/stox/1SABTm0JzGLIP_Y833WOqCfhejU Subject: [Stox] Very belated review of draft-ietf-stox-groupchat-07 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 04 Nov 2014 23:53:39 -0000 Hi, First, let me say that groupchat-07 is a far better document than when I = last reviewed it (I think that was 07.) This version cleans up most of = the architectural confusion from the older version. It's so much more = understandable, that I found some new (to me) issues ;-) I apologize in = advance if any of these have already been discussed and I missed it: *** Major Issues: -- Section 6:=20 When Romeo (a SIP user) joins the capulet chatroom (an XMPP group chat), = what prevents Romeo's client from bypassing his own SIP proxy and trying = to directly find a SIP service at example.com? This is to some degree an = RFC7247 issue, where we assume that a SIP server knows to send stuff = through a SIP-XMPP gateway. The problem is, SIP doesn't actually require = a UAC to route requests through it's own proxy. Now, I recognize that in _practice_, the UAC will almost only route = outbound requests through its own server for NAT traversal and/or = authentication reasons(perhaps using the SIP outbound mechanism). But = that's not a 3261 requirement. If this draft wants to assume that this = will always happen, that's probably ok--but it should mention that = explicitly, and perhaps mention that if SIP clients do not use outbound = SIP services, this approach may not work. (Or alternately, the client = itself needs to know to route things through gateways...) Related Question: Is there a use case for when a SIP service does not = have a gateway, and just sends SIP to a gateway at the XMPP domain? If = so, that would not seem to need the assumption that a SIP client always = uses an outbound proxy. -- Also Section 6: If I read things correctly, the actual joining of the MUC is a = consequence of the SIP user subscribing to the conference event package. = But that subscription is not normatively required for simple-chat = implementations. The simple-chat draft only says that clients = "typically" will do so. So unless you want to make a normative = requirement for simple-chat clients to do so in order to work with = stox-groupchat, you cannot depend on that subscription to trigger the = presence interchange. -- Section 9: The draft says that it that it introduces no new security = considerations. But there must be some assumptions about user = identities, authentication and trust. These probably should have been in = RFC7247, but I don't find them there on a quick scan. *** Minor Issues: -- general: There's a fair amount of 2119 normative language that really repeats = statements from the other protocols (SIP, MSRP, XMPP, etc.). Please = consider avoiding 2119 language when talking about how one of those = protocols works, unless you are creating some new requirement that = doesn't already exist for that protocol. -- section 2: The draft lists MSPR (RFC 4975) as a groupchat related spec. It's really = not; that should probably reference simple-chat. (It would make sense to = add RFC4975 to the "We assume readers are familiar..." list.) -- section 3 (and the flow diagrams) You indicate that you will use the same diagram convention for SIP and = MSRP traffic. I suggest you distinguish between the two; they are = completely separate (if loosely related) protocols. -- section 4, "... MSRP groupchat sessions are considered to be a type = of media ..." That's true for MSRP in _general_, not just for group chat. -- Figure 1: I would not assume a direct app-specific connection or flow = between the SIP proxy and the MSRP switch. It may exist, but it's = equally valid that all such interactions would be intermediated by the = focus. (And it doesn't seem to be needed by anything else in this = draft.) -- Section 5: It's worth mentioning that any SIP provisional responses have been left = off for the sake of simplicity. In F6, there should really be an MSRP SEND request that happens before = the nickname request. RFC4975 requires an immediate SEND request by the = active party. It can be empty if you aren't ready to send a real message = yet. (There might should be some guidance about not accidentally = creating a privacy leak by sending a real message prior to setting a = nickname.) F28: There's work going on in SIPCORE to change the way REFER requests = handle notifies (See draft-sparks-sipcore-refere-clarifications and = draft-sparks-sipcore-refer-explicit-subscription). There probably don't = need to block anything here, but it might be worth a footnote to say = that, at the time of this writing, work is happening that might change = this part of the flow.) -- section 5.1, example 2: It's unlikely that a SIP UAC is going to generate a gruu tag with a = value as neat as "balcony". Unlike XMPP, SIP doesn't typically use human = readable identifiers to distinguish devices (analogous to XMPP = resources.) More likely that will be random string assigned by the = registrar. (It's not _wrong_ as stated, but it might mislead = implementors.) -- section 5.1, table 1: Do I understand correctly that you could have more than one = element over the course of a MUC? For the SIP/MSRP user, the Call-ID = will stay the same for the life of the session. Also, the call-id will = be unique for each SIP participant; I assume that's not true for = . -- Example 3: The 200 has the =46rom and To wrong. Responses do not swap the from and = to from the original request. They should be identical to the original, = with the possible exception of the "to" tag. (I think this repeats = throughout the draft.) -- Example 8: Inconsistent use of Allow header fields. I would probably leave them out = except where required, but others may have other opinions. -- section 5.4: first paragraph First part of the paragraph seems to belong in 5.3. It might make sense = to combined 5.3 and 5.4 into one section. -- 5.5.2: Second Paragraph: Maybe this paragraph should belong in the section about the original = INVITE? -- section 6, F42-44? If the initial SEND in F42 was empty, would F44 and 45 still happen? Can = F44 and F45 fail? -- 6.1, paragraph before example 28: What if the MSRP user never sets a nick at all? 6.3.1, last paragraph: How do you determine "sameness" between stanzas in this context? -- 7, 3rd paragraph: "In SIP, the nickname..." s/SIP/" the SIP conference event package" -- 7, 2nd to last paragraph: I'm confused by this--I can see saying to display the contents of = or the JID resource part if the respective xcon element = or element are not present, but this seems to suggest one should = ignore them if they are present. Is that the intent? From nobody Wed Nov 5 19:38:58 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5CC1A02F1 for ; Wed, 5 Nov 2014 19:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_cwLzqqouFu for ; Wed, 5 Nov 2014 19:38:54 -0800 (PST) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38851A0248 for ; Wed, 5 Nov 2014 19:38:54 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id x19so2155545ier.33 for ; Wed, 05 Nov 2014 19:38:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oDc6BIlq9gFi4wBxcIsSYIU0bpJUOz/KfebIUKDOHMw=; b=S+O/HIPnDy16yvOeFkVsBOOiHLxxSmGo8KRu5YZ6uvhDefTtKff4M4qbLm409BbPVG W72Bl13TJN4pvBNKawHfpn09JSX1qfpGCRqVZWxSOoPjyX9l2NaFmx7osIHH/m3IqoDn t6Gvao8D9dekaVurUy2CPPWONzC4Z961vI0oVNT/leaa2C4tFPll2YJkSrDvRLAvsChG StgEnovTEKOiKffXWZd7YN5nFcJGXMCqqpACRygao6HZA/zvqJfhHEDjgyumY3xHslzZ OglDpl/8gLGerxF8/CbST6/9bKXsbz3UyLgZey4ge1sczjkLnIdEBefv1YtCYO4T7U9U YKHg== X-Gm-Message-State: ALoCoQlRFNhPKFdO6aM3Uq6PgLc1wRftw8peMK3JDWNT81XQyv7z/sTGtuUt+G/ZJlJlvKmZA3Qf X-Received: by 10.107.157.11 with SMTP id g11mr1642318ioe.5.1415245134050; Wed, 05 Nov 2014 19:38:54 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id dy3sm2138048igb.1.2014.11.05.19.38.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 19:38:53 -0800 (PST) Message-ID: <545AED4C.8060503@andyet.net> Date: Wed, 05 Nov 2014 20:38:52 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/777EfLVHLxb5vZLeEhltluGHDoY Cc: stox@ietf.org Subject: Re: [Stox] Very belated review of draft-ietf-stox-groupchat-07 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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, 06 Nov 2014 03:38:57 -0000 Hi Ben, Thank you very much for the in-depth feedback. I'll carve out some time soon to review and reply (probably next week). Peter On 11/4/14, 4:53 PM, Ben Campbell wrote: > Hi, > > First, let me say that groupchat-07 is a far better document than when I last reviewed it (I think that was 07.) This version cleans up most of the architectural confusion from the older version. It's so much more understandable, that I found some new (to me) issues ;-) I apologize in advance if any of these have already been discussed and I missed it: > > > *** Major Issues: > > -- Section 6: > > When Romeo (a SIP user) joins the capulet chatroom (an XMPP group chat), what prevents Romeo's client from bypassing his own SIP proxy and trying to directly find a SIP service at example.com? This is to some degree an RFC7247 issue, where we assume that a SIP server knows to send stuff through a SIP-XMPP gateway. The problem is, SIP doesn't actually require a UAC to route requests through it's own proxy. > > Now, I recognize that in _practice_, the UAC will almost only route outbound requests through its own server for NAT traversal and/or authentication reasons(perhaps using the SIP outbound mechanism). But that's not a 3261 requirement. If this draft wants to assume that this will always happen, that's probably ok--but it should mention that explicitly, and perhaps mention that if SIP clients do not use outbound SIP services, this approach may not work. (Or alternately, the client itself needs to know to route things through gateways...) > > Related Question: Is there a use case for when a SIP service does not have a gateway, and just sends SIP to a gateway at the XMPP domain? If so, that would not seem to need the assumption that a SIP client always uses an outbound proxy. > > -- Also Section 6: > > If I read things correctly, the actual joining of the MUC is a consequence of the SIP user subscribing to the conference event package. But that subscription is not normatively required for simple-chat implementations. The simple-chat draft only says that clients "typically" will do so. So unless you want to make a normative requirement for simple-chat clients to do so in order to work with stox-groupchat, you cannot depend on that subscription to trigger the presence interchange. > > -- Section 9: > > The draft says that it that it introduces no new security considerations. But there must be some assumptions about user identities, authentication and trust. These probably should have been in RFC7247, but I don't find them there on a quick scan. > > *** Minor Issues: > > -- general: > > There's a fair amount of 2119 normative language that really repeats statements from the other protocols (SIP, MSRP, XMPP, etc.). Please consider avoiding 2119 language when talking about how one of those protocols works, unless you are creating some new requirement that doesn't already exist for that protocol. > > -- section 2: > > The draft lists MSPR (RFC 4975) as a groupchat related spec. It's really not; that should probably reference simple-chat. (It would make sense to add RFC4975 to the "We assume readers are familiar..." list.) > > -- section 3 (and the flow diagrams) > > You indicate that you will use the same diagram convention for SIP and MSRP traffic. I suggest you distinguish between the two; they are completely separate (if loosely related) protocols. > > -- section 4, "... MSRP groupchat sessions are considered to be a type of media ..." > > That's true for MSRP in _general_, not just for group chat. > > -- Figure 1: I would not assume a direct app-specific connection or flow between the SIP proxy and the MSRP switch. It may exist, but it's equally valid that all such interactions would be intermediated by the focus. (And it doesn't seem to be needed by anything else in this draft.) > > -- Section 5: > > It's worth mentioning that any SIP provisional responses have been left off for the sake of simplicity. > > In F6, there should really be an MSRP SEND request that happens before the nickname request. RFC4975 requires an immediate SEND request by the active party. It can be empty if you aren't ready to send a real message yet. (There might should be some guidance about not accidentally creating a privacy leak by sending a real message prior to setting a nickname.) > > F28: There's work going on in SIPCORE to change the way REFER requests handle notifies (See draft-sparks-sipcore-refere-clarifications and draft-sparks-sipcore-refer-explicit-subscription). There probably don't need to block anything here, but it might be worth a footnote to say that, at the time of this writing, work is happening that might change this part of the flow.) > > -- section 5.1, example 2: > > It's unlikely that a SIP UAC is going to generate a gruu tag with a value as neat as "balcony". Unlike XMPP, SIP doesn't typically use human readable identifiers to distinguish devices (analogous to XMPP resources.) More likely that will be random string assigned by the registrar. (It's not _wrong_ as stated, but it might mislead implementors.) > > -- section 5.1, table 1: > > Do I understand correctly that you could have more than one element over the course of a MUC? For the SIP/MSRP user, the Call-ID will stay the same for the life of the session. Also, the call-id will be unique for each SIP participant; I assume that's not true for . > > -- Example 3: > > The 200 has the From and To wrong. Responses do not swap the from and to from the original request. They should be identical to the original, with the possible exception of the "to" tag. (I think this repeats throughout the draft.) > > -- Example 8: > > Inconsistent use of Allow header fields. I would probably leave them out except where required, but others may have other opinions. > > -- section 5.4: first paragraph > > First part of the paragraph seems to belong in 5.3. It might make sense to combined 5.3 and 5.4 into one section. > > -- 5.5.2: Second Paragraph: > > Maybe this paragraph should belong in the section about the original INVITE? > > -- section 6, F42-44? > > If the initial SEND in F42 was empty, would F44 and 45 still happen? Can F44 and F45 fail? > > -- 6.1, paragraph before example 28: > > What if the MSRP user never sets a nick at all? > > 6.3.1, last paragraph: > > How do you determine "sameness" between stanzas in this context? > > -- 7, 3rd paragraph: "In SIP, the nickname..." > > s/SIP/" the SIP conference event package" > > -- 7, 2nd to last paragraph: > > I'm confused by this--I can see saying to display the contents of or the JID resource part if the respective xcon element or element are not present, but this seems to suggest one should ignore them if they are present. Is that the intent? > From nobody Fri Nov 14 18:20:39 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4E1A0687 for ; Fri, 14 Nov 2014 18:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOJ3URHPQJiP for ; Fri, 14 Nov 2014 18:20:32 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E272A1A03B3 for ; Fri, 14 Nov 2014 18:20:31 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so2544070igd.7 for ; Fri, 14 Nov 2014 18:20:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l2Vkg0n6giagQRAj2Ei15huMiFN0etvKZfpnaBtduKQ=; b=L3jZTxyg9UOzAVHrZ2XQcYEUZZS6Ff8bQfxrqtB9G6NTecfb5mqV4vsoFU1deXlz9N auOhI+QfWWBFpnbv7ZeQjU1Wokdsk/YG0UeXXGIXC2w3Zqb4i71U/soczXI67dfz0g5w dLVtXD7MXD+HfcCUsxa68JqOD7xYvJBlX3PDpJ1p2yhx042px7J7Llj4Lzu62+3EsGuv NhRGhSOHHkhAjxpBArHMtTRVm2I7k2al9B26pUswns9aRerVZ4B74F9tUwKx/S5bZKwl +VfpXsWK6T2pMFJyDbZ/we4T7uKUpZovEAj+6HXi4uPRNsNUom7VE+bzJ2PopOZfA4XR hpxg== X-Gm-Message-State: ALoCoQkYSRHs89wfAJn1TsM+ZwdOGtZv7q5gpl0oO1OnyILrsZQQNGifQBe1VY3nakcAeQ2bkYES X-Received: by 10.107.28.131 with SMTP id c125mr14240465ioc.29.1416018031261; Fri, 14 Nov 2014 18:20:31 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id au2sm2233708igc.4.2014.11.14.18.20.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 18:20:30 -0800 (PST) Message-ID: <5466B86C.5090004@andyet.net> Date: Fri, 14 Nov 2014 19:20:28 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-stox-groupchat.all@tools.ietf.org, stox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/kVRxtd9bJrDFqfWOwZ6BN6SQdJU Subject: Re: [Stox] Very belated review of draft-ietf-stox-groupchat-07 X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 15 Nov 2014 02:20:37 -0000 Hi Ben, thanks for the review. Comments inline. On 11/4/14, 4:53 PM, Ben Campbell wrote: > Hi, > > First, let me say that groupchat-07 is a far better document than > when I last reviewed it I'm happy to hear it. > (I think that was 07.) This version cleans up most of the > architectural confusion from the older version. It's so much more > understandable, that I found some new (to me) issues ;-) It happens. :-) > I apologize in advance if any of these have already been discussed > and I missed it: > > > *** Major Issues: > > -- Section 6: > > When Romeo (a SIP user) joins the capulet chatroom (an XMPP group > chat), what prevents Romeo's client from bypassing his own SIP proxy > and trying to directly find a SIP service at example.com? This is to > some degree an RFC7247 issue, where we assume that a SIP server knows > to send stuff through a SIP-XMPP gateway. The problem is, SIP doesn't > actually require a UAC to route requests through it's own proxy. Yes, I can see that. (This document clearly reflects the fact that I don't know SIP as well as I know XMPP.) > Now, I recognize that in _practice_, the UAC will almost only route > outbound requests through its own server for NAT traversal and/or > authentication reasons(perhaps using the SIP outbound mechanism). But > that's not a 3261 requirement. If this draft wants to assume that > this will always happen, that's probably ok--but it should mention > that explicitly, I think it's really just a simplifying assumption for this document (e.g., it's not easy to illustrate every possible deployment architecture or communication path). But I agree with you that we need to make this explicit. > and perhaps mention that if SIP clients do not use > outbound SIP services, this approach may not work. Good point. > (Or alternately, > the client itself needs to know to route things through gateways...) That seems unlikely in practice, especially if an end user would need to configure the SIP UA with a gateway address. > Related Question: Is there a use case for when a SIP service does not > have a gateway, and just sends SIP to a gateway at the XMPP domain? Again as a simplifying assumption, we've described the gateways as components that are associated with the sending domain (thus a SIP service would have a SIP-to-XMPP gateway for outbound traffic, and an XMPP service would have an XMPP-to-SIP gateway for outbound traffic). But nothing prevents services from having inbound gateways and in practice some services do host such gateways. As you say, this is really an RFC 7247 issue. (Sometimes I want to go back and revise both RFC 7247 and RFC 7248!) However, it does seem that we might want to make this crystal clear in this document. > If so, that would not seem to need the assumption that a SIP client > always uses an outbound proxy. Right. > -- Also Section 6: > > If I read things correctly, the actual joining of the MUC is a > consequence of the SIP user subscribing to the conference event > package. But that subscription is not normatively required for > simple-chat implementations. The simple-chat draft only says that > clients "typically" will do so. So unless you want to make a > normative requirement for simple-chat clients to do so in order to > work with stox-groupchat, you cannot depend on that subscription to > trigger the presence interchange. Hmm, this is a bit of a conundrum. I had indeed noticed the "typically" language in simple-chat. And I certainly don't want to place a normative requirement on simple-chat implementations. On the other hand, in XMPP multi-user chat what the client does is best mapped to a subscription construct. The mapping document under consideration could be worded better, but the way I see it the XMPP-to-SIP gateway needs to send a conference event package subscription only if it wants to receive presence notifications back from the MSRP switch (Sections 5.3 & 5.4). And similarly in the other direction (Sections 6.1 & 6.2). It's not clear to me how either side would be able to receive presence notifications without such a subscription, and those notifications are quite helpful in the context of a groupchat channel. But I don't think they are absolutely required. > -- Section 9: > > The draft says that it that it introduces no new security > considerations. But there must be some assumptions about user > identities, authentication and trust. These probably should have been > in RFC7247, but I don't find them there on a quick scan. Would you mind expanding on those points a bit more deeply? > *** Minor Issues: > > -- general: > > There's a fair amount of 2119 normative language that really repeats > statements from the other protocols (SIP, MSRP, XMPP, etc.). Please > consider avoiding 2119 language when talking about how one of those > protocols works, unless you are creating some new requirement that > doesn't already exist for that protocol. Good point, we'll scrub the text in that regard. > -- section 2: > > The draft lists MSPR (RFC 4975) as a groupchat related spec. It's > really not; that should probably reference simple-chat. (It would > make sense to add RFC4975 to the "We assume readers are familiar..." > list.) Agreed. > -- section 3 (and the flow diagrams) > > You indicate that you will use the same diagram convention for SIP > and MSRP traffic. I suggest you distinguish between the two; they are > completely separate (if loosely related) protocols. In the diagrams we use separate conventions: Legend: . = XMPP % = MSRP * = SIP & = app-specific So we'll fix that text. > -- section 4, "... MSRP groupchat sessions are considered to be a > type of media ..." > > That's true for MSRP in _general_, not just for group chat. True. Will adjust. > -- Figure 1: I would not assume a direct app-specific connection or > flow between the SIP proxy and the MSRP switch. It may exist, but > it's equally valid that all such interactions would be intermediated > by the focus. (And it doesn't seem to be needed by anything else in > this draft.) I suppose that by "app-specific" we meant that it's not standardized (any particular implementation could use whatever method it deems best). > -- Section 5: > > It's worth mentioning that any SIP provisional responses have been > left off for the sake of simplicity. Ah, I thought we'd added that. Will fix. > In F6, there should really be an MSRP SEND request that happens > before the nickname request. RFC4975 requires an immediate SEND > request by the active party. It can be empty if you aren't ready to > send a real message yet. (There might should be some guidance about > not accidentally creating a privacy leak by sending a real message > prior to setting a nickname.) Will fix. > F28: There's work going on in SIPCORE to change the way REFER > requests handle notifies (See > draft-sparks-sipcore-refere-clarifications and > draft-sparks-sipcore-refer-explicit-subscription). There probably > don't need to block anything here, but it might be worth a footnote > to say that, at the time of this writing, work is happening that > might change this part of the flow.) Noted. > -- section 5.1, example 2: > > It's unlikely that a SIP UAC is going to generate a gruu tag with a > value as neat as "balcony". Unlike XMPP, SIP doesn't typically use > human readable identifiers to distinguish devices (analogous to XMPP > resources.) More likely that will be random string assigned by the > registrar. (It's not _wrong_ as stated, but it might mislead > implementors.) In XMPP we've moved away from these human-readable identiers, too. Will adjust or at least add a note. > -- section 5.1, table 1: > > Do I understand correctly that you could have more than one > element over the course of a MUC? For the SIP/MSRP user, the Call-ID > will stay the same for the life of the session. Also, the call-id > will be unique for each SIP participant; I assume that's not true for > . In practice, the element is not used heavily in XMPP groupchat, mostly because no one has ever figured out a good user experience for multiple threads in a conference. However, that doesn't change the fact that the current text is misleading. Will fix. > -- Example 3: > > The 200 has the From and To wrong. Responses do not swap the from and > to from the original request. They should be identical to the > original, with the possible exception of the "to" tag. (I think this > repeats throughout the draft.) Probably a generalized misunderstanding or copy-and-paste error. Will fix. > -- Example 8: > > Inconsistent use of Allow header fields. I would probably leave them > out except where required, but others may have other opinions. It seems OK to remove them. > -- section 5.4: first paragraph > > First part of the paragraph seems to belong in 5.3. It might make > sense to combined 5.3 and 5.4 into one section. Probably, yes. > -- 5.5.2: Second Paragraph: > > Maybe this paragraph should belong in the section about the original > INVITE? This seems like a fine place for it, but I'll take a second look. > -- section 6, F42-44? > > If the initial SEND in F42 was empty, would F44 and 45 still happen? > Can F44 and F45 fail? What do you mean by "empty"? Is this a bodiless request, or a request with an empty body? > -- 6.1, paragraph before example 28: > > What if the MSRP user never sets a nick at all? Hmm, good point. Instituting a timeout doesn't seem optimal. Will reconsider. > 6.3.1, last paragraph: > > How do you determine "sameness" between stanzas in this context? Good question! I would say that, in this context, the stanza is "the same" if the XML elements in the payload match those from the outbound stanza that the MSRP-to-XMPP gateway generated from the MSRP SEND request. (There might be more elements, such as delayed delivery elements added by the MUC service, but matching the elements from the outbound stanza might work well, as long as the gateway matches only on stanzas received from the MSRP user's occupant JID.) I think we can describe this in a helpful manner (alternatively we could drop this behavior). > -- 7, 3rd paragraph: "In SIP, the nickname..." > > s/SIP/" the SIP conference event package" Correct. > -- 7, 2nd to last paragraph: > > I'm confused by this--I can see saying to display the contents of > or the JID resource part if the respective xcon > element or element are not present, but this seems to suggest > one should ignore them if they are present. Is that the intent? Right, the text should say "if present" in both cases. Thanks again for the helpful and thorough review! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Nov 21 19:12:56 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2A31AC3BB; Fri, 21 Nov 2014 19:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCo8T4G-GUOP; Fri, 21 Nov 2014 19:12:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AFF1AC3B5; Fri, 21 Nov 2014 19:12:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141122031250.27972.98185.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 19:12:50 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/stox/__6o0J1J8zDGjWp8sqQNHIAfxEM Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-08.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 03:12:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat Authors : Peter Saint-Andre Saul Ibarra Salvatore Loreto Filename : draft-ietf-stox-groupchat-08.txt Pages : 38 Date : 2014-11-21 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the SIP-based Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat (MUC) extension. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-groupchat-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 21 19:17:56 2014 Return-Path: X-Original-To: stox@ietfa.amsl.com Delivered-To: stox@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C41AC3B1 for ; Fri, 21 Nov 2014 19:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Jq_AtH3cHwW for ; Fri, 21 Nov 2014 19:17:52 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56141AC3B0 for ; Fri, 21 Nov 2014 19:17:51 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id r2so660015igi.6 for ; Fri, 21 Nov 2014 19:17:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HDjdWUDSVowAQmhQv0s1EFLkfmlUhdAUjHGmlIIW/hE=; b=IimcKSTRsLLM1nk+brFnPHN6WThAhW3N2j4N0eSsV5C6Gxa/5/ksCaCDq/+KO8d1c9 KaY54aYjivUimHPzqmdevJofRIlxTnqinvSA/P1JD/GwiDsim/4U3bmvsOMbOocXKEKG Qbd680FP3wG8Gm9Jklv7CRqi8mqD2swRYi3JrOsLPLqJu3LFC/IROMbmnRSL8nxzjNI+ sGE1UBeMBt90ZJ0gDKiZSnMCLw3HoNxSCXqXEBf6VYiWosptzBM/I0eemfTlbLa4RKvo JBSO43kvT6JlvSjghKGpWFptDOf7XlNyNhEnkWA24CgLrHl/GdB1kbILS3eQQC79Epye Jg2Q== X-Gm-Message-State: ALoCoQn2uAgTgSoJks2VVUpb8mSgSyuRBflYihF8mFhBTSGzxN4o4iRf4Qkdl1oi/gsWmnKsGSiC X-Received: by 10.43.76.67 with SMTP id zd3mr16474598icb.42.1416626270937; Fri, 21 Nov 2014 19:17:50 -0800 (PST) Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id zy11sm744955igc.4.2014.11.21.19.17.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 19:17:50 -0800 (PST) Message-ID: <5470005D.8050407@andyet.net> Date: Fri, 21 Nov 2014 20:17:49 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: stox@ietf.org References: <20141122031250.27972.98185.idtracker@ietfa.amsl.com> In-Reply-To: <20141122031250.27972.98185.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/stox/-6rYLiSHGKG3MMFMwS0A3kJRJbo Subject: Re: [Stox] I-D Action: draft-ietf-stox-groupchat-08.txt X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 22 Nov 2014 03:17:54 -0000 This version is my attempt at addressing the careful reviews that Ben Campbell provided. Peter On 11/21/14, 8:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the SIP-TO-XMPP Working Group of the IETF. > > Title : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat > Authors : Peter Saint-Andre > Saul Ibarra > Salvatore Loreto > Filename : draft-ietf-stox-groupchat-08.txt > Pages : 38 > Date : 2014-11-21 > > Abstract: > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a multiparty chat > session among users of the Session Initiation Protocol (SIP) and > users of the Extensible Messaging and Presence Protocol (XMPP). > Specifically, this document defines a mapping between the SIP-based > Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat > (MUC) extension. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-stox-groupchat-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-08 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > stox mailing list > stox@ietf.org > https://www.ietf.org/mailman/listinfo/stox >