From nobody Mon Feb 2 08:23:21 2015 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 76CF11A86FA for ; Mon, 2 Feb 2015 08:23:20 -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 Pf2_vXr3UNMD for ; Mon, 2 Feb 2015 08:23:14 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8981A86F2 for ; Mon, 2 Feb 2015 08:23:07 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id at20so18580056iec.3 for ; Mon, 02 Feb 2015 08:23:07 -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=B+H2YGoNag/+1gR8hyl+s24TdW9+D+ZYyHsmH8elwhw=; b=eRXMzmd2tE1RI+0k/EszNsMR81YGiHiXzsCLS+UN7pATS9CIO43Kt0IWJ4MOuDC35k jrNYHTdqz6GjOvjco3RiObux5GGM9SMcq8Gq/C6q1ba1Efoetk7G1zPS5QZ7bqqNOTpz ku66Scvd2GTCnROoq8MBv01w/R8D9lsFevcJ2c8B2DsT956uZtISlIvgImLfONyUB/i+ WjDHSHraiOu3FhoxB6lAmeHG/mfbp+XPqTuXlhvi9nCv+1yYJEk+aNxzgvqaWwdnZBZm u7sjAANq6S7KwDmYFvKvAz9xR/5Kfp9UDq5O/OTkstR3pHciXEUDnEVDoy69/BOjJ1JX +u9w== X-Gm-Message-State: ALoCoQmCIj6uNuZJqMFYKygo6O9Pt8Djj1d74f+33g/sU1RHeJRGQ4vqiKjE8scPfRP7RiCYO1Rt X-Received: by 10.107.9.91 with SMTP id j88mr23135440ioi.91.1422894187027; Mon, 02 Feb 2015 08:23:07 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:3df3:7ca3:bc84:ffd3]) by mx.google.com with ESMTPSA id k9sm6283809ige.6.2015.02.02.08.23.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 08:23:06 -0800 (PST) Message-ID: <54CFA468.5070807@andyet.net> Date: Mon, 02 Feb 2015 09:23:04 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , stox@ietf.org References: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> In-Reply-To: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Stox] AD evaluation: draft-ietf-stox-im-10 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: Mon, 02 Feb 2015 16:23:20 -0000 Hi Alissa, thanks for the review. Comments inline. On 1/31/15 5:09 PM, Alissa Cooper wrote: > I have reviewed this draft in preparation for IETF LC, along with the > -chat and -groupchat drafts. Overall the document appears in good > shape. I have a comment I’d like to discuss before proceeding to IETF > LC, along with an editorial nit to be addressed with any LC > comments. > > You will note some commonality across my comments on all three > drafts. In general, these drafts could do a better job of precisely > specifying what is minimally required (normatively) for > interoperability, versus what is optional or likely to differ between > implementations. I think if at least the syntax mappings are > normatively specified that should be sufficient, but the authors and > WG might want to consider doing another pass at these documents to > see if they could be more clear about which protocol exchanges the > various gateways must support for STOX to work at all, versus which > ones are suggested or optional. > > Comment: > > To achieve minimal interoperability, I think the syntax mappings in > Section 4 need to be MUST-level requirements rather than SHOULD. Or, > if there are cases envisioned in which different implementations > might map the elements differently, those should be explained. But I > assume there are not. That seems reasonable. Would you like the authors to complete this review and cleanup (with revised I-Ds for all three documents) before IETF Last Call? > Nit: > > If GRUUs are generally not human-readable in use, I would suggest > changing the ones in Section 4 to random identifiers. Good point. Will fix. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 2 08:36:35 2015 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 69CD91A876A for ; Mon, 2 Feb 2015 08:36:31 -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 pWdobaW2OL7v for ; Mon, 2 Feb 2015 08:36:22 -0800 (PST) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D0F1A82E2 for ; Mon, 2 Feb 2015 08:35:46 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id rl12so18753236iec.0 for ; Mon, 02 Feb 2015 08:35:45 -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=B5kVZdYrwKkql7H/AVpL0OGfVi4izSvkp8NCW974qqY=; b=NXI/M/ZiTvAlOVmioQuP+raYdlooDUmHdh6upd4TOAK0n5nGKoCNOqGB6YcA+fYLgv hiky2j4775tCclZS56TkY3ndH5XIEeeRgAudHDp2Aln4TE/o+8VfPqlxXtMr0yeONG7I lpSe+ePjkVaTIP8I6GpZDwIwIu8l9M3iaKqjBWdwo8eYjml+6QsWH9491s9Iz7p+PQU1 Y5TeYzONRPH1qj+afoBBFEZQevk2hbmf9sUuE+kxazJe7oFqyxOOeOV0kNUzcH7JP5uz I+goTRcDswFirds/pugl56CBGcGXC0UMpx5rnWnrJJkiw/c1kJghQmKLK/5BLqmP37Yi JAYw== X-Gm-Message-State: ALoCoQmO/1w18Tm1PrqQs7/CbytI9i+s5KC9m8/HmSf4cFt6SFlOu61+2s+26KZjnysWBxbukl8x X-Received: by 10.42.251.65 with SMTP id mr1mr10220855icb.76.1422894945742; Mon, 02 Feb 2015 08:35:45 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:3df3:7ca3:bc84:ffd3]) by mx.google.com with ESMTPSA id l192sm6243867ioe.9.2015.02.02.08.35.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 08:35:45 -0800 (PST) Message-ID: <54CFA75F.2040605@andyet.net> Date: Mon, 02 Feb 2015 09:35:43 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , stox@ietf.org References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> In-Reply-To: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08 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: Mon, 02 Feb 2015 16:36:31 -0000 On 1/31/15 5:09 PM, Alissa Cooper wrote: > = Section 7 = Is all of the delivery report behavior meant to be > entirely optional to support, or should there be some normative > requirements listed in this section? IMHO this is entirely optional (as with Section 6). > = Section 4 = "The XMPP-to-SIP gateway at the XMPP server would then > initiate an MSRP session with Romeo on Juliet's behalf (since there > is no reliable way for the gateway to determine if Romeo's client > supports MSRP, it simply needs to guess).” > > “Guessing” makes it sound like the gateway might use heuristics or > some such to determine whether to initiate an MSRP session, and that > in some cases it might not initiate a session. Would it be more > accurate to say that MSRP session initiation may yield an error since > there is no reliable way for the gateway to determine if Romeo's > client supports MSRP? Yes, that's better. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 2 08:59:31 2015 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 4B5EA1A8727 for ; Mon, 2 Feb 2015 08:59:28 -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 5jdDyhQA_Yga for ; Mon, 2 Feb 2015 08:59:26 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B401A8724 for ; Mon, 2 Feb 2015 08:59:26 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so19756558igk.1 for ; Mon, 02 Feb 2015 08:59:25 -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=C2Q14A9E0rcB/uzPuqR/+gvelYzVZaRfzzN6H3QranM=; b=G63Il83+B06fXJmRAr+IRcOOqcVyWADK451QNDn5c8lElieyvf6wwCNQYFI8s/c69f bOApwEAaIguujPPzGYvB39y2y9vBJnwQAP4yu+usnQsGm96KFMHIMIiycNcaPvkh6iRs Gp5s3eaVuRhguID3LRZK06o2eAJx0jYob/evHcJu7+HEx40nRgk4z1D7ZfhWJfLdowWz D6pS++FihKbLRYro1dwnzM+82clNHpXO+LKXpm7RRwkZpRMHz2DfpY9kb4RdOOoxN7vl jisQ6uB9AwL/B4sefeWvKVn/xgKcqbtJjqKclRsAuv8WS1wnOK7QH+U4zArqohKz3P/U fedQ== X-Gm-Message-State: ALoCoQk5FK8KG6dG6qimP+vZyGVEF4xGxR46Uw389BcRNXUmLIqQa57tPundWeNDt/B1AxZ/jd4T X-Received: by 10.42.207.129 with SMTP id fy1mr19538013icb.17.1422896365458; Mon, 02 Feb 2015 08:59:25 -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 l15sm6124913iod.33.2015.02.02.08.59.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 08:59:24 -0800 (PST) Message-ID: <54CFACEA.1040304@andyet.net> Date: Mon, 02 Feb 2015 09:59:22 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , stox@ietf.org References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> In-Reply-To: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08 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: Mon, 02 Feb 2015 16:59:28 -0000 On 1/31/15 5:10 PM, Alissa Cooper wrote: > I have reviewed this draft in preparation for IETF LC. I have a couple of comments/questions that I’d like to discuss before issuing the LC. I’ve also included some editorial nits that should be addressed together with any LC comments. > > = Section 5 = > All of the flow labels as used in the text and the examples need to be checked against the labels in the diagram. I found a bunch of inconsistencies where the labels used in the text are not describing the right flows in the diagram (e.g., Example 20, all the labels in Section 5.8). This is sort of editorial but given that the spec is basically defined by the diagrams and examples, I think it needs to be fixed before IETF LC. It confused me quite a bit. Yes, we changed them all around based on Ben Campbell's review and I recall making the modifications late at night, so it doesn't surprise me greatly that there are errors. Will review again. > In fact, I would suggest checking every label in the document to make sure it corresponds to the appropriate diagramed flow. +1 > = Section 5.1 = > "As specified in [RFC7247], the mapping of XMPP syntax elements to SIP > and [RFC4566] syntax elements is as shown in the following table.” > > This doesn’t seem quite right since RFC 7247 doesn’t actually provide the mapping of from->From and to->To — that’s what the table right here is doing. I would suggest that the text here follow the same pattern used in the -im draft, namely: > > "The mapping of XMPP syntax to SIP syntax [MUST] be as shown in the following table. > > Table 1: Message syntax mapping from XMPP to SIP/SDP > > +-----------------------------+-----------------------------+ > | XMPP Element or Attribute | SIP Header or SDP Contents | > +-----------------------------+-----------------------------+ > | from | From | > | to (without the /nick) | To | > +-----------------------------+——————————————+ > > As shown in the foregoing example and described in [RFC7247], the > XMPP-to-SIP gateway [MUST] map the bare JID > ("localpart@domainpart") of the XMPP sender to the SIP From > header and include the resourcepart of the full JID as the GRUU > portion [RFC5627] of the SIP URI.” > > Note that I’ve replaced the SHOULDs with MUSTs as explained in my comments on the -im draft. Great, thanks. > = Section 5.4 = > OLD > The following table shows the syntax mapping from the RFC 4575 > payload to the XMPP participant list. > > NEW > The syntax mappings from the RFC 4575 > payload to the XMPP participant list MUST be as shown in the following table. > > OLD > The mapping of SIP and [RFC4575] payload syntax elements to XMPP > syntax elements is as shown in the following table. > > NEW > The mapping of SIP and [RFC4575] payload syntax elements to XMPP > syntax elements MUST be as shown in the following table. > > = Section 5.5 = > OLD > The mapping of XMPP syntax elements to MSRP syntax elements is as > shown in the following table. > > NEW > The mapping of XMPP syntax elements to MSRP syntax elements MUST be as > shown in the following table. WFM. > = Section 6 = > As in Section 5, something is awry with the labels of the protocol flows in this section, both in the diagram and the examples that follow. I believe the first flow in the diagram, SIP INVITE from the SIP user to the SIP proxy, should be F35, not F33. > > Then in 6.1 the SUBSCRIBE flow is listed in Example 29 as F40, but it should be F38 as in the diagram. From there, the flow numbers listed in the examples are all off by 1 or 2. Yes, we'll check all of these. > = Section 6.3 = > OLD > The mapping of MSRP syntax elements to XMPP syntax elements is as > shown in the following table. > > NEW > The mapping of MSRP syntax elements to XMPP syntax elements MUST be as > shown in the following table. Yes. > = Section 6.3.1 = > Why does the SIP-to-XMPP gateway send an MSRP 200 OK back to the sender before seeing that the groupchat message has been reflected back? Doesn’t this give the sender the wrong impression in the event that a transport error causes the groupchat message to fail to reach the XMPP MUC? > > "In MSRP this reflected message is unnecessary." > > What does it mean for it to be “unnecessary”? Perhaps that was a poor choice of words. In MSRP, the switch doesn't reflect the message because it is explicitly acknowledged (200 OK). In XMPP, the MUC room doesn't explicitly acknowledge receipt of groupchat messages. I think it would be better for the switch + gateway to not generate the MSRP 200 OK until it receives the reflected message back from the MUC room. That is, move F45 after F47 and remove F48 & F49. > Why does the MSRP gateway send it (F48 in the diagram)? I suggest we remove F48 and F49. > = Section 7 = > "Implementations are strongly encouraged to apply the > rules for preparation and comparison of nicknames specified in > [I-D.ietf-precis-nickname].” > > draft-ietf-precis-nickname is listed as a normative reference. Should its use be a normative requirement? Probably. If we can ever finish the PRECIS work... > "Therefore, for display purposes SIP implementations > ought to use the element if the XCON 'nickname' > attribute is not present, and XMPP implementations ought to use the > resourcepart of the occupant JID if the element is not > present.” > > Should these be normative requirements? I don't think that display name mappings are critical for interoperability. > = Section 9 = > > I don’t think it’s sufficient to refer to the security considerations of the underlying specifications. > > This section omits discussion about whether the gateways needed for groupchat are expected to support the security requirements of the protocols they are gatewaying. The other two drafts address this point and it needs to be addressed here as well. Good catch. > Same goes for end-to-end security protections — some discussion is needed. To my knowledge, end-to-end security protections do not exist for multiparty text chat in MSRP or XMPP MUC. It's a hard problem (even harder than the 1:1 cases for IM and chat). > Also, many of the groupchat features that are left unspecified in this draft could be considered to be application security features: room administration, moderation, semi-anonymous rooms/anonymous participation, kicking and banning, etc. It seems at least worth mentioning that implementations supporting the feature set specified here cannot afford users with those features as they may be accustomed. Yes, we'll note that. Thanks again, Peter -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 2 16:16:06 2015 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 B9A301A8843; Mon, 2 Feb 2015 16:16:02 -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 yfsOm1zBmp3W; Mon, 2 Feb 2015 16:16:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7015B1A87BF; Mon, 2 Feb 2015 16:15:59 -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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203001559.20910.9195.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:15:59 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-11.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: Tue, 03 Feb 2015 00:16:03 -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): Instant Messaging Authors : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-11.txt Pages : 12 Date : 2015-02-02 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-11 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 Mon Feb 2 16:16:08 2015 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 58D1C1A87D7 for ; Mon, 2 Feb 2015 16:16:04 -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 ONNT0tC61k52; Mon, 2 Feb 2015 16:16:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 148851A87EF; Mon, 2 Feb 2015 16:16:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: stox@ietf.org, stox-chairs@tools.ietf.org, yana@jitsi.org, draft-ietf-stox-im.all@tools.ietf.org, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203001600.20910.8561.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:16:00 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-im-11.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: Tue, 03 Feb 2015 00:16:04 -0000 A new version (-11) has been submitted for draft-ietf-stox-im: http://www.ietf.org/internet-drafts/draft-ietf-stox-im-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-11 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. IETF Secretariat. From nobody Mon Feb 2 16:16:15 2015 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 4D0E91A8867; Mon, 2 Feb 2015 16:16:09 -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 jdPBFXhEFN37; Mon, 2 Feb 2015 16:16:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEEB1A1B44; Mon, 2 Feb 2015 16:16:02 -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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203001602.25230.27073.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:16:02 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-09.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: Tue, 03 Feb 2015 00:16:09 -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): One-to-One Text Chat Sessions Authors : Peter Saint-Andre Salvatore Loreto Filename : draft-ietf-stox-chat-09.txt Pages : 19 Date : 2015-02-02 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-09 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 Mon Feb 2 16:16:16 2015 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 88ABD1A8838 for ; Mon, 2 Feb 2015 16:16:11 -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 ZMTQOWv3-zwa; Mon, 2 Feb 2015 16:16:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A19F01A883B; Mon, 2 Feb 2015 16:16:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: stox@ietf.org, stox-chairs@tools.ietf.org, yana@jitsi.org, draft-ietf-stox-chat.all@tools.ietf.org, alissa@cooperw.in X-Test-IDTracker: no X-IETF-IDTracker: 5.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203001602.25230.66966.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:16:02 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-chat-09.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: Tue, 03 Feb 2015 00:16:11 -0000 A new version (-09) has been submitted for draft-ietf-stox-chat: http://www.ietf.org/internet-drafts/draft-ietf-stox-chat-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-09 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. IETF Secretariat. From nobody Mon Feb 2 16:16:22 2015 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 53FA91A88AD; Mon, 2 Feb 2015 16:16:15 -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 O4urrqoGcsHv; Mon, 2 Feb 2015 16:16:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73C1A884D; Mon, 2 Feb 2015 16:16:08 -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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150203001608.3573.37498.idtracker@ietfa.amsl.com> Date: Mon, 02 Feb 2015 16:16:08 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-09.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: Tue, 03 Feb 2015 00:16:15 -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-09.txt Pages : 39 Date : 2015-02-02 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-09 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 Mon Feb 2 16:20:43 2015 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 046161A8832 for ; Mon, 2 Feb 2015 16:20:43 -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 XlS6Fsa_7csK for ; Mon, 2 Feb 2015 16:20:41 -0800 (PST) Received: from mail-ie0-f176.google.com (mail-ie0-f176.google.com [209.85.223.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436771A8825 for ; Mon, 2 Feb 2015 16:20:41 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at20so21519602iec.7 for ; Mon, 02 Feb 2015 16:20:40 -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=2s95QFGr+nu/hVjMlipsuLFOuQiRAkKrxJ7jreke19g=; b=gOIJEuxdpDTmNT/rT4a0lp0PGYfpRfK6d/0zW1mcbdJkhwYTw3IiGNs2TtDGoUlhmv OkGGWo+r7LOWu9iHHNaPBThVUFOB/oFAQlTAoFwVcI3emM6yqseZhowc6UOqGHMJozg2 LcsS97ONBPqZNI/IL/9afBC302rqxs24uwjZLViDlrqsAHsnlTGr4DLImEvmoylwaTsw Zro0JjapRkr0PbQYdTMAPdFj2PRLcneN9JCdKSQIkwuk7D0LVnzO8vHcZ+zsdOu9NS31 b3O9eWCdz5VrmeIRg82pqJrYaMiSR/BB8Yufjp91grVj0k7yGs3XQWNramLGPrYbAOoc zHVg== X-Gm-Message-State: ALoCoQmWAqrKQ6/xUEyHOLJ2liE4mk1r/+C/V//SnWyLF+CRu8OO4DXxjwoyU7GoY4vKS1W1F6f0 X-Received: by 10.42.199.211 with SMTP id et19mr22097966icb.9.1422922840645; Mon, 02 Feb 2015 16:20:40 -0800 (PST) Received: from aither.local ([2601:1:8202:a280:f08b:f3d6:5be0:f30d]) by mx.google.com with ESMTPSA id t5sm7085408ign.12.2015.02.02.16.20.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 16:20:40 -0800 (PST) Message-ID: <54D01456.8070503@andyet.net> Date: Mon, 02 Feb 2015 17:20:38 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "stox@ietf.org" References: <20150203001614.20910.77312.idtracker@ietfa.amsl.com> In-Reply-To: <20150203001614.20910.77312.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150203001614.20910.77312.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Stox] Fwd: New Version Notification for draft-saintandre-stox-7248bis-00.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: Tue, 03 Feb 2015 00:20:43 -0000 I figured it would be better to correct the problems with RFC 7248 [1] through a new specification than through a huge erratum that no one would read anyway. :-) Peter [1] http://www.ietf.org/mail-archive/web/stox/current/msg00507.html -------- Forwarded Message -------- Subject: New Version Notification for draft-saintandre-stox-7248bis-00.txt Date: Mon, 02 Feb 2015 16:16:14 -0800 From: internet-drafts@ietf.org To: Peter Saint-Andre , Peter Saint-Andre A new version of I-D, draft-saintandre-stox-7248bis-00.txt has been successfully submitted by Peter Saint-Andre and posted to the IETF repository. Name: draft-saintandre-stox-7248bis Revision: 00 Title: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Document date: 2015-02-02 Group: Individual Submission Pages: 27 URL: http://www.ietf.org/internet-drafts/draft-saintandre-stox-7248bis-00.txt Status: https://datatracker.ietf.org/doc/draft-saintandre-stox-7248bis/ Htmlized: http://tools.ietf.org/html/draft-saintandre-stox-7248bis-00 Abstract: This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. 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. The IETF Secretariat -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 5 12:51:12 2015 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 594531A8AF6 for ; Thu, 5 Feb 2015 12:51:07 -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 vVE7gawJPxLM for ; Thu, 5 Feb 2015 12:51:03 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17DC91A1B37 for ; Thu, 5 Feb 2015 12:51:03 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so1115802igk.1 for ; Thu, 05 Feb 2015 12:51:02 -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=+mLP/FFfyB1GOeef8igZpkM2dGXqrLANYwh7wSS8bfs=; b=Q8/VDNqFFvjgcKzknKM4TP30DRiXXuQy/1kb5nHJEf4IEu7MUTddr1cq+g3g4d4pVu XoM1ioiMDcDwh1Z4e9DTM/I6eh7+PSsEEhFKLJIJNtddse2UfYCnkKOq8mXoBU/x299O fpNMQg4A190efFcFCzIEe8BcLK95LVoCBJRhow3Rxvf0p/4r3i1FPnwZq+GJUHZkW8qc rLP4ADWZezc7KYDe+j9Gnk0axXDg2aE11snmi1b6vwo4ntZMfwO1ZB5D21POqLIkujZx +LeFfskPnjgE7hkqb17C4Jx46NE5/ZQdH+13p+JnVk2XOSHeKp8ArN8ttHiLAcRVMsM/ bK/Q== X-Gm-Message-State: ALoCoQli/+XGJsf7+o2Z3jXh4Q7vXKTzoQBLEZuBlf2xRYKnULXKQx3yNTZGPkh5wl30xPCxdFTo X-Received: by 10.107.25.135 with SMTP id 129mr7314599ioz.44.1423169462459; Thu, 05 Feb 2015 12:51:02 -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 93sm161406iop.4.2015.02.05.12.51.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Feb 2015 12:51:01 -0800 (PST) Message-ID: <54D3D7B5.6010206@andyet.net> Date: Thu, 05 Feb 2015 13:51:01 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , stox@ietf.org References: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> In-Reply-To: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Stox] AD evaluation: draft-ietf-stox-im-10 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, 05 Feb 2015 20:51:08 -0000 On 1/31/15 5:09 PM, Alissa Cooper wrote: > I have reviewed this draft in preparation for IETF LC, along with the > -chat and -groupchat drafts. Overall the document appears in good > shape. I have a comment I’d like to discuss before proceeding to IETF > LC, along with an editorial nit to be addressed with any LC > comments. Hi Alissa, we've updated all three drafts to address your comments. Let us know if there's anything else you need from the authors in order to proceed. Thanks! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 5 15:57:31 2015 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 5F9611A8876 for ; Thu, 5 Feb 2015 15:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 Ge_Quzf14EVm for ; Thu, 5 Feb 2015 15:57:19 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E77C71A8873 for ; Thu, 5 Feb 2015 15:57:18 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5CFDD209FC for ; Thu, 5 Feb 2015 18:57:18 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 05 Feb 2015 18:57:18 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=BtcyvOakBPxpa4GnBXNBgvDayio=; b=h4tYxp4sD3OFxZIFa/X35 38IBsUcHV0zTWzLkyiuy3thgJHYmv54y/yQd1ab3nP6EwD/eRgXpzf6dMQGfhB43 6iNCrK1WyWOMF7FXGg/SzGrhN3+/0GdoM8drb5EiPMp2I4PvOicO2XnuwNVTxwQs wJFvWRUE6x18NMQ0nW0+f8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=BtcyvOakBPxpa4GnBXNBgvD ayio=; b=syRkDI6a9fB9TnLn7LNBOkzv/KMT8VoTGCOwKoWoHf1klGxJCdaw6TS SBEfkHkFlOv2gTZtd8/zhEEZ9XvOMgKG3jKE6zFJtb3m6awov8LzmJcrRAE0O4wl GqUGEBOzaVNbJv4mFUqn23/9EtOS2mI0KyfnFIRRrW1wA30gM6oo= X-Sasl-enc: HEykagWYqqwVGc51U43oYk8Iu+d2a5Qh6lvOlK0vu6v2 1423180637 Received: from [10.128.182.85] (unknown [70.35.43.175]) by mail.messagingengine.com (Postfix) with ESMTPA id 09504C0029B; Thu, 5 Feb 2015 18:57:16 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54D3D7B5.6010206@andyet.net> Date: Thu, 5 Feb 2015 15:57:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5CCCEED5-DF78-49A6-AA0A-EB18ACAEB551@cooperw.in> References: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> <54D3D7B5.6010206@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-im-10 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, 05 Feb 2015 23:57:23 -0000 Thanks. It will likely take me a few days to go through the responses. On Feb 5, 2015, at 12:51 PM, Peter Saint-Andre - &yet = wrote: > On 1/31/15 5:09 PM, Alissa Cooper wrote: >> I have reviewed this draft in preparation for IETF LC, along with the >> -chat and -groupchat drafts. Overall the document appears in good >> shape. I have a comment I=92d like to discuss before proceeding to = IETF >> LC, along with an editorial nit to be addressed with any LC >> comments. >=20 > Hi Alissa, we've updated all three drafts to address your comments. = Let us know if there's anything else you need from the authors in order = to proceed. >=20 > Thanks! >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Mon Feb 9 15:31:10 2015 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 320BF1A8A52 for ; Mon, 9 Feb 2015 15:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 rH9gzOYBD7-e for ; Mon, 9 Feb 2015 14:59:56 -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 EB4951A8A62 for ; Mon, 9 Feb 2015 14:59:55 -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 t19Mxp31012193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 16:59:52 -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] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ben Campbell Date: Mon, 9 Feb 2015 16:59:51 -0600 X-Mao-Original-Outgoing-Id: 445215591.266508-f0a7063290d4221cd99565945634a552 Content-Transfer-Encoding: quoted-printable Message-Id: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> To: Peter Saint-Andre - &yet , Alissa Cooper X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org Subject: [Stox] Comments on stox-chat-09 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: Mon, 09 Feb 2015 23:00:03 -0000 (Resending to include STOX list) (No hats yet) Hi Peter and Alissa, I've looked over draft-ietf-stox-chat-09. It looks mostly good, but = there are still a few issues. Thanks! /Ben ---------------------------- MSRP Failure-Report headers: The examples assume the MSRP Failure-Report header field is set to no. = It's missing from the first SEND, but explicitly set to no in the rest. = The responses to SEND requests are left off throughout. This is allowed, = but non-default behavior for MSRP. If the intent is to set = Failure-Report: no, it would be good to say a few words about it. If the = intent is to leave that to the implementation, then I would expect the = examples to follow the defaults. SIP Response From/To: The SIP responses swap the =46rom and To from the associated requests. = This is not correct, To and =46rom of a SIP response matches the To and = =46rom of the original request. (More to the point, the To and =46rom in = a response do not change to indicate the direction of the response = message.) I note that the groupchat draft had this issue at one point, = but it's been fixed. Session Termination I would like to see a little more prominent discussion about when the = XMPP side might terminate a session. It's mentioned in the "Composing" = section, but that seems to bury an important concept. I note both = primary examples show the SIP side terminating the session--it would be = nice to see one of those examples let the XMPP side do it. (Is the = "gone" composing state the only way this would happen?) SIP CSeq: CSeq is missing from most SIP requests, except oddly for BYE requests. = (And note that the CSeq of a BYE, sent by the peer that initiated the = INVITE, would never be "1") Security Considerations, last sentence: The text non-normatively "suggests" the use of RFC3862 for end-to-end = protection. That seems to want to have it both ways (non-normative and = recommended) . I suggest either making that normative, or reducing the = strength to say RFC3862 could be used for this purpose. (I realize we do = this all the time with "ought to", but it seems like we need a sharper = line for something like e2e crypto.) From nobody Mon Feb 9 15:49:48 2015 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 0CBF11A8A67 for ; Mon, 9 Feb 2015 15:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Gd5z02y3G4Ki for ; Mon, 9 Feb 2015 15:01:33 -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 AE6AF1A8A62 for ; Mon, 9 Feb 2015 15:01:33 -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 t19N1RoR012357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 17:01:28 -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] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ben Campbell In-Reply-To: Date: Mon, 9 Feb 2015 17:01:27 -0600 X-Mao-Original-Outgoing-Id: 445215687.275651-c55bc4dbc69678c762fc020dc2bb3359 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> <54CFACEA.1040304@andyet.net> <54D55765.7050000@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08 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: Mon, 09 Feb 2015 23:01:37 -0000 (Alissa pointed out that I left the STOX list of of these--resending.) One more thing: The SIP CSeq headers are incorrect in several places. = CSeq is missing from most SIP messages, except in BYE requests. (This is also true for stox-chat. I will send notes on that separately.) /Ben > On Feb 6, 2015, at 11:11 PM, Ben Campbell wrote: >=20 >=20 >> On Feb 6, 2015, at 6:08 PM, Peter Saint-Andre - &yet = wrote: >>=20 >> Ben, thanks again for your careful reviews. If you don't mind I'll = address these as IETF LC feedback, unless Alissa would like me to push = out a revised version incorporating the relevant fixes. >>=20 >=20 > Certainly, that works for me. >=20 > Thanks! >=20 > Ben. >=20 >> On 2/6/15 4:34 PM, Ben Campbell wrote: >>> (No hats) >>>=20 >>> Hi Peter and Alissa, >>>=20 >>> I just reviewed version groupchat-09, and it looks good. I just = noticed a few nits: >>>=20 >>> Section 4: The bulleted text for example.org and chat.example.org = don't seem to quite match the figure. The figure calls both the focus = and switch chat.example.org (which may not be what you want. = Example.org is a SIP proxy. >>>=20 >>> 5.1: The indented paragraph about MSRP URLs could be interpreted to = mean that the explicit port is only required for a literal address. In = fact, it's always required. >>>=20 >>> /Ben >>>=20 >>>=20 >>>> On Feb 2, 2015, at 10:59 AM, Peter Saint-Andre - &yet = wrote: >>>>=20 >>>> On 1/31/15 5:10 PM, Alissa Cooper wrote: >>>>> I have reviewed this draft in preparation for IETF LC. I have a = couple of comments/questions that I=E2=80=99d like to discuss before = issuing the LC. I=E2=80=99ve also included some editorial nits that = should be addressed together with any LC comments. >>>>>=20 >>>>> =3D Section 5 =3D >>>>> All of the flow labels as used in the text and the examples need = to be checked against the labels in the diagram. I found a bunch of = inconsistencies where the labels used in the text are not describing the = right flows in the diagram (e.g., Example 20, all the labels in Section = 5.8). This is sort of editorial but given that the spec is basically = defined by the diagrams and examples, I think it needs to be fixed = before IETF LC. It confused me quite a bit. >>>>=20 >>>> Yes, we changed them all around based on Ben Campbell's review and = I recall making the modifications late at night, so it doesn't surprise = me greatly that there are errors. Will review again. >>>>=20 >>>>> In fact, I would suggest checking every label in the document to = make sure it corresponds to the appropriate diagramed flow. >>>>=20 >>>> +1 >>>>=20 >>>>> =3D Section 5.1 =3D >>>>> "As specified in [RFC7247], the mapping of XMPP syntax elements to = SIP >>>>> and [RFC4566] syntax elements is as shown in the following = table.=E2=80=9D >>>>>=20 >>>>> This doesn=E2=80=99t seem quite right since RFC 7247 doesn=E2=80=99t= actually provide the mapping of from->=46rom and to->To =E2=80=94 = that=E2=80=99s what the table right here is doing. I would suggest that = the text here follow the same pattern used in the -im draft, namely: >>>>>=20 >>>>> "The mapping of XMPP syntax to SIP syntax [MUST] be as shown in = the following table. >>>>>=20 >>>>> Table 1: Message syntax mapping from XMPP to SIP/SDP >>>>>=20 >>>>> +-----------------------------+-----------------------------+ >>>>> | XMPP Element or Attribute | SIP Header or SDP Contents | >>>>> +-----------------------------+-----------------------------+ >>>>> | from | =46rom = | >>>>> | to (without the /nick) | To | >>>>> = +-----------------------------+=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94+ >>>>>=20 >>>>> As shown in the foregoing example and described in [RFC7247], the >>>>> XMPP-to-SIP gateway [MUST] map the bare JID >>>>> ("localpart@domainpart") of the XMPP sender to the SIP From >>>>> header and include the resourcepart of the full JID as the = GRUU >>>>> portion [RFC5627] of the SIP URI.=E2=80=9D >>>>>=20 >>>>> Note that I=E2=80=99ve replaced the SHOULDs with MUSTs as = explained in my comments on the -im draft. >>>>=20 >>>> Great, thanks. >>>>=20 >>>>> =3D Section 5.4 =3D >>>>> OLD >>>>> The following table shows the syntax mapping from the RFC 4575 >>>>> payload to the XMPP participant list. >>>>>=20 >>>>> NEW >>>>> The syntax mappings from the RFC 4575 >>>>> payload to the XMPP participant list MUST be as shown in the = following table. >>>>>=20 >>>>> OLD >>>>> The mapping of SIP and [RFC4575] payload syntax elements to XMPP >>>>> syntax elements is as shown in the following table. >>>>>=20 >>>>> NEW >>>>> The mapping of SIP and [RFC4575] payload syntax elements to XMPP >>>>> syntax elements MUST be as shown in the following table. >>>>>=20 >>>>> =3D Section 5.5 =3D >>>>> OLD >>>>> The mapping of XMPP syntax elements to MSRP syntax elements is as >>>>> shown in the following table. >>>>>=20 >>>>> NEW >>>>> The mapping of XMPP syntax elements to MSRP syntax elements MUST = be as >>>>> shown in the following table. >>>>=20 >>>> WFM. >>>>=20 >>>>> =3D Section 6 =3D >>>>> As in Section 5, something is awry with the labels of the protocol = flows in this section, both in the diagram and the examples that follow. = I believe the first flow in the diagram, SIP INVITE from the SIP user to = the SIP proxy, should be F35, not F33. >>>>>=20 >>>>> Then in 6.1 the SUBSCRIBE flow is listed in Example 29 as F40, but = it should be F38 as in the diagram. =46rom there, the flow numbers = listed in the examples are all off by 1 or 2. >>>>=20 >>>> Yes, we'll check all of these. >>>>=20 >>>>> =3D Section 6.3 =3D >>>>> OLD >>>>> The mapping of MSRP syntax elements to XMPP syntax elements is as >>>>> shown in the following table. >>>>>=20 >>>>> NEW >>>>> The mapping of MSRP syntax elements to XMPP syntax elements MUST = be as >>>>> shown in the following table. >>>>=20 >>>> Yes. >>>>=20 >>>>> =3D Section 6.3.1 =3D >>>>> Why does the SIP-to-XMPP gateway send an MSRP 200 OK back to the = sender before seeing that the groupchat message has been reflected back? = Doesn=E2=80=99t this give the sender the wrong impression in the event = that a transport error causes the groupchat message to fail to reach the = XMPP MUC? >>>>>=20 >>>>> "In MSRP this reflected message is unnecessary." >>>>>=20 >>>>> What does it mean for it to be =E2=80=9Cunnecessary=E2=80=9D? >>>>=20 >>>> Perhaps that was a poor choice of words. In MSRP, the switch = doesn't reflect the message because it is explicitly acknowledged (200 = OK). In XMPP, the MUC room doesn't explicitly acknowledge receipt of = groupchat messages. >>>>=20 >>>> I think it would be better for the switch + gateway to not generate = the MSRP 200 OK until it receives the reflected message back from the = MUC room. That is, move F45 after F47 and remove F48 & F49. >>>>=20 >>>>> Why does the MSRP gateway send it (F48 in the diagram)? >>>>=20 >>>> I suggest we remove F48 and F49. >>>>=20 >>>>> =3D Section 7 =3D >>>>> "Implementations are strongly encouraged to apply the >>>>> rules for preparation and comparison of nicknames specified in >>>>> [I-D.ietf-precis-nickname].=E2=80=9D >>>>>=20 >>>>> draft-ietf-precis-nickname is listed as a normative reference. = Should its use be a normative requirement? >>>>=20 >>>> Probably. >>>>=20 >>>> If we can ever finish the PRECIS work... >>>>=20 >>>>> "Therefore, for display purposes SIP implementations >>>>> ought to use the element if the XCON 'nickname' >>>>> attribute is not present, and XMPP implementations ought to use = the >>>>> resourcepart of the occupant JID if the element is not >>>>> present.=E2=80=9D >>>>>=20 >>>>> Should these be normative requirements? >>>>=20 >>>> I don't think that display name mappings are critical for = interoperability. >>>>=20 >>>>> =3D Section 9 =3D >>>>>=20 >>>>> I don=E2=80=99t think it=E2=80=99s sufficient to refer to the = security considerations of the underlying specifications. >>>>>=20 >>>>> This section omits discussion about whether the gateways needed = for groupchat are expected to support the security requirements of the = protocols they are gatewaying. The other two drafts address this point = and it needs to be addressed here as well. >>>>=20 >>>> Good catch. >>>>=20 >>>>> Same goes for end-to-end security protections =E2=80=94 some = discussion is needed. >>>>=20 >>>> To my knowledge, end-to-end security protections do not exist for = multiparty text chat in MSRP or XMPP MUC. It's a hard problem (even = harder than the 1:1 cases for IM and chat). >>>>=20 >>>>> Also, many of the groupchat features that are left unspecified in = this draft could be considered to be application security features: room = administration, moderation, semi-anonymous rooms/anonymous = participation, kicking and banning, etc. It seems at least worth = mentioning that implementations supporting the feature set specified = here cannot afford users with those features as they may be accustomed. >>>>=20 >>>> Yes, we'll note that. >>>>=20 >>>> Thanks again, >>>>=20 >>>> Peter >>>>=20 >>>> -- >>>> Peter Saint-Andre >>>> https://andyet.com/ >>>>=20 >>>> _______________________________________________ >>>> stox mailing list >>>> stox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/stox >=20 From nobody Mon Feb 9 15:50:44 2015 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 47C951A8A74 for ; Mon, 9 Feb 2015 15:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 GqloqGGtdmB6 for ; Mon, 9 Feb 2015 15:27:11 -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 8A6211A8A7D for ; Mon, 9 Feb 2015 15:27:11 -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 t19NR88b014526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 17:27:08 -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] Content-Type: multipart/signed; boundary="Apple-Mail=_B182F6B1-78D7-4916-8DD0-39A4CE5FA503"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Ben Campbell Date: Mon, 9 Feb 2015 17:27:08 -0600 X-Mao-Original-Outgoing-Id: 445217227.83926-be0cd1ebfaff7a680f13c6e51544a9db Message-Id: To: draft-ietf-stox-im.all@tools.ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: [Stox] Comments on draft-ietf-stox-im-11 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: Mon, 09 Feb 2015 23:27:15 -0000 --Apple-Mail=_B182F6B1-78D7-4916-8DD0-39A4CE5FA503 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (No hats) Hi, (I apologize that these comments are late in the process. Please feel = free to defer them to last call.) This version mostly looks good, but there are a few minor issues: -- Message Size It might be worth a discussion on message size limits (e.g. the SIP = MESSAGE method limits the size to 1300 octets except under some pretty = narrow circumstances.) -- Example 3: This example reverses the =46rom and To in the SIP response (similar to = the same issue for stox-chat.) --section 4, text right above table 1: The text references stox-chat for additional mappings. But stox-chat = references this draft for the same reasons. I realize it's not really a = circular reference, but I think it might confuse the reader. -- Security considerations I'm a little uncomfortable non-normatively saying we "prefer" the use of = RFC3862. My strictly individual opinion is that we should make a = normative recommendation, or merely point out the possibility of using = 3862. (I realize we do this a lot with the "ought to" construct, but it = seems like things like end-to-end crypto could benefit from a less vague = approach.) --Apple-Mail=_B182F6B1-78D7-4916-8DD0-39A4CE5FA503 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU2UJLAAoJEIBWSmyV89QNxwkP+wR1NYzaIRQQKQX4m72YTJeV DT5I7KTcFe87Igkap1EFN5BkRypthhjfKyc619I/mE+DCG4J70zVewFyeRlC8Axd 7pEeCsQY5TiyH4EL2tVwug9mqixaY6jyps0tKoF3GNQkjBB7lHG+BfpX20bniJ6C /CEY80YbrGfKTMnl6QaDAcTf9xh8JedwLcQEW/hiYiXlsrKmkxnNMYiq2Zahd/lA dmSJphqG7BbFw9tCvEvvZFJ0xuHUJJGuDNDopTS3ahyCzLZ7Qqi+p/y/U8OJnZvp /UnWAscfSoTSFN0hRVDFc/Ce0RXSOPFnyAk5Gdw8AWtKvjO2SzZ6VQdSUCtop8Io 9R+MV3xXhhLFO2ch+QEFbj6MA573Gmadbmgm/VuLojufAknFBxCqiNq7C53m++zO X0dk7IxkvNwR+tkMXy6EsvJglMiGxUultxssHhCWWSkg43r+Er2r/FxiWj/1CQ/h G0bKGiXwCYhoogf4pUpsaT58d2oSMvCW8sypwKGELsiOYH6usXVdaS6qEcxypYBf 1jcRxULbtUQd8ENWNv1GXpKubW7CvDQC+RjO49GLK/0I/xkL4H4OXDIfVbVZfOT+ jTmyZps8cPb4RoBWsWqmZ/KlgE0eZGY8tRyR/TCdJCI1Rlgu065jiYm+vylhMYrh g4puGdp3nScQx5DEdcXC =zpKB -----END PGP SIGNATURE----- --Apple-Mail=_B182F6B1-78D7-4916-8DD0-39A4CE5FA503-- From nobody Mon Feb 9 15:51:43 2015 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 4F5FC1A8A9D for ; Mon, 9 Feb 2015 15:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 PhiLU2gNRCRm for ; Mon, 9 Feb 2015 15:44:05 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164491A8AAA for ; Mon, 9 Feb 2015 15:44:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8375B20E46 for ; Mon, 9 Feb 2015 18:44:04 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Feb 2015 18:44:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=eliGbi5JGtiX58eZkMTg/7iI7HQ=; b=ZsXKOWS3W3SBfgDLENa98 h0jhlJh1L/m+qFri1NVFpmynd/yrp1yCL83KomLpUNfkDvNYBWpRCKoWl1JopEkt s9nS9ICllNt0nvC3l9fz/FSGep2P1YJ51mj7S1RU3EvJ5XQ2EsGS8iuB/Lr2zRiO 8t+jjxZumszyThPOXtNfbo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=eliGbi5JGtiX58eZkMTg/7i I7HQ=; b=A1+YH3tJOWIMj7Pu8Wsf7HdlrzhJmnpkLXGySQx/p/8HXUXq9KSNtTR caOa6x4+hsuBRkbglnfkiWohIx2QmzutUj3ljlo9GtzmpN1qiynjRFieNykHwKcX kM8ztoRZnaEq1m3vjc5NVFrmQXWe10r+NlQj4qUHRNAyDEa8OedU= X-Sasl-enc: xTss/2fhls8R9eunOiCr7a49pufWrbomqGHeyHqtHxp9 1423525444 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id A02E76800E3; Mon, 9 Feb 2015 18:44:03 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54CFA75F.2040605@andyet.net> Date: Mon, 9 Feb 2015 15:44:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in> References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> <54CFA75F.2040605@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08 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: Mon, 09 Feb 2015 23:44:08 -0000 On Feb 2, 2015, at 8:35 AM, Peter Saint-Andre - &yet = wrote: > On 1/31/15 5:09 PM, Alissa Cooper wrote: >=20 >> =3D Section 7 =3D Is all of the delivery report behavior meant to be >> entirely optional to support, or should there be some normative >> requirements listed in this section? >=20 > IMHO this is entirely optional (as with Section 6). I think the difference between Section 6 and Section 7 is that Section 6 = at least gives a little narrative description of how to do the mapping = for composing notifications, whereas in Section 7 there is no such = description, it=92s just illustrated by examples. So I would suggest = adding a sentence or two that generically describes what the gateway in = each direction should do to map an MSRP REPORT to an XMPP message = receipt request/response and vice versa. This is obviously a small thing = but seems like good practice. This can be dealt with during IETF LC. Ben has sent comments on this draft and I=92d like to see how that = discussion resolves before issuing the IETF LC. Thanks, Alissa=20 >=20 >> =3D Section 4 =3D "The XMPP-to-SIP gateway at the XMPP server would = then >> initiate an MSRP session with Romeo on Juliet's behalf (since there >> is no reliable way for the gateway to determine if Romeo's client >> supports MSRP, it simply needs to guess).=94 >>=20 >> =93Guessing=94 makes it sound like the gateway might use heuristics = or >> some such to determine whether to initiate an MSRP session, and that >> in some cases it might not initiate a session. Would it be more >> accurate to say that MSRP session initiation may yield an error since >> there is no reliable way for the gateway to determine if Romeo's >> client supports MSRP? >=20 > Yes, that's better. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Mon Feb 9 15:51:45 2015 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 4901A1A8AA0 for ; Mon, 9 Feb 2015 15:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 k8NZmm4wq_vp for ; Mon, 9 Feb 2015 15:44:13 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBD61A8AAA for ; Mon, 9 Feb 2015 15:44:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7A50C20C1C for ; Mon, 9 Feb 2015 18:44:12 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 09 Feb 2015 18:44:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=l/AYrBt2JxA8bYODJCpginAIvKU=; b=vM7mGciisOGKuW24zQRGY 1IykDC/Bnm+mrtapPFBxdDk+mKlhAF1bwS8YpxeGqFUx+6i5JZqsKloYFjCYhv32 T5lMzMWaDvgp3YfkA/IAiofS6X2edJWO2lrBZIhaVJyqrHvRVoUC3ZD3ktGvA4+e jKI4sl0GHBznEqDiUvFpYw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=l/AYrBt2JxA8bYODJCpginA IvKU=; b=Cb2eb7TGowVEbeR/KTiSfIZ6U2DZFvNnRLK02jRRIlD+//vND5jdPc0 rd/bmyZsrP0DGmXuAt2BgQohwSM96q6Dzw6XOipLs6BY7ALvn2gcoPcqp9UxtpFv Z8AwoEMQKlRfbdtGZg0Lbasn5fkOHzupfXvM0xSSiJ3/sRA6S4i8= X-Sasl-enc: 3mZVBhcnMZeFKLHhBYSumfHkf5QhFsQl3d323g5XFduc 1423525452 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id A02106801F2; Mon, 9 Feb 2015 18:44:11 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54CFA468.5070807@andyet.net> Date: Mon, 9 Feb 2015 15:44:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> <54CFA468.5070807@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-im-10 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: Mon, 09 Feb 2015 23:44:16 -0000 The new draft addresses all of my issues, thanks. I=92d like to see how = the discussion with Ben resolves before issuing an IETF LC. Alissa On Feb 2, 2015, at 8:23 AM, Peter Saint-Andre - &yet = wrote: > Hi Alissa, thanks for the review. Comments inline. >=20 > On 1/31/15 5:09 PM, Alissa Cooper wrote: >> I have reviewed this draft in preparation for IETF LC, along with the >> -chat and -groupchat drafts. Overall the document appears in good >> shape. I have a comment I=92d like to discuss before proceeding to = IETF >> LC, along with an editorial nit to be addressed with any LC >> comments. >>=20 >> You will note some commonality across my comments on all three >> drafts. In general, these drafts could do a better job of precisely >> specifying what is minimally required (normatively) for >> interoperability, versus what is optional or likely to differ between >> implementations. I think if at least the syntax mappings are >> normatively specified that should be sufficient, but the authors and >> WG might want to consider doing another pass at these documents to >> see if they could be more clear about which protocol exchanges the >> various gateways must support for STOX to work at all, versus which >> ones are suggested or optional. >>=20 >> Comment: >>=20 >> To achieve minimal interoperability, I think the syntax mappings in >> Section 4 need to be MUST-level requirements rather than SHOULD. Or, >> if there are cases envisioned in which different implementations >> might map the elements differently, those should be explained. But I >> assume there are not. >=20 > That seems reasonable. >=20 > Would you like the authors to complete this review and cleanup (with = revised I-Ds for all three documents) before IETF Last Call? >=20 >> Nit: >>=20 >> If GRUUs are generally not human-readable in use, I would suggest >> changing the ones in Section 4 to random identifiers. >=20 > Good point. Will fix. >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Mon Feb 9 15:51:46 2015 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 13B231A8AB1 for ; Mon, 9 Feb 2015 15:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 mVzaLiq9UmHo for ; Mon, 9 Feb 2015 15:44:19 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5891A8AAA for ; Mon, 9 Feb 2015 15:44:19 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1685120E33 for ; Mon, 9 Feb 2015 18:44:18 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Mon, 09 Feb 2015 18:44:19 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=QeBpjk0WtytvKhuHYEcy98a3jj0=; b=PzVqgtLwEGGyeZN91aHNc tszMBtxsXqAtTlMMl36HzqzbDb/6/IOqi1WOtwmk9Bbdg1M0L+MRA3YqcnX5ZAwM C/GElpvW14JXW9EElsLTuGKV/t8hilC9U6ZHRVzTuOxxeWNB0fmXgC3rgVTy6BNl m6o3Y9FN2jdhrsLj8oL9JU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=QeBpjk0WtytvKhuHYEcy98a 3jj0=; b=JPIjI+guyAuvHpHC/Wo9dy4yxutUT5bb2QbhIs4acB/IVgl11u778oZ yncGFK7TdS0T6MVcSiMfrHIYx3MgbOQnLOaZ1WkMZ+nbSv7T8hhLvbeS/MnM40J2 Bb2oN/Heny+P9EmQJiQzMTAXujGckYDIn1I4RUd+enqR5CCT/Wtc= X-Sasl-enc: xHVUn3oMppW2vciUc5DJUX8sFx9ANK7GMOso0E83QU1n 1423525458 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.235]) by mail.messagingengine.com (Postfix) with ESMTPA id 20BE7680153; Mon, 9 Feb 2015 18:44:17 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54CFACEA.1040304@andyet.net> Date: Mon, 9 Feb 2015 15:44:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <01A1D5F0-5363-4298-A86C-11280D66F903@cooperw.in> References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> <54CFACEA.1040304@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08 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: Mon, 09 Feb 2015 23:44:21 -0000 Peter, Thanks, the changes look good. On Feb 2, 2015, at 8:59 AM, Peter Saint-Andre - &yet = wrote: >> "Therefore, for display purposes SIP implementations >> ought to use the element if the XCON 'nickname' >> attribute is not present, and XMPP implementations ought to use = the >> resourcepart of the occupant JID if the element is not >> present.=94 >>=20 >> Should these be normative requirements? >=20 > I don't think that display name mappings are critical for = interoperability. Fair enough, I thought there was a case missing in there where the user = might end up entering a display name that then does not get displayed = because the gateway does not support it, but those cases seem to be = covered. For this draft I think Ben=92s comments can be incorporated together = with IETF LC comments. But I=92d like to put all three documents in LC = together, so will wait on the resolution of the comments on the other = drafts. Thanks, Alissa From nobody Wed Feb 11 18:16:21 2015 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 200A81A8A51 for ; Wed, 11 Feb 2015 18:16:09 -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 Sp3yjlL2f-c4 for ; Wed, 11 Feb 2015 18:16:06 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2F61A8A44 for ; Wed, 11 Feb 2015 18:16:06 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so916801igb.5 for ; Wed, 11 Feb 2015 18:16:05 -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=DRjkLh6/Ny0FfhSElTxdfYxjRNoEtZ9m5ba2/ND7+YM=; b=KGMAk9y3L05U7eE9ew4uGyRT5NC03CKcs30I1cllHEQhCUSxZJNwzN7O+qYMn1yQMr HWKsxDRuNWywHQyJYWQizMddsw8NT6d+2IRvrmQZABKpyD3X8ny0OFvGbYKyDh594dhe r75k3AEZZrZLke6p8BudR/O2QuIFGIkF360It0kQTGYHq/a5jOMONKJEDy9uUQDspjy8 /QCHBQWtBiq+/E2K06gfifjtFDOwKA/f9DtLtJqKJR58bPlxRMmMyNCRcyIykxJoBWNW pY3JLayX8oJk+RepJtYY9oIPqcsyzTXKygms7QfcKsM1xfw3cW1U67B3x0N7h+GrVyDi KTOA== X-Gm-Message-State: ALoCoQkD3Bso3ROolzvUc1Nl2G/A2omMCmgLDH7vxa2TUGAl0lfLqSMGNqxhjRsxA1svKZyIsdQx X-Received: by 10.42.130.74 with SMTP id u10mr1525090ics.61.1423707365765; Wed, 11 Feb 2015 18:16:05 -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 e3sm338510igg.16.2015.02.11.18.16.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 18:16:05 -0800 (PST) Message-ID: <54DC0CE3.8090405@andyet.net> Date: Wed, 11 Feb 2015 19:16:03 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-stox-im.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 12 Feb 2015 02:16:09 -0000 On 2/9/15 4:27 PM, Ben Campbell wrote: > (No hats) > > Hi, > > (I apologize that these comments are late in the process. Please feel > free to defer them to last call.) > > This version mostly looks good, but there are a few minor issues: > > -- Message Size > > It might be worth a discussion on message size limits (e.g. the SIP > MESSAGE method limits the size to 1300 octets except under some > pretty narrow circumstances.) Thank you for pointing this out. I had glossed over it in my reading of RFC 3428. I think it deserves a section of its own in the -im document. > -- Example 3: > > This example reverses the From and To in the SIP response (similar to > the same issue for stox-chat.) Will fix. > --section 4, text right above table 1: > > The text references stox-chat for additional mappings. But stox-chat > references this draft for the same reasons. I realize it's not really > a circular reference, but I think it might confuse the reader. Hmm. I think it would be best to put them all in the -im document. > -- Security considerations > > I'm a little uncomfortable non-normatively saying we "prefer" the use > of RFC3862. My strictly individual opinion is that we should make a > normative recommendation, or merely point out the possibility of > using 3862. (I realize we do this a lot with the "ought to" > construct, but it seems like things like end-to-end crypto could > benefit from a less vague approach.) I would prefer to point out the possibility of using RFC 3862. Given that no one, to my knowledge, has implemented RFC 3923 in an XMPP client, I'd be uncomfortable making that a normative recommendation. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 18:47:39 2015 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 027D31A1B91 for ; Wed, 11 Feb 2015 18:47:37 -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 Q80qi2uA50gn for ; Wed, 11 Feb 2015 18:47:32 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660AA1A1B18 for ; Wed, 11 Feb 2015 18:47:32 -0800 (PST) Received: by iecat20 with SMTP id at20so8823930iec.12 for ; Wed, 11 Feb 2015 18:47: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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=sRw4ToWs3Ca1QUcQhGQe447jlLDnLJH+fss3QQDTSqg=; b=KpDn6xw6eS7GHvEK/6RZRx+RFtkQvrEw9en0Cn3oyr0X5jzSViaD1gyN8rrts15l45 0xBi6wqTg0pNI+utCcnbub7YhNrpRXCJnMmpf7LjV4OFBk/j3z4NkYA05WhXP8DbQ/tm glG1t+UE2/f5ICUOF8/sdcNTkWymLsmHWaEq2D0NhmNNfe+JD1DUB158joPXEnLdJXAp af2sGtmOiB84MOgmCLDRkUI7dCpwB6Ux7BtgJOHJ1G8wXbjCqOJ9xvCgV+mpvhHOVUov l6VJHV4ZTXsUuBK3dbya3eCQtPxpasPXq2rjAZHrN+hHEmol7zq2FoL6rrDqe+7vdXmm iJbw== X-Gm-Message-State: ALoCoQlKkdwFPP3IaOq7dqJx4gnxN5nFQy1SAWx1/9NvmbrTcBuzKRD1wuHEXQpPFXWgdJEGCBls X-Received: by 10.107.46.213 with SMTP id u82mr2219453iou.68.1423709251793; Wed, 11 Feb 2015 18:47: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 a125sm1607521ioa.40.2015.02.11.18.47.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 18:47:30 -0800 (PST) Message-ID: <54DC1441.2090305@andyet.net> Date: Wed, 11 Feb 2015 19:47:29 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , draft-ietf-stox-im.all@tools.ietf.org References: <54DC0CE3.8090405@andyet.net> In-Reply-To: <54DC0CE3.8090405@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 12 Feb 2015 02:47:37 -0000 On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: > On 2/9/15 4:27 PM, Ben Campbell wrote: >> (No hats) >> >> Hi, >> >> (I apologize that these comments are late in the process. Please feel >> free to defer them to last call.) >> >> This version mostly looks good, but there are a few minor issues: >> >> -- Message Size >> >> It might be worth a discussion on message size limits (e.g. the SIP >> MESSAGE method limits the size to 1300 octets except under some >> pretty narrow circumstances.) > > Thank you for pointing this out. I had glossed over it in my reading of > RFC 3428. I think it deserves a section of its own in the -im document. I propose the following text: [RFC3428] specifies that (outside of a media session) the size of a MESSAGE request is not allowed to exceed 1300 bytes. Although in practice XMPP instant messages do not often exceed that size, neither [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP stanzas. However, XMPP server deployments usually do limit the size of stanzas in order to help prevent denial of service attacks, and [RFC6120] states that if a server sets a maximum stanza size then the limit is not allowed to be less than 10,000 bytes. Because of this mismatch, an XMPP-to-SIP gateway MUST return a stanza error if an XMPP user attempts to send an XMPP message stanza that would result in a SIP MESSAGE greater than 1300 bytes. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 18:52:18 2015 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 D91E01A1B5C for ; Wed, 11 Feb 2015 18:52:17 -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 0yN1FNSvifBo for ; Wed, 11 Feb 2015 18:52:16 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765701A1B5B for ; Wed, 11 Feb 2015 18:52:16 -0800 (PST) Received: by iecrd18 with SMTP id rd18so8840011iec.8 for ; Wed, 11 Feb 2015 18:52:16 -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=gbz138+l1op4Y/GP2kwV4M8KbDoDGndQRP3Nr7tx/qo=; b=ZBydFOvPK/dzCWzfk1jmz15EGGN0T9S00xefL7boGHZwthgSPwtalY56gGRW7gH9/x q2eOAkE8H/mnfE4m13Hs/x6XuAxRK91OxEuVrhsOifBTHgkUTHezywWcujMMnsNYto6s xlUivqdXB9J8w8aDdjw3sFngVVS+Zhsa4jrUDk0eCwi8TG+zRsA3sXgdaLj2u5oGf5Vh j4JY0YZFRJac9WGO4aOB77ZlJix9G9mBFfhV1YucCLMse1CaE6Nz/W8SvpzGPos/AqhR qSdNtrZAEkoHbGxp/2mmDrCS2AThrwinlJADF4DLeSp4C8iX7icGqADohVzy4LKQXf/v MNwg== X-Gm-Message-State: ALoCoQl4QGe7qOulfznfS1fdcEwCp5ozo76k+T5rSzq/eLt9cKM41dshOhtrjr7eml1Ti5k4Njem X-Received: by 10.50.97.41 with SMTP id dx9mr1289758igb.1.1423709535956; Wed, 11 Feb 2015 18:52:15 -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 m38sm1615517ioi.39.2015.02.11.18.52.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 18:52:15 -0800 (PST) Message-ID: <54DC155E.4070706@andyet.net> Date: Wed, 11 Feb 2015 19:52:14 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper References: <48B4925F-747B-4453-AF7F-3B1E9505A549@cooperw.in> <54CFA468.5070807@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-im-10 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, 12 Feb 2015 02:52:18 -0000 On 2/9/15 4:44 PM, Alissa Cooper wrote: > The new draft addresses all of my issues, thanks. I’d like to see how the discussion with Ben resolves before issuing an IETF LC. Agreed. If the text I've proposed seems acceptable, I can submit -12 with the relevant fixes. Peter From nobody Wed Feb 11 18:58:05 2015 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 CE1701A03E3 for ; Wed, 11 Feb 2015 18:58:03 -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 obuxRO48YAHI for ; Wed, 11 Feb 2015 18:57:59 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7401A1B5C for ; Wed, 11 Feb 2015 18:57:57 -0800 (PST) Received: by iery20 with SMTP id y20so8903083ier.9 for ; Wed, 11 Feb 2015 18:57:56 -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=zV89mJz7L6XmCDsohOpN4yhv98RcRNJWQSaw6N98KF8=; b=T0Fv88h6zNDywOlPSSg7Jq5HnJqCFP4n5gz0QHEeEHCQZUbLwbTS+xTAM2JMbjEzS6 TBfPWUDx3h+IZQtX5/7fooLUt5vBaqKcTDMWCiJGQ1z4K6rdN/YDgQUUMFU9e4ST+PVH QEoOcGjN4pGwkSNhCYWlSw1b5peoSvz8Y8kBXxtMIRkE6+utRKxKmRmriPoNZ6nnlTmT PI1yMqoORBLTC9tEgNEKnkbHxfQo+84ACtt17g9Ry45Fsop3+yjMftfg9Y5icDvIKtS4 vtWREuGJ4ewbKLlsuOOdc3YkCZfZRYIEqDa4w5fSy40nX5ZZFAUuRdiQk4+8nr+tSp+z oUsA== X-Gm-Message-State: ALoCoQnI+aEyv+SdFC74Hr2+tAAH3XZ+VsZqKlJ9uWmWLZx+v2+a8RnB5+HVP87OlaWR0/bLWyHF X-Received: by 10.107.46.213 with SMTP id u82mr2255069iou.68.1423709876843; Wed, 11 Feb 2015 18:57:56 -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 t41sm1648626ioi.0.2015.02.11.18.57.55 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 18:57:56 -0800 (PST) Message-ID: <54DC16B3.2020205@andyet.net> Date: Wed, 11 Feb 2015 19:57:55 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> <54CFA75F.2040605@andyet.net> <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in> In-Reply-To: <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08 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, 12 Feb 2015 02:58:04 -0000 On 2/9/15 4:44 PM, Alissa Cooper wrote: > On Feb 2, 2015, at 8:35 AM, Peter Saint-Andre - &yet wrote: > >> On 1/31/15 5:09 PM, Alissa Cooper wrote: >> >>> = Section 7 = Is all of the delivery report behavior meant to be >>> entirely optional to support, or should there be some normative >>> requirements listed in this section? >> >> IMHO this is entirely optional (as with Section 6). > > I think the difference between Section 6 and Section 7 is that Section 6 at least gives a little narrative description of how to do the mapping for composing notifications, whereas in Section 7 there is no such description, it’s just illustrated by examples. So I would suggest adding a sentence or two that generically describes what the gateway in each direction should do to map an MSRP REPORT to an XMPP message receipt request/response and vice versa. This is obviously a small thing but seems like good practice. This can be dealt with during IETF LC. Yes, I see your point. Will add. > Ben has sent comments on this draft and I’d like to see how that discussion resolves before issuing the IETF LC. Agreed. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 19:07:59 2015 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 C98B21A8A5A for ; Wed, 11 Feb 2015 19:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 t3EyAzhv9veZ for ; Wed, 11 Feb 2015 19:07:28 -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 2F4CD1A8A65 for ; Wed, 11 Feb 2015 19:07:28 -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 t1C37IAD049458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 21:07:19 -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] Content-Type: multipart/signed; boundary="Apple-Mail=_8F5408B1-ABDC-490A-9BC9-96C0B81797C6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Ben Campbell In-Reply-To: <54DC1441.2090305@andyet.net> Date: Wed, 11 Feb 2015 21:07:18 -0600 X-Mao-Original-Outgoing-Id: 445403238.179771-fe93bc60406d74cccedf271dfb60759c Message-Id: References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org, Alissa Cooper , draft-ietf-stox-im.all@tools.ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 12 Feb 2015 03:07:42 -0000 --Apple-Mail=_8F5408B1-ABDC-490A-9BC9-96C0B81797C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet = wrote: >=20 > On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: >> On 2/9/15 4:27 PM, Ben Campbell wrote: >>> (No hats) >>>=20 >>> Hi, >>>=20 >>> (I apologize that these comments are late in the process. Please = feel >>> free to defer them to last call.) >>>=20 >>> This version mostly looks good, but there are a few minor issues: >>>=20 >>> -- Message Size >>>=20 >>> It might be worth a discussion on message size limits (e.g. the SIP >>> MESSAGE method limits the size to 1300 octets except under some >>> pretty narrow circumstances.) >>=20 >> Thank you for pointing this out. I had glossed over it in my reading = of >> RFC 3428. I think it deserves a section of its own in the -im = document. >=20 > I propose the following text: >=20 > [RFC3428] specifies that (outside of a media session) the size of a > MESSAGE request is not allowed to exceed 1300 bytes. Although in > practice XMPP instant messages do not often exceed that size, = neither > [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP > stanzas. However, XMPP server deployments usually do limit the size > of stanzas in order to help prevent denial of service attacks, and > [RFC6120] states that if a server sets a maximum stanza size then = the > limit is not allowed to be less than 10,000 bytes. Because of this > mismatch, an XMPP-to-SIP gateway MUST return a > stanza error if an XMPP user attempts to send an XMPP message stanza > that would result in a SIP MESSAGE greater than 1300 bytes. >=20 That just stepped in a bit of discomfort on my part, in that I'm not = sure how a gateway that happened to support both stox-im and stox-chat = decides which to invoke. I'm mostly willing to ignore that particular = elephant, but would it be reasonable for an implementation to decide = that larger messages would get promoted to MSRP (assuming support at the = other end)? If so, the MUST return a seems to forbid = it. (While I'm still standing in it--what happens in stox-chat if the MSRP = side sends a message larger than the largest allowed? Apologies if the = draft talks about that--I don't have it in front of me.) > Peter >=20 > -- > Peter Saint-Andre > https://andyet.com/ --Apple-Mail=_8F5408B1-ABDC-490A-9BC9-96C0B81797C6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3BjmAAoJEIBWSmyV89QNg8sQAJHD+UOe8WBR+LK615Mx55Ag vpNYhPtikU8gPm/SkzNY9+nLzfPPIfgT2eEOTl0XHlTfGGrapABbiPcj1QwzkT+U 5RidMCe5BMzk4eN4jYDP0fMWkrfIDldaqer+8IzybTZIg/A5Z0iJi/ztsHUuFUd9 kl96//HalMCpqHYOdLCI97GBgBhiB9G6hnlD+DveB+uK0Ngvlbrv97JjgsEgA5ml OYvEgwZxpBFuVmZgyt1BrKBCYdkLwTXUDl94JHmjrSMgrNmDaJ1mperBB46icF5m 9M6K5UUTAXeRmNn3B+JxE0iHT398kLk3Wkh+Vtin4u0zsLCQLKbTgsjz9l2YgO/C 616YHDVAxYyLaB5rHH79Bk4xnn1E71FQnosw5T6Y0VmvaTJ7TrgrmYRh/eB/sdv7 1j0dn17US6nZSA56Q9KH6eAOHk+qiQ07oN0QzQH/9I2O7ZgL56nZ2WlPkKvicqX0 kNenU+0sQkrn4hiFTQFpGF5fyOhM/yViLaYCz6n8D5RHxEO+Jc8d+DtWqN8iEXQV R9iAGBN65yZTj7xCH+3tnGxsmaFdRXO5+oZFChb4wMoAZ9ueFGVmiW+N2j2vRj3O xqv50/DugQb5UPyKOKnumQXKiGGdTePOUyJXxtpnPhynbw1ko/7gLAQ7vmvSr4aQ KxgLrv4KrwJ72YwVORYt =PRJ5 -----END PGP SIGNATURE----- --Apple-Mail=_8F5408B1-ABDC-490A-9BC9-96C0B81797C6-- From nobody Wed Feb 11 19:13:30 2015 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 AF22E1A1B35 for ; Wed, 11 Feb 2015 19:13:28 -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 zEKjmMcNaoBP for ; Wed, 11 Feb 2015 19:13:24 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3821A1BE8 for ; Wed, 11 Feb 2015 19:13:23 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id a13so1171911igq.0 for ; Wed, 11 Feb 2015 19:13:23 -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=/iGP+gWFPoNWQF/KLNCW/Bc9FwaqI4W3iwqYXqBEQNg=; b=e66u1zLQSAMc+6HP0PySAQ93GCf8+SRPS5I6nQMinuRTy/3eIRD01usMQe5o6cKOI/ Zu35HZv2ftnMYfIpMbXqi3lGVmsEWIo0wKf6QNLVB+R29PopVKuhqADUrcDvQOz87jnH VKnIDEIK57i+TVAF0UkPcMb9DeylgE8/Tnb/ne0SS3Hgrffq7gOoUchZCJhMuQ/OtyPG ExE0O/Xr6lpDePPFWzovsqHN7D4ppyrmVIORU2UyTi6ZuJpfhl4CiPBX6XbYZ7qlyRDx bt/Me3uIigYP5AkxahdSzWFiSdLvU8o4+TNGVqxccYXYal5mbKx3oGO+zUS3ZJFi267Y 4fHQ== X-Gm-Message-State: ALoCoQkck0x2R2l8pxK3kP+RRhlc/VgKKB006Jt1eoDPmd3ZZxYzcnxqXDxP2++oY6b3ND4+aXgN X-Received: by 10.50.176.196 with SMTP id ck4mr1413077igc.40.1423710803378; Wed, 11 Feb 2015 19:13:23 -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 l15sm1649261iod.33.2015.02.11.19.13.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 19:13:22 -0800 (PST) Message-ID: <54DC1A52.8070401@andyet.net> Date: Wed, 11 Feb 2015 20:13:22 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> <54CFA75F.2040605@andyet.net> <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in> <54DC16B3.2020205@andyet.net> In-Reply-To: <54DC16B3.2020205@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08 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, 12 Feb 2015 03:13:28 -0000 On 2/11/15 7:57 PM, Peter Saint-Andre - &yet wrote: > On 2/9/15 4:44 PM, Alissa Cooper wrote: >> On Feb 2, 2015, at 8:35 AM, Peter Saint-Andre - &yet >> wrote: >> >>> On 1/31/15 5:09 PM, Alissa Cooper wrote: >>> >>>> = Section 7 = Is all of the delivery report behavior meant to be >>>> entirely optional to support, or should there be some normative >>>> requirements listed in this section? >>> >>> IMHO this is entirely optional (as with Section 6). >> >> I think the difference between Section 6 and Section 7 is that Section >> 6 at least gives a little narrative description of how to do the >> mapping for composing notifications, whereas in Section 7 there is no >> such description, it’s just illustrated by examples. So I would >> suggest adding a sentence or two that generically describes what the >> gateway in each direction should do to map an MSRP REPORT to an XMPP >> message receipt request/response and vice versa. This is obviously a >> small thing but seems like good practice. This can be dealt with >> during IETF LC. > > Yes, I see your point. Will add. Here is proposed text. ### An XMPP Message Receipts element of is to be mapped to an MSRP Success-Report header field with a value of "yes", and an XMPP Message Receipts element of is to be mapped to an MSRP REPORT request. A Success-Report header field with a value of "yes" in an MSRP SEND request is to be mapped to an XMPP Message Receipts element of , and an MSRP REPORT request is to be mapped to an XMPP message containing only a Message Receipts element of . There are no other suggested mappings (e.g., for the MSRP Failure- Report header field). ### Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 19:35:44 2015 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 5E1861A1EEC for ; Wed, 11 Feb 2015 19:35:41 -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 tY1wgPAiVJWu for ; Wed, 11 Feb 2015 19:35:36 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9951D1A1BED for ; Wed, 11 Feb 2015 19:35:36 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so1251467igk.1 for ; Wed, 11 Feb 2015 19:35:36 -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=hatISataf0LqVhbhBcxlLqzy8bNNYBicqExx7HH0wWA=; b=fuQuYkQyFcxpCTh9eMwNapGikGjrY3F8jtWLMb0ofwGgKKurTVC48o96b/tmew7mDb dC9fMtdTbU2px4/nMdQMM9tIeNvu1ambxoPTkzk1A/gB9UW68mtKXVijO/IPzNK8MNI7 3Fy5fWowC45l0AD6q9icLCMvCXXWAY+Y7tSV5Nke3jcSWqp9PsA04rD1rqppbD0ZYXhy UhzCefQTH2m9r0Edvugv1hBtnggmjGZOSxNFMw8vAKNeLxq8AiQFWMDfijMTaXrrzmeJ eQlN5rw9f8CimsMPrB9o8sjzwuxy+u4vjXFIOH3mFph/8H00E2IECWUEh823R7dGetSy 16aw== X-Gm-Message-State: ALoCoQkSWrhMD8ke0BIZTegzSd0LwR1g84dMOOeiPOVyll4agBWBSJ9xk77ABw/Jvou525LKwaAu X-Received: by 10.50.39.112 with SMTP id o16mr1522395igk.0.1423712136049; Wed, 11 Feb 2015 19:35:36 -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 a125sm1679363ioa.40.2015.02.11.19.35.34 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 19:35:35 -0800 (PST) Message-ID: <54DC1F86.6020709@andyet.net> Date: Wed, 11 Feb 2015 20:35:34 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell , Alissa Cooper References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> In-Reply-To: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] Comments on stox-chat-09 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, 12 Feb 2015 03:35:41 -0000 On 2/9/15 3:59 PM, Ben Campbell wrote: > (Resending to include STOX list) (No hats yet) > > Hi Peter and Alissa, > > I've looked over draft-ietf-stox-chat-09. It looks mostly good, but > there are still a few issues. > > Thanks! > > /Ben > > ---------------------------- > > MSRP Failure-Report headers: > > The examples assume the MSRP Failure-Report header field is set to > no. It's missing from the first SEND, but explicitly set to no in the > rest. The responses to SEND requests are left off throughout. This is > allowed, but non-default behavior for MSRP. If the intent is to set > Failure-Report: no, it would be good to say a few words about it. If > the intent is to leave that to the implementation, then I would > expect the examples to follow the defaults. As I see it: Because the XMPP message receipts specification (XEP-0184) does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no". > SIP Response From/To: > > The SIP responses swap the From and To from the associated requests. > This is not correct, To and From of a SIP response matches the To and > From of the original request. (More to the point, the To and From in > a response do not change to indicate the direction of the response > message.) I note that the groupchat draft had this issue at one > point, but it's been fixed. Noted. Will fix. > Session Termination > > I would like to see a little more prominent discussion about when the > XMPP side might terminate a session. It's mentioned in the > "Composing" section, but that seems to bury an important concept. I > note both primary examples show the SIP side terminating the > session--it would be nice to see one of those examples let the XMPP > side do it. (Is the "gone" composing state the only way this would > happen?) There is no concept of an explicit messaging session in RFC 6121: the conversation just trails off. The "gone" state is the only way to indicate that the session is over, but that's not defined in RFC 6121. > SIP CSeq: > > CSeq is missing from most SIP requests, except oddly for BYE > requests. Are you saying that CSeq is typically not included in SIP requests (even in dialogs) per the specs, or that we have mistakenly left them off here? I think the latter, but I want to make sure. > (And note that the CSeq of a BYE, sent by the peer that > initiated the INVITE, would never be "1") True. > Security Considerations, last sentence: > > The text non-normatively "suggests" the use of RFC3862 for end-to-end > protection. That seems to want to have it both ways (non-normative > and recommended) . I suggest either making that normative, or > reducing the strength to say RFC3862 could be used for this purpose. > (I realize we do this all the time with "ought to", but it seems like > we need a sharper line for something like e2e crypto.) See previous reply about the -im document. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 19:51:56 2015 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 4917A1A8A8D for ; Wed, 11 Feb 2015 19:51:55 -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 7nCQ42jJ7_0a for ; Wed, 11 Feb 2015 19:51:50 -0800 (PST) Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5C11A8A25 for ; Wed, 11 Feb 2015 19:51:50 -0800 (PST) Received: by mail-ig0-f174.google.com with SMTP id b16so1306832igk.1 for ; Wed, 11 Feb 2015 19:51:50 -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=dWqEOkcQpmVxLIa6yW18CcTK4dZH6Xwa3xrFtj9Si1g=; b=ZDKx7Owu0kVXkL/CXIXxEMmrqOMVTVwGVAKvJJfsb8ET+E33DCkFSfMGB4rHDM3t25 QZXS0m6F4msww+AEB39hNuQfQhwDQI/PweqScQ6rVRVSVdezkQB3pngUCqnpyq0d+Mil ghF+JZJtJny4ERyRTOHVFgrkMzE4hV8WUiAGJcUfUZwAZ1gxyjBjhEI/b4Of+KrQ3RLO sZ6mUWjUMH1E2uhnrstzDqQJl0vBuMQCZYPrx//aafI8LNEorVKHq4UaKUA+PBahBWIW DLcZWG9bop+AXD8cZup1UbnMnaAygDZ1pOunOGCxmDcOlAdSgjqjErKCikFFQmL3ElcV wzpQ== X-Gm-Message-State: ALoCoQlgn0Qq4LSvdDj3I2nUVGT2jgC6M9NBII1ToksNwbjdmT5wqBZ4962cRuDk/J7eMF+DQ6FR X-Received: by 10.107.167.135 with SMTP id q129mr2359094ioe.23.1423713110136; Wed, 11 Feb 2015 19:51: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 c6sm1704853ioe.37.2015.02.11.19.51.49 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Feb 2015 19:51:49 -0800 (PST) Message-ID: <54DC2354.6080309@andyet.net> Date: Wed, 11 Feb 2015 20:51:48 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> <54CFACEA.1040304@andyet.net> <54D55765.7050000@andyet.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08 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, 12 Feb 2015 03:51:55 -0000 On 2/9/15 4:01 PM, Ben Campbell wrote: > (Alissa pointed out that I left the STOX list of of these--resending.) > > One more thing: The SIP CSeq headers are incorrect in several places. CSeq is missing from most SIP messages, except in BYE requests. > > (This is also true for stox-chat. I will send notes on that separately.) See clarifying question in the stox-chat thread. >>> On 2/6/15 4:34 PM, Ben Campbell wrote: >>>> (No hats) >>>> >>>> Hi Peter and Alissa, >>>> >>>> I just reviewed version groupchat-09, and it looks good. I just noticed a few nits: >>>> >>>> Section 4: The bulleted text for example.org and chat.example.org don't seem to quite match the figure. The figure calls both the focus and switch chat.example.org (which may not be what you want. Example.org is a SIP proxy. Correct. This is better: o example.org -- a SIP proxy with an associated signaling gateway ("S2X GW") to XMPP. o chat.example.org -- a SIP-based conference focus and MSRP switch with an associated gateway ("M2X GW") to XMPP. >>>> 5.1: The indented paragraph about MSRP URLs could be interpreted to mean that the explicit port is only required for a literal address. In fact, it's always required. How's this? There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have no meaning outside the scope of that session. The authority component of the MSRP URI here MUST contain the XMPP-to-MSRP gateway hostname or numeric IP address (as well as, in accordance with [RFC4975], an explicit port number). Thanks again for your careful reviews. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Wed Feb 11 21:01:14 2015 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 AA6031A8FD5 for ; Wed, 11 Feb 2015 21:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 EBM4jthHNxSj for ; Wed, 11 Feb 2015 21:01:11 -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 C788F1A8AD9 for ; Wed, 11 Feb 2015 21:01:11 -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 t1C515lO058004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 23:01:06 -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] Content-Type: multipart/signed; boundary="Apple-Mail=_2372FFEC-BD24-40FF-ACD1-BD0CB6E12AC7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Ben Campbell In-Reply-To: <54DC1F86.6020709@andyet.net> Date: Wed, 11 Feb 2015 23:01:05 -0600 X-Mao-Original-Outgoing-Id: 445410065.22193-0b6895e9ebb086e11720bea1c105908a Message-Id: <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com> References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> <54DC1F86.6020709@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] Comments on stox-chat-09 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, 12 Feb 2015 05:01:13 -0000 --Apple-Mail=_2372FFEC-BD24-40FF-ACD1-BD0CB6E12AC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet = wrote: >=20 > On 2/9/15 3:59 PM, Ben Campbell wrote: >> (Resending to include STOX list) (No hats yet) >>=20 >> Hi Peter and Alissa, >>=20 >> I've looked over draft-ietf-stox-chat-09. It looks mostly good, but >> there are still a few issues. >>=20 >> Thanks! >>=20 >> /Ben >>=20 >> ---------------------------- >>=20 >> MSRP Failure-Report headers: >>=20 >> The examples assume the MSRP Failure-Report header field is set to >> no. It's missing from the first SEND, but explicitly set to no in the >> rest. The responses to SEND requests are left off throughout. This is >> allowed, but non-default behavior for MSRP. If the intent is to set >> Failure-Report: no, it would be good to say a few words about it. If >> the intent is to leave that to the implementation, then I would >> expect the examples to follow the defaults. >=20 > As I see it: >=20 > Because the XMPP message receipts specification (XEP-0184) does not = support failure reports, there is no mapping for the MSRP Failure-Report = header field and gateways SHOULD set that header field to "no". >=20 That's reasonable. A few words to that effect might help keep others = from tripping over it. [...] >> Session Termination >>=20 >> I would like to see a little more prominent discussion about when the >> XMPP side might terminate a session. It's mentioned in the >> "Composing" section, but that seems to bury an important concept. I >> note both primary examples show the SIP side terminating the >> session--it would be nice to see one of those examples let the XMPP >> side do it. (Is the "gone" composing state the only way this would >> happen?) >=20 > There is no concept of an explicit messaging session in RFC 6121: the = conversation just trails off. The "gone" state is the only way to = indicate that the session is over, but that's not defined in RFC 6121. Got it. Then my only real comment here is it might be nice (but = completely optional) to say something about that in the main flow = examples, instead of bury it in the "composing" state section. >=20 >> SIP CSeq: >>=20 >> CSeq is missing from most SIP requests, except oddly for BYE >> requests. >=20 > Are you saying that CSeq is typically not included in SIP requests = (even in dialogs) per the specs, or that we have mistakenly left them = off here? I think the latter, but I want to make sure. >=20 The latter. "most SIP requests" should have been "most SIP requests in = this draft". [...] --Apple-Mail=_2372FFEC-BD24-40FF-ACD1-BD0CB6E12AC7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3DORAAoJEIBWSmyV89QNcMoQAI4nIY7PwYq8UlDJV+pE2uTX Vwt+mxoHwXoCH9Uc360ZLuVKbz5jYj0sq5kC1ipLbsmDKxaZ7krFjHIGTYZKMud6 rHArP9OUbI3WVznuSDb88FCpitUhLIuuTlg/vETBrmuhOE0l7eqtkJ4Zwa22uTjw QtaZhBLpMtV1WypIUXzzgMZsLg9Ic0yhXmF4iyAIVVbMAhRiWpTs2ZRg3Nns1xy/ EI8gHEXE1aZH7l0OP6XE9uCYRwlhY97suiBabr0LsJ8DD9iKQvxpzj+KRdNYhOZr 3nbgbyQrGCtYACu7Ms8ntmCqb0ggVfx7R6fkGy7TTzw712I1CKcKzCnCWisTFctH qETYVrECp1uV7bSz7RpdBRyIFV7zJmwq/M38CZKbhsWROPhk7kJCwuJ6THGMECzl zn+Lwj+dyA7zQPmqLJ5xfcTLhtfrQQR8Gx/gorxqhgnvvoz4i6QJKcdicC/ivq4U hAu97YOG0Y0/gMO4/7ffjEQtXaKDCbfQiZZNprFNLrV/46zxCiyXX+zEMSEtFrd2 Vw7Fn3J/rEHK2SVOeg+0jgkqDm/5ccs/TBH6P3r4FDds5HqpVXwRlOFyAMGx9iVi nG5kt8oCC1gR2RfuI6oXUk6rWkEuMOiIxoEUtO2D6yev5TuHbwOXR3zWHG5IDiSK c0yGhzOnDDZxND+5+j0/ =/ePu -----END PGP SIGNATURE----- --Apple-Mail=_2372FFEC-BD24-40FF-ACD1-BD0CB6E12AC7-- From nobody Wed Feb 11 21:02:39 2015 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 513C31A8FD5 for ; Wed, 11 Feb 2015 21:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 mKp2Ie0gZ8Wt for ; Wed, 11 Feb 2015 21:02:35 -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 538721A901E for ; Wed, 11 Feb 2015 21:02:35 -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 t1C52TCB058113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2015 23:02:30 -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] Content-Type: multipart/signed; boundary="Apple-Mail=_F78467A6-DE6B-475C-983E-ED4F3AA615D2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Ben Campbell In-Reply-To: <54DC2354.6080309@andyet.net> Date: Wed, 11 Feb 2015 23:02:28 -0600 X-Mao-Original-Outgoing-Id: 445410148.354943-d9c422c354139cb499026a8bcf31d4a1 Message-Id: <6E47F7E8-F809-486E-93F6-A93B6F889260@nostrum.com> References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in> <54CFACEA.1040304@andyet.net> <54D55765.7050000@andyet.net> <54DC2354.6080309@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] AD evaluation: draft-ietf-stox-groupchat-08 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, 12 Feb 2015 05:02:37 -0000 --Apple-Mail=_F78467A6-DE6B-475C-983E-ED4F3AA615D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 11, 2015, at 9:51 PM, Peter Saint-Andre - &yet = wrote: >=20 > On 2/9/15 4:01 PM, Ben Campbell wrote: >> (Alissa pointed out that I left the STOX list of of = these--resending.) >>=20 >> One more thing: The SIP CSeq headers are incorrect in several places. = CSeq is missing from most SIP messages, except in BYE requests. >>=20 >> (This is also true for stox-chat. I will send notes on that = separately.) >=20 > See clarifying question in the stox-chat thread. See answer in same. >=20 >>>> On 2/6/15 4:34 PM, Ben Campbell wrote: >>>>> (No hats) >>>>>=20 >>>>> Hi Peter and Alissa, >>>>>=20 >>>>> I just reviewed version groupchat-09, and it looks good. I just = noticed a few nits: >>>>>=20 >>>>> Section 4: The bulleted text for example.org and chat.example.org = don't seem to quite match the figure. The figure calls both the focus = and switch chat.example.org (which may not be what you want. = Example.org is a SIP proxy. >=20 > Correct. This is better: >=20 > o example.org -- a SIP proxy with an associated signaling gateway > ("S2X GW") to XMPP. >=20 > o chat.example.org -- a SIP-based conference focus and MSRP switch > with an associated gateway ("M2X GW") to XMPP. Agreed. >=20 >>>>> 5.1: The indented paragraph about MSRP URLs could be interpreted = to mean that the explicit port is only required for a literal address. = In fact, it's always required. >=20 > How's this? >=20 > There is no direct mapping for the MSRP URIs. In fact MSRP URIs > identify a session of instant messages at a particular device; > they are ephemeral and have no meaning outside the scope of that > session. The authority component of the MSRP URI here MUST > contain the XMPP-to-MSRP gateway hostname or numeric IP address > (as well as, in accordance with [RFC4975], an explicit port > number). >=20 WFM --Apple-Mail=_F78467A6-DE6B-475C-983E-ED4F3AA615D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU3DPkAAoJEIBWSmyV89QNTmgQAMhaOQYlyuoJ7VtSo5ccv+WN taeqrpu2I+ijrZ4G5AgUF1dKQzZhv6jDZjstGDiqn1cI/sxSEwYi3tS1sC4izy7g mvFxiopF7KeCi0k2lH/fKNm4VbsFgR3mfK0no9UR2nSmIkZPhlh3ENVzNXRi7EjH yaY8Lpx1h1JCqsB579/Nvf8ynLq1uh8FHvO8xJPgWInl3wZ+ICNANUvFF6v2g25/ dv+GERGtPZ0ojDp5IDhSKv44zYmtVPWrVYtLCofyc9GuspIOBb0C7iqFFIhqYcBC 88gP6WF/T4YiAlkedJHR2yhmj6kMfko47u1lmbPQKUbUgoBA+JyYkyaMj5p7oA3/ 8BMJ4vGnG3PmOszuVbjNpxFkoZkcfCDEmKrY8hpsRNKcQ/J5vKiYAoX3VZj5KMP2 XxKizj+WJAqfIALVznRS2RKKZ5FF4OzTKpTBbLVyKKfSq4roJ2DOj/ah01hfJwtl NRB5JSio3b1YlqcS1FFcmYXSdF7OsGcBobQ6gHoK2jMjclJvicIN7cGp+AVkj8je RId2vXE06pwYjCHqyAqwpP8GGaj07vw3BQ8vT1fRvqIr4PuTcPCbQnt2zrbKqOiY 2gvPyEchLtQRsB71l986nwxqGdrm2Dm9/RofLnZ3idOXaalbjvPFnICbF2HXoEVs LcA2DsbiejZQkVtYSh/6 =G2d1 -----END PGP SIGNATURE----- --Apple-Mail=_F78467A6-DE6B-475C-983E-ED4F3AA615D2-- From nobody Thu Feb 12 14:02:43 2015 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 98A931A038C for ; Thu, 12 Feb 2015 14:02:41 -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 0ZAvjr4BYgw7 for ; Thu, 12 Feb 2015 14:02:39 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DFB1A00EA for ; Thu, 12 Feb 2015 14:02:38 -0800 (PST) Received: by iecar1 with SMTP id ar1so15459561iec.0 for ; Thu, 12 Feb 2015 14:02:38 -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=cBrSaQwJrwuvPBLaMX5rYlb9mm9d0m/ysik/XO0CAJ0=; b=CtEOE6du0yo5ChEfr2/dOlHawYyRxU+P8Odh3ZIbmtVcqkuH+Eam4OBTuxQ/KgM3j8 fqsHJfdGkg0O2Jan49awmjAjT0nlYXclWERBsPqLAtwnTW2ewWkH8ewXM+lhm13Qn4yK dIfasqV/aV6lV8NJndhVCoAibsKvZtZ1NXpw0of2KkQVh3OB5BnMzE0uP3K5scfvc60Z mKJUlxMx/8lHil2UPAt/66YQw90RYOVaeeQyaHHjL1/WYX7hgR2aelpywsj5gZwRnVw5 Z/rw851p5hgvkpirEDq2VmhVrIOt4sAsk1lz7kjBp4TkP1BX7fidrLhG4VcVI8eJQtzo pkWQ== X-Gm-Message-State: ALoCoQn4tXeemY6I9QWjyFWF0RhEfg2hwrkNl3wZWt9QpoY79aHZnhBqN6FjXeZXhxbeHTgniv2K X-Received: by 10.43.100.67 with SMTP id cv3mr11076631icc.92.1423778558247; Thu, 12 Feb 2015 14:02:38 -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 j6sm2006505igv.4.2015.02.12.14.02.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 14:02:37 -0800 (PST) Message-ID: <54DD22FC.9000907@andyet.net> Date: Thu, 12 Feb 2015 15:02:36 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> <54DC1F86.6020709@andyet.net> <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com> In-Reply-To: <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper Subject: Re: [Stox] Comments on stox-chat-09 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, 12 Feb 2015 22:02:42 -0000 On 2/11/15 10:01 PM, Ben Campbell wrote: > >> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet >> wrote: >> >> On 2/9/15 3:59 PM, Ben Campbell wrote: >>> (Resending to include STOX list) (No hats yet) >>> >>> Hi Peter and Alissa, >>> >>> I've looked over draft-ietf-stox-chat-09. It looks mostly good, >>> but there are still a few issues. >>> >>> Thanks! >>> >>> /Ben >>> >>> ---------------------------- >>> >>> MSRP Failure-Report headers: >>> >>> The examples assume the MSRP Failure-Report header field is set >>> to no. It's missing from the first SEND, but explicitly set to no >>> in the rest. The responses to SEND requests are left off >>> throughout. This is allowed, but non-default behavior for MSRP. >>> If the intent is to set Failure-Report: no, it would be good to >>> say a few words about it. If the intent is to leave that to the >>> implementation, then I would expect the examples to follow the >>> defaults. >> >> As I see it: >> >> Because the XMPP message receipts specification (XEP-0184) does not >> support failure reports, there is no mapping for the MSRP >> Failure-Report header field and gateways SHOULD set that header >> field to "no". >> > > That's reasonable. A few words to that effect might help keep others > from tripping over it. Here's what I have in Section 7 of my working copy... Because the XMPP Message Receipts specification does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no". > [...] > >>> Session Termination >>> >>> I would like to see a little more prominent discussion about when >>> the XMPP side might terminate a session. It's mentioned in the >>> "Composing" section, but that seems to bury an important concept. >>> I note both primary examples show the SIP side terminating the >>> session--it would be nice to see one of those examples let the >>> XMPP side do it. (Is the "gone" composing state the only way >>> this would happen?) >> >> There is no concept of an explicit messaging session in RFC 6121: >> the conversation just trails off. The "gone" state is the only way >> to indicate that the session is over, but that's not defined in RFC >> 6121. > > Got it. Then my only real comment here is it might be nice (but > completely optional) to say something about that in the main flow > examples, instead of bury it in the "composing" state section. Perhaps this at the end of Section 4: In addition, there is no explicit method defined in [RFC6121] for an XMPP user to formally terminate a chat session, so a gateway would need to listen for a "gone" chat state notification from the XMPP user or institute a timer that considers the XMPP informal chat session to be ended after some amount of time has elapsed. >>> SIP CSeq: >>> >>> CSeq is missing from most SIP requests, except oddly for BYE >>> requests. >> >> Are you saying that CSeq is typically not included in SIP requests >> (even in dialogs) per the specs, or that we have mistakenly left >> them off here? I think the latter, but I want to make sure. >> > > The latter. "most SIP requests" should have been "most SIP requests > in this draft". OK, we'll add those in. I notice that the presence document has them... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 12 14:28:18 2015 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 080141A1A99 for ; Thu, 12 Feb 2015 14:28:16 -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 tCRjl9EFfJvg for ; Thu, 12 Feb 2015 14:28:12 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D8C61A0AF7 for ; Thu, 12 Feb 2015 14:28:06 -0800 (PST) Received: by iebtr6 with SMTP id tr6so4921864ieb.10 for ; Thu, 12 Feb 2015 14:28:05 -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=ytYfdoZabcUtS0q7orscSyCWYQoSAFaqL9+Kma6eQq8=; b=eb2q4kLW+luXk9hXnyES/PcLXi4PddnMtriEP/dCzSsy9AVrzauY4fiPwACg4KkqAj ctCkvEH//l+jd0BXws5BbkoeNXv8ZJbhYZg7boFJt2/DZoCyudijr62IpqFU87g/BvTH 2M5jPlmuWuyo4yiWoL0lcAHRGU4SUDKyqE4y3ztF6AHmG1M7T6EqtRg1nwFqxqzaUDTE uMvbV3n2WMKiAdJl57gL1pR6lb6HPDCdk04NY5z0X90N+coKR/g/A/o9t885ugRqMINV /lS/ruiPX9iYakXJ0c6BhPZk2EjFDfRGTwf1Eo9gswZ0xDPnXK99HyUsNhY23exVy7ZL kp1w== X-Gm-Message-State: ALoCoQmNdbi7wIl5A1JYRzOV6msK3xz4co9SS51cFwXqHL3aI34MaSLjoR5Ufkj4Dmms3yS14vS2 X-Received: by 10.42.153.132 with SMTP id m4mr11144230icw.49.1423780085686; Thu, 12 Feb 2015 14:28:05 -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 ip8sm2032447igb.17.2015.02.12.14.28.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 14:28:05 -0800 (PST) Message-ID: <54DD28F4.7070200@andyet.net> Date: Thu, 12 Feb 2015 15:28:04 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper , draft-ietf-stox-im.all@tools.ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 12 Feb 2015 22:28:16 -0000 On 2/11/15 8:07 PM, Ben Campbell wrote: > >> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet >> wrote: >> >> On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: >>> On 2/9/15 4:27 PM, Ben Campbell wrote: >>>> (No hats) >>>> >>>> Hi, >>>> >>>> (I apologize that these comments are late in the process. >>>> Please feel free to defer them to last call.) >>>> >>>> This version mostly looks good, but there are a few minor >>>> issues: >>>> >>>> -- Message Size >>>> >>>> It might be worth a discussion on message size limits (e.g. the >>>> SIP MESSAGE method limits the size to 1300 octets except under >>>> some pretty narrow circumstances.) >>> >>> Thank you for pointing this out. I had glossed over it in my >>> reading of RFC 3428. I think it deserves a section of its own in >>> the -im document. >> >> I propose the following text: >> >> [RFC3428] specifies that (outside of a media session) the size of >> a MESSAGE request is not allowed to exceed 1300 bytes. Although >> in practice XMPP instant messages do not often exceed that size, >> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of >> XMPP stanzas. However, XMPP server deployments usually do limit >> the size of stanzas in order to help prevent denial of service >> attacks, and [RFC6120] states that if a server sets a maximum >> stanza size then the limit is not allowed to be less than 10,000 >> bytes. Because of this mismatch, an XMPP-to-SIP gateway MUST >> return a stanza error if an XMPP user attempts >> to send an XMPP message stanza that would result in a SIP MESSAGE >> greater than 1300 bytes. >> > > That just stepped in a bit of discomfort on my part, in that I'm not > sure how a gateway that happened to support both stox-im and > stox-chat decides which to invoke. I'm mostly willing to ignore that > particular elephant, but would it be reasonable for an implementation > to decide that larger messages would get promoted to MSRP (assuming > support at the other end)? If so, the MUST return a > seems to forbid it. We've been treating -im (page mode) and -chat (session mode) as entirely separate things. However, you're right that "upgrading" from page mode (SIP MESSAGE) to session mode (MSRP) might make sense in some situations. Without hearing in detail from those who've implemented such systems, I would be hesitant to specify guidelines for when such an upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and leaving the upgrade logic up to implementations. > (While I'm still standing in it--what happens in stox-chat if the > MSRP side sends a message larger than the largest allowed? Apologies > if the draft talks about that--I don't have it in front of me.) That's messy. :/ Ideally we'd be talking about unchunked MSRP messages. In RFC 3921/6121 we don't have the concept of chunking for regular chat messages, and the only chunking method we have in XMPP is not used for chat messages but for file transfer (XEP-0047). For chat purposes, a typical XMPP client won't have the necessary application logic to handle chunked messages and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a message. However, I don't see a way in RFC 4975 for an entity such as a gateway to advertise that it doesn't support chunking. Although in theory the max-size a-line could help, that applies to full messages before chunking. I also don't see a way in RFC 4975 to reject a particular MSRP SEND because it's too big. Sigh. Peter From nobody Thu Feb 12 15:00:42 2015 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 439F61A00A9 for ; Thu, 12 Feb 2015 15:00:40 -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 HAo36XiZC1Zh for ; Thu, 12 Feb 2015 15:00:38 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3615F1A008F for ; Thu, 12 Feb 2015 15:00:38 -0800 (PST) Received: by iebtr6 with SMTP id tr6so5048405ieb.7 for ; Thu, 12 Feb 2015 15:00:37 -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=5nN8ZvHexTsxvUCV2YXSN2CNg9x73i8KFwM01QgKS8o=; b=YM1bADaGYJS92zcXgXjka8wyjPjFNkrLqiHvIeqKB+wxA+8SLpWV7duMwFxUKif/U7 icS1tbyvo95kTW1Zwr6haQNhyX2Wa5iFS5fdFHWAdKhMl9Dv2stRt309Cos8ZABEiZCw Otn/cA6X88H+y0sW4NHGILcS4duO4ik8J9ewqt+QRrIYFEWkQOO8hv5gIjbJR7KtB897 XXGhRnxx8HT4/g0Ow/sqW/idrhV5PQyDWv/Yz4+Sc2TV3PVdQgVHdrJwvQ7/XaoCfV2p vOhzVNQspVcXfmrdHs3U5szL9zvh8333HuzyE2fT1UDAhMYaTZxs2YThbLdBvkfMb3wr O6fA== X-Gm-Message-State: ALoCoQmBgDlYmtjawKWEvzM3oInxt71GYFxbkl9A+a6eQIesDNKDXtzQvuD40ysN7EppiWqesw5O X-Received: by 10.42.199.211 with SMTP id et19mr11527611icb.9.1423782037736; Thu, 12 Feb 2015 15:00:37 -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 w3sm2383671igz.1.2015.02.12.15.00.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 15:00:36 -0800 (PST) Message-ID: <54DD3093.3030501@andyet.net> Date: Thu, 12 Feb 2015 16:00:35 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> In-Reply-To: <54DD28F4.7070200@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: stox@ietf.org, Alissa Cooper , draft-ietf-stox-im.all@tools.ietf.org Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 12 Feb 2015 23:00:40 -0000 On 2/12/15 3:28 PM, Peter Saint-Andre - &yet wrote: > On 2/11/15 8:07 PM, Ben Campbell wrote: >> >>> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet >>> wrote: >>> >>> On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: >>>> On 2/9/15 4:27 PM, Ben Campbell wrote: >>>>> (No hats) >>>>> >>>>> Hi, >>>>> >>>>> (I apologize that these comments are late in the process. >>>>> Please feel free to defer them to last call.) >>>>> >>>>> This version mostly looks good, but there are a few minor >>>>> issues: >>>>> >>>>> -- Message Size >>>>> >>>>> It might be worth a discussion on message size limits (e.g. the >>>>> SIP MESSAGE method limits the size to 1300 octets except under >>>>> some pretty narrow circumstances.) >>>> >>>> Thank you for pointing this out. I had glossed over it in my >>>> reading of RFC 3428. I think it deserves a section of its own in >>>> the -im document. >>> >>> I propose the following text: >>> >>> [RFC3428] specifies that (outside of a media session) the size of >>> a MESSAGE request is not allowed to exceed 1300 bytes. Although >>> in practice XMPP instant messages do not often exceed that size, >>> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of >>> XMPP stanzas. However, XMPP server deployments usually do limit >>> the size of stanzas in order to help prevent denial of service >>> attacks, and [RFC6120] states that if a server sets a maximum >>> stanza size then the limit is not allowed to be less than 10,000 >>> bytes. Because of this mismatch, an XMPP-to-SIP gateway MUST >>> return a stanza error if an XMPP user attempts >>> to send an XMPP message stanza that would result in a SIP MESSAGE >>> greater than 1300 bytes. >>> >> >> That just stepped in a bit of discomfort on my part, in that I'm not >> sure how a gateway that happened to support both stox-im and >> stox-chat decides which to invoke. I'm mostly willing to ignore that >> particular elephant, but would it be reasonable for an implementation >> to decide that larger messages would get promoted to MSRP (assuming >> support at the other end)? If so, the MUST return a >> seems to forbid it. > > We've been treating -im (page mode) and -chat (session mode) as entirely > separate things. However, you're right that "upgrading" from page mode > (SIP MESSAGE) to session mode (MSRP) might make sense in some > situations. Without hearing in detail from those who've implemented such > systems, I would be hesitant to specify guidelines for when such an > upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and > leaving the upgrade logic up to implementations. Proposed text: ### 6. Message Size [RFC3428] specifies that (outside of a media session) the size of a MESSAGE request is not allowed to exceed 1300 bytes. Although in practice XMPP instant messages do not often exceed that size, neither [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP stanzas. However, XMPP server deployments usually do limit the size of stanzas in order to help prevent denial of service attacks, and [RFC6120] states that if a server sets a maximum stanza size then the limit is not allowed to be less than 10,000 bytes. Because of this mismatch, an XMPP-to-SIP gateway SHOULD return a stanza error if an XMPP user attempts to send an XMPP message stanza that would result in a SIP MESSAGE greater than 1300 bytes. Although such a gateway might decide to "upgrade" from page mode to session mode using the Message Session Relay Protocol (MSRP) and thus treating the instant message as part of a chat session as described in [I-D.ietf-stox-chat], such behavior is application-specific and this document provides no guidelines for how to complete such an upgrade. ### From nobody Thu Feb 12 18:31:58 2015 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 062FB1A0E10 for ; Thu, 12 Feb 2015 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 UVC1NfRRITAq for ; Thu, 12 Feb 2015 18:31:54 -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 8812C1A0AF7 for ; Thu, 12 Feb 2015 18:31:54 -0800 (PST) Received: from [192.168.5.249] (ip-64-134-146-224.public.wayport.net [64.134.146.224]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1D2VYFH056755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 20:31:43 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host ip-64-134-146-224.public.wayport.net [64.134.146.224] claimed to be [192.168.5.249] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54DD22FC.9000907@andyet.net> Date: Thu, 12 Feb 2015 20:31:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0432370E-468B-4C87-914C-AACA55B03877@nostrum.com> References: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com> <54DC1F86.6020709@andyet.net> <2EF02818-EB21-494C-95C9-1A1961BA912A@nostrum.com> <54DD22FC.9000907@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "stox@ietf.org" , Alissa Cooper Subject: Re: [Stox] Comments on stox-chat-09 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: Fri, 13 Feb 2015 02:31:57 -0000 All points WFM. Thanks! Ben. > On Feb 12, 2015, at 4:02 PM, Peter Saint-Andre - &yet w= rote: >=20 >> On 2/11/15 10:01 PM, Ben Campbell wrote: >>=20 >>> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet >>> wrote: >>>=20 >>>> On 2/9/15 3:59 PM, Ben Campbell wrote: >>>> (Resending to include STOX list) (No hats yet) >>>>=20 >>>> Hi Peter and Alissa, >>>>=20 >>>> I've looked over draft-ietf-stox-chat-09. It looks mostly good, >>>> but there are still a few issues. >>>>=20 >>>> Thanks! >>>>=20 >>>> /Ben >>>>=20 >>>> ---------------------------- >>>>=20 >>>> MSRP Failure-Report headers: >>>>=20 >>>> The examples assume the MSRP Failure-Report header field is set >>>> to no. It's missing from the first SEND, but explicitly set to no >>>> in the rest. The responses to SEND requests are left off >>>> throughout. This is allowed, but non-default behavior for MSRP. >>>> If the intent is to set Failure-Report: no, it would be good to >>>> say a few words about it. If the intent is to leave that to the >>>> implementation, then I would expect the examples to follow the >>>> defaults. >>>=20 >>> As I see it: >>>=20 >>> Because the XMPP message receipts specification (XEP-0184) does not >>> support failure reports, there is no mapping for the MSRP >>> Failure-Report header field and gateways SHOULD set that header >>> field to "no". >>=20 >> That's reasonable. A few words to that effect might help keep others >> from tripping over it. >=20 > Here's what I have in Section 7 of my working copy... >=20 > Because the XMPP Message Receipts specification does not support > failure reports, there is no mapping for the MSRP Failure-Report > header field and gateways SHOULD set that header field to "no". >=20 >> [...] >>=20 >>>> Session Termination >>>>=20 >>>> I would like to see a little more prominent discussion about when >>>> the XMPP side might terminate a session. It's mentioned in the >>>> "Composing" section, but that seems to bury an important concept. >>>> I note both primary examples show the SIP side terminating the >>>> session--it would be nice to see one of those examples let the >>>> XMPP side do it. (Is the "gone" composing state the only way >>>> this would happen?) >>>=20 >>> There is no concept of an explicit messaging session in RFC 6121: >>> the conversation just trails off. The "gone" state is the only way >>> to indicate that the session is over, but that's not defined in RFC >>> 6121. >>=20 >> Got it. Then my only real comment here is it might be nice (but >> completely optional) to say something about that in the main flow >> examples, instead of bury it in the "composing" state section. >=20 > Perhaps this at the end of Section 4: >=20 > In addition, there is no explicit method defined in [RFC6121] for an > XMPP user to formally terminate a chat session, so a gateway would > need to listen for a "gone" chat state notification from the XMPP > user or institute a timer that considers the XMPP informal chat > session to be ended after some amount of time has elapsed. >=20 >>>> SIP CSeq: >>>>=20 >>>> CSeq is missing from most SIP requests, except oddly for BYE >>>> requests. >>>=20 >>> Are you saying that CSeq is typically not included in SIP requests >>> (even in dialogs) per the specs, or that we have mistakenly left >>> them off here? I think the latter, but I want to make sure. >>=20 >> The latter. "most SIP requests" should have been "most SIP requests >> in this draft". >=20 > OK, we'll add those in. I notice that the presence document has them... >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Thu Feb 12 18:59:05 2015 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 0C6AC1A1A29 for ; Thu, 12 Feb 2015 18:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 bIUAO2IW-reT for ; Thu, 12 Feb 2015 18:59:01 -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 D6E161A1A6A for ; Thu, 12 Feb 2015 18:59:00 -0800 (PST) Received: from [10.9.94.181] (mobile-166-173-058-122.mycingular.net [166.173.58.122]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1D2woLk058665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 20:58:53 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-122.mycingular.net [166.173.58.122] claimed to be [10.9.94.181] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54DD28F4.7070200@andyet.net> Date: Thu, 12 Feb 2015 20:58:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 02:59:03 -0000 > On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet w= rote: >=20 >> On 2/11/15 8:07 PM, Ben Campbell wrote: >>=20 >>> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet >>> wrote: >>>=20 >>>> On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: >>>>> On 2/9/15 4:27 PM, Ben Campbell wrote: >>>>> (No hats) >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> (I apologize that these comments are late in the process. >>>>> Please feel free to defer them to last call.) >>>>>=20 >>>>> This version mostly looks good, but there are a few minor >>>>> issues: >>>>>=20 >>>>> -- Message Size >>>>>=20 >>>>> It might be worth a discussion on message size limits (e.g. the >>>>> SIP MESSAGE method limits the size to 1300 octets except under >>>>> some pretty narrow circumstances.) >>>>=20 >>>> Thank you for pointing this out. I had glossed over it in my >>>> reading of RFC 3428. I think it deserves a section of its own in >>>> the -im document. >>>=20 >>> I propose the following text: >>>=20 >>> [RFC3428] specifies that (outside of a media session) the size of >>> a MESSAGE request is not allowed to exceed 1300 bytes. Although >>> in practice XMPP instant messages do not often exceed that size, >>> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of >>> XMPP stanzas. However, XMPP server deployments usually do limit >>> the size of stanzas in order to help prevent denial of service >>> attacks, and [RFC6120] states that if a server sets a maximum >>> stanza size then the limit is not allowed to be less than 10,000 >>> bytes. Because of this mismatch, an XMPP-to-SIP gateway MUST >>> return a stanza error if an XMPP user attempts >>> to send an XMPP message stanza that would result in a SIP MESSAGE >>> greater than 1300 bytes. >>>=20 >>=20 >> That just stepped in a bit of discomfort on my part, in that I'm not >> sure how a gateway that happened to support both stox-im and >> stox-chat decides which to invoke. I'm mostly willing to ignore that >> particular elephant, but would it be reasonable for an implementation >> to decide that larger messages would get promoted to MSRP (assuming >> support at the other end)? If so, the MUST return a >> seems to forbid it. >=20 > We've been treating -im (page mode) and -chat (session mode) as entirely s= eparate things. However, you're right that "upgrading" from page mode (SIP M= ESSAGE) to session mode (MSRP) might make sense in some situations. Without h= earing in detail from those who've implemented such systems, I would be hesi= tant to specify guidelines for when such an upgrade makes sense. Thus I'd be= most comfortable with a SHOULD here and leaving the upgrade logic up to imp= lementations. A SHOULD works for me. Would it make sense to mention the possibility of upg= rading, even if the procedures are not specified? >=20 >> (While I'm still standing in it--what happens in stox-chat if the >> MSRP side sends a message larger than the largest allowed? Apologies >> if the draft talks about that--I don't have it in front of me.) >=20 > That's messy. :/ >=20 > Ideally we'd be talking about unchunked MSRP messages. Yes, or a message reassembled from chunks by the gateway. > In RFC 3921/6121 we don't have the concept of chunking afor regular chat m= essages, and the only chunking method we have in XMPP is not used for chat m= essages but for file transfer (XEP-0047). For chat purposes, a typical XMPP c= lient won't have the necessary application logic to handle chunked messages .= .. Right, that would be the gateway's problem. I had assumed that the since the= gateway is for all practical purposes the MSRP endpoint, it would reassembl= e any chunks before sending toward the XMPP side. > and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a message. Hmm, you've lost me here. Do you mean the gateway can't assume it's okay to c= hunk towards the XMPP client (which makes sense) or towards the MSRP client?= > However, I don't see a way in RFC 4975 for an entity such as a gateway to a= dvertise that it doesn't support chunking. There's not a way, because the assumption has always been that any MSRP endp= oint can at least receive chunked messages. > Although in theory the max-size a-line could help, that applies to full me= ssages before chunking. I also don't see a way in RFC 4975 to reject a parti= cular MSRP SEND because it's too big. You can sort of do this with 413. But I think it's the whole message size th= at is important here, not the size of a particular SEND request. >=20 > Sigh. >=20 > Peter >=20 From nobody Thu Feb 12 19:00:20 2015 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 F183C1A0252 for ; Thu, 12 Feb 2015 19:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7B-Fg2mh30qe for ; Thu, 12 Feb 2015 19:00:18 -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 0761C1A0211 for ; Thu, 12 Feb 2015 19:00:18 -0800 (PST) Received: from [10.9.94.181] (mobile-166-173-058-122.mycingular.net [166.173.58.122]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1D305lP058712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 21:00:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-122.mycingular.net [166.173.58.122] claimed to be [10.9.94.181] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54DD3093.3030501@andyet.net> Date: Thu, 12 Feb 2015 21:00:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> <54DD3093.3030501@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 03:00:20 -0000 > On Feb 12, 2015, at 5:00 PM, Peter Saint-Andre - &yet w= rote: >=20 >> On 2/12/15 3:28 PM, Peter Saint-Andre - &yet wrote: >>> On 2/11/15 8:07 PM, Ben Campbell wrote: >>>=20 >>>> On Feb 11, 2015, at 8:47 PM, Peter Saint-Andre - &yet >>>> wrote: >>>>=20 >>>>> On 2/11/15 7:16 PM, Peter Saint-Andre - &yet wrote: >>>>>> On 2/9/15 4:27 PM, Ben Campbell wrote: >>>>>> (No hats) >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> (I apologize that these comments are late in the process. >>>>>> Please feel free to defer them to last call.) >>>>>>=20 >>>>>> This version mostly looks good, but there are a few minor >>>>>> issues: >>>>>>=20 >>>>>> -- Message Size >>>>>>=20 >>>>>> It might be worth a discussion on message size limits (e.g. the >>>>>> SIP MESSAGE method limits the size to 1300 octets except under >>>>>> some pretty narrow circumstances.) >>>>>=20 >>>>> Thank you for pointing this out. I had glossed over it in my >>>>> reading of RFC 3428. I think it deserves a section of its own in >>>>> the -im document. >>>>=20 >>>> I propose the following text: >>>>=20 >>>> [RFC3428] specifies that (outside of a media session) the size of >>>> a MESSAGE request is not allowed to exceed 1300 bytes. Although >>>> in practice XMPP instant messages do not often exceed that size, >>>> neither [RFC6120] nor [RFC6121] sets an upper limit on the size of >>>> XMPP stanzas. However, XMPP server deployments usually do limit >>>> the size of stanzas in order to help prevent denial of service >>>> attacks, and [RFC6120] states that if a server sets a maximum >>>> stanza size then the limit is not allowed to be less than 10,000 >>>> bytes. Because of this mismatch, an XMPP-to-SIP gateway MUST >>>> return a stanza error if an XMPP user attempts >>>> to send an XMPP message stanza that would result in a SIP MESSAGE >>>> greater than 1300 bytes. >>>=20 >>> That just stepped in a bit of discomfort on my part, in that I'm not >>> sure how a gateway that happened to support both stox-im and >>> stox-chat decides which to invoke. I'm mostly willing to ignore that >>> particular elephant, but would it be reasonable for an implementation >>> to decide that larger messages would get promoted to MSRP (assuming >>> support at the other end)? If so, the MUST return a >>> seems to forbid it. >>=20 >> We've been treating -im (page mode) and -chat (session mode) as entirely >> separate things. However, you're right that "upgrading" from page mode >> (SIP MESSAGE) to session mode (MSRP) might make sense in some >> situations. Without hearing in detail from those who've implemented such >> systems, I would be hesitant to specify guidelines for when such an >> upgrade makes sense. Thus I'd be most comfortable with a SHOULD here and >> leaving the upgrade logic up to implementations. >=20 > Proposed text: >=20 > ### >=20 > 6. Message Size >=20 > [RFC3428] specifies that (outside of a media session) the size of a > MESSAGE request is not allowed to exceed 1300 bytes. Although in > practice XMPP instant messages do not often exceed that size, neither > [RFC6120] nor [RFC6121] sets an upper limit on the size of XMPP > stanzas. However, XMPP server deployments usually do limit the size > of stanzas in order to help prevent denial of service attacks, and > [RFC6120] states that if a server sets a maximum stanza size then the > limit is not allowed to be less than 10,000 bytes. Because of this > mismatch, an XMPP-to-SIP gateway SHOULD return a > stanza error if an XMPP user attempts to send an XMPP message stanza > that would result in a SIP MESSAGE greater than 1300 bytes. Although > such a gateway might decide to "upgrade" from page mode to session > mode using the Message Session Relay Protocol (MSRP) and thus > treating the instant message as part of a chat session as described > in [I-D.ietf-stox-chat], such behavior is application-specific and > this document provides no guidelines for how to complete such an > upgrade. >=20 > ### >=20 WFM Thanks! Ben. >=20 From nobody Thu Feb 12 19:18:07 2015 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 C8CC61A1ACC for ; Thu, 12 Feb 2015 19:18:04 -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 fmphXyvERwRz for ; Thu, 12 Feb 2015 19:18:02 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B193C1A1ABB for ; Thu, 12 Feb 2015 19:17:33 -0800 (PST) Received: by iecrp18 with SMTP id rp18so1429780iec.9 for ; Thu, 12 Feb 2015 19:17:33 -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=eGVzQbTjuWCWVfktMkWffUVcjxDvU2Mnf9hDgnaAlMY=; b=dFboklZ5LqGCPxBf07MpnKW+JKIYmoEWpyS7RyWwEOq7AmTn4kVZszKjGNZEJrGhZs Qu5ZyvjbZU1XvzFPbPbMqbAD+7PEXPzqhvMNmSmTwS/3giTGBojXAuky4xgYkw3QHnst Uca6RybRUkEL36BKnBaydDsCdeCIYayyyKzaBtAa/g/ZXYIK72DAIe7Z04PWtiiWgbv3 8hm1ifOcR8WQW6rjCVz5WNPCAn+nFENtweKRTzifbLE/tPd5hMi4YZTpJTBzTE6lA9lw XrJ7hrUb7/VjS3fxSLO2l0g1GwyNd2AN595VVb662ImSgdLdaB2BUkt46MwyVwMDiJ3c XoOw== X-Gm-Message-State: ALoCoQmOEmY10U0JAGMqa7XlWRiQhOj6gCo+5jNC0n6fylnzc6QorLmY+hCpqSRwHxeC2ceZxIYC X-Received: by 10.42.110.14 with SMTP id n14mr12566088icp.21.1423797453028; Thu, 12 Feb 2015 19:17:33 -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 g4sm3698196ioe.19.2015.02.12.19.17.31 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 19:17:32 -0800 (PST) Message-ID: <54DD6CCA.2020605@andyet.net> Date: Thu, 12 Feb 2015 20:17:30 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 03:18:05 -0000 On 2/12/15 7:58 PM, Ben Campbell wrote: > >> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet >> wrote: >> >>> On 2/11/15 8:07 PM, Ben Campbell wrote: >>> >>> (While I'm still standing in it--what happens in stox-chat if >>> the MSRP side sends a message larger than the largest allowed? >>> Apologies if the draft talks about that--I don't have it in front >>> of me.) >> >> That's messy. :/ >> >> Ideally we'd be talking about unchunked MSRP messages. > > Yes, or a message reassembled from chunks by the gateway. Ah, true. That might give us a way out. >> In RFC 3921/6121 we don't have the concept of chunking afor regular >> chat messages, and the only chunking method we have in XMPP is not >> used for chat messages but for file transfer (XEP-0047). For chat >> purposes, a typical XMPP client won't have the necessary >> application logic to handle chunked messages ... > > Right, that would be the gateway's problem. I had assumed that the > since the gateway is for all practical purposes the MSRP endpoint, it > would reassemble any chunks before sending toward the XMPP side. Right. >> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a >> message. > > Hmm, you've lost me here. That's because I was thinking out loud. :-) > Do you mean the gateway can't assume it's > okay to chunk towards the XMPP client (which makes sense) or towards > the MSRP client? Towards the XMPP client. But as you say that's not necessary. >> However, I don't see a way in RFC 4975 for an entity such as a >> gateway to advertise that it doesn't support chunking. > > There's not a way, because the assumption has always been that any > MSRP endpoint can at least receive chunked messages. > >> Although in theory the max-size a-line could help, that applies to >> full messages before chunking. I also don't see a way in RFC 4975 >> to reject a particular MSRP SEND because it's too big. > > You can sort of do this with 413. But I think it's the whole message > size that is important here, not the size of a particular SEND > request. Yes. Let me propose some text. Stay tuned... Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 12 19:30:59 2015 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 9693D1A00FC for ; Thu, 12 Feb 2015 19:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 odnQSuACdkss for ; Thu, 12 Feb 2015 19:30:56 -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 1E5FF1A00EC for ; Thu, 12 Feb 2015 19:30:55 -0800 (PST) Received: from [10.9.94.181] (mobile-166-173-058-122.mycingular.net [166.173.58.122]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1D3Uiwg060967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2015 21:30:46 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-122.mycingular.net [166.173.58.122] claimed to be [10.9.94.181] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54DD6CCA.2020605@andyet.net> Date: Thu, 12 Feb 2015 21:30:39 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> <54DD6CCA.2020605@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 03:30:58 -0000 > On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet w= rote: >=20 >> On 2/12/15 7:58 PM, Ben Campbell wrote: >>=20 >>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet >>> wrote: >>>=20 >>>> On 2/11/15 8:07 PM, Ben Campbell wrote: >>>>=20 >>>> (While I'm still standing in it--what happens in stox-chat if >>>> the MSRP side sends a message larger than the largest allowed? >>>> Apologies if the draft talks about that--I don't have it in front >>>> of me.) >>>=20 >>> That's messy. :/ >>>=20 >>> Ideally we'd be talking about unchunked MSRP messages. >>=20 >> Yes, or a message reassembled from chunks by the gateway. >=20 > Ah, true. That might give us a way out. >=20 >>> In RFC 3921/6121 we don't have the concept of chunking afor regular >>> chat messages, and the only chunking method we have in XMPP is not >>> used for chat messages but for file transfer (XEP-0047). For chat >>> purposes, a typical XMPP client won't have the necessary >>> application logic to handle chunked messages ... >>=20 >> Right, that would be the gateway's problem. I had assumed that the >> since the gateway is for all practical purposes the MSRP endpoint, it >> would reassemble any chunks before sending toward the XMPP side. >=20 > Right. >=20 >>> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a >>> message. >>=20 >> Hmm, you've lost me here. >=20 > That's because I was thinking out loud. :-) >=20 >> Do you mean the gateway can't assume it's >> okay to chunk towards the XMPP client (which makes sense) or towards >> the MSRP client? >=20 > Towards the XMPP client. But as you say that's not necessary. >=20 >>> However, I don't see a way in RFC 4975 for an entity such as a >>> gateway to advertise that it doesn't support chunking. >>=20 >> There's not a way, because the assumption has always been that any >> MSRP endpoint can at least receive chunked messages. >>=20 >>> Although in theory the max-size a-line could help, that applies to >>> full messages before chunking. I also don't see a way in RFC 4975 >>> to reject a particular MSRP SEND because it's too big. >>=20 >> You can sort of do this with 413. But I think it's the whole message >> size that is important here, not the size of a particular SEND >> request. >=20 > Yes. >=20 > Let me propose some text. Stay tuned... This seems like the right track, although it's worth considering how much bu= ffering a gateway might be willing to do, and think about memory depletion a= ttacks. This is mentioned in 4975, so it may already be covered well enough.= >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Thu Feb 12 19:57:36 2015 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 D77F91A1AEA for ; Thu, 12 Feb 2015 19:57:33 -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 jOJ6WSVu9nPz for ; Thu, 12 Feb 2015 19:57:31 -0800 (PST) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 869281A1B3A for ; Thu, 12 Feb 2015 19:57:29 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id h15so8247573igd.4 for ; Thu, 12 Feb 2015 19:57:28 -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=ilNwFDllIztdjmIQPkn/3X1sUd8WuImgM+A1ZCfSlMs=; b=Udi8AKcNp8K+3iUqYtOybKFamY95dgISskBiP8e6HP0jutlh6c2vdn+bViVQCAcgG6 JxBQzy7q2mJ0nP81VTt0dfwi0qr6HzB+6zjggUp7EF1MWAeWcRtxXuOGV7DR6yvMYN80 En95xPPysfMsEYuEXWtm1iXf8nS8aHrlcbLuvVuigQKobbhaSawv7RZBU6gPGYqbOtTB zm6zCyJP2r6pMN9MQMP0E8E3CjBM2ZgqtYY37AJBzyNxuiTM0rucQd/Oof/d+RDrIlJF uq/d6WC1YUj1dzvC2DuTDnlGSYaZqU+lEQN3OMuGfnx1VdN1y3v/REv74UH4JLnKmcG8 0DYg== X-Gm-Message-State: ALoCoQniZc6ob+KjRC9bbnkujVN1FdXfulSpwTPscVunTWb/TrKNNl14GlZUk4JFU6tlKTkdaYGq X-Received: by 10.50.136.228 with SMTP id qd4mr1157715igb.13.1423799848862; Thu, 12 Feb 2015 19:57:28 -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 d1sm2526907igr.20.2015.02.12.19.57.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Feb 2015 19:57:28 -0800 (PST) Message-ID: <54DD7626.40704@andyet.net> Date: Thu, 12 Feb 2015 20:57:26 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> <54DD6CCA.2020605@andyet.net> <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> In-Reply-To: <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 03:57:34 -0000 On 2/12/15 8:30 PM, Ben Campbell wrote: > > > >> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet wrote: >> >>> On 2/12/15 7:58 PM, Ben Campbell wrote: >>> >>>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet >>>> wrote: >>>> >>>>> On 2/11/15 8:07 PM, Ben Campbell wrote: >>>>> >>>>> (While I'm still standing in it--what happens in stox-chat if >>>>> the MSRP side sends a message larger than the largest allowed? >>>>> Apologies if the draft talks about that--I don't have it in front >>>>> of me.) >>>> >>>> That's messy. :/ >>>> >>>> Ideally we'd be talking about unchunked MSRP messages. >>> >>> Yes, or a message reassembled from chunks by the gateway. >> >> Ah, true. That might give us a way out. >> >>>> In RFC 3921/6121 we don't have the concept of chunking afor regular >>>> chat messages, and the only chunking method we have in XMPP is not >>>> used for chat messages but for file transfer (XEP-0047). For chat >>>> purposes, a typical XMPP client won't have the necessary >>>> application logic to handle chunked messages ... >>> >>> Right, that would be the gateway's problem. I had assumed that the >>> since the gateway is for all practical purposes the MSRP endpoint, it >>> would reassemble any chunks before sending toward the XMPP side. >> >> Right. >> >>>> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a >>>> message. >>> >>> Hmm, you've lost me here. >> >> That's because I was thinking out loud. :-) >> >>> Do you mean the gateway can't assume it's >>> okay to chunk towards the XMPP client (which makes sense) or towards >>> the MSRP client? >> >> Towards the XMPP client. But as you say that's not necessary. >> >>>> However, I don't see a way in RFC 4975 for an entity such as a >>>> gateway to advertise that it doesn't support chunking. >>> >>> There's not a way, because the assumption has always been that any >>> MSRP endpoint can at least receive chunked messages. >>> >>>> Although in theory the max-size a-line could help, that applies to >>>> full messages before chunking. I also don't see a way in RFC 4975 >>>> to reject a particular MSRP SEND because it's too big. >>> >>> You can sort of do this with 413. But I think it's the whole message >>> size that is important here, not the size of a particular SEND >>> request. >> >> Yes. >> >> Let me propose some text. Stay tuned... > > This seems like the right track, although it's worth considering how much buffering a gateway might be willing to do, and think about memory depletion attacks. This is mentioned in 4975, so it may already be covered well enough. True. Proposed text for a new section in stox-chat... ### 8. Message Size Unlike page-mode messaging [RFC3428] (which specifies that the size of a MESSAGE request is not allowed to exceed 1300 bytes), session- mode messaging [RFC4975] can be used to send larger messages. MSRP includes a chunking mechanism such that larger messages can be broken up into multiple MSRP SEND requests. Because the MSRP gateway at an XMPP service acts as an MSRP endpoint, it is responsible for receiving chunked messages and reconstructing them into a single message for delivery toward the XMPP recipient. (Naturally, implementations need to be careful about accepting very large messages; see Section 14.5 of [RFC4975].) Although there is no hard limit on the size of an XMPP stanza, in practice most XMPP services (at least on the public Internet) are configured with a maximum stanza size in order to help prevent denial of service attacks. As specified in Section 13.12 of [RFC6120], this maximum is not allowed to be less than 10,000 bytes. The administrators of an XMPP service need to ensure the associated MSRP gateway is configured with the same or smaller maximum MSRP message size as the maximum XMPP stanza size; this enables the gateway to return an appropriate value for the SDP "max-size" attribute and to properly handle messages larger than the configured limits. If an MSRP-to-XMPP gateway implementation receives an MSRP message that exceeds its configured limit as just described, it MUST return an MSRP 413 error (e.g., in response to the first SEND request whose Byte-Range header field indicates a byte total exceeding the limit). ### From nobody Fri Feb 13 08:21:49 2015 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 9558D1A8740 for ; Fri, 13 Feb 2015 08:21:45 -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 oZ_6RQCkENH5 for ; Fri, 13 Feb 2015 08:21:42 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8258D1A8777 for ; Fri, 13 Feb 2015 08:21:22 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so11503106iga.5 for ; Fri, 13 Feb 2015 08:21:22 -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=f+AhX5mgB0CIuHdH729NkveJheISN0OhhlCe7l18BBc=; b=VhkHjF+DylP4qwmtjEwJBZ/Jc/QXI0f6giqj7uSlko4pgCjOZkXNtn2WTDiS+QSw0O 3BqcN8CNcttx9uoOvhgN6Bv87UDg0k8PGNT3PQRTJW7fu9G8l6YbUWsNHiifM6DXOrQ9 +4uuBLKepRQ32uRk1TqayO8X2BNS4d1x5FgwKajuP3GH1IPHNeyNsTDLPRDBhft+Za9Y Jvtf8a8dEBL1lM7gHp1BiiNWQbcN0AEGXipguV7s5xoU3PdkANu5kd8vM5jT4fDH5MJm kBe1H4/uz+F4a4hqSAzJpVdNi6cF6DhfPJef+FHspsFFKwX9ZsHObhwg+QXBpxVib0Kq vrkg== X-Gm-Message-State: ALoCoQnPXFGmf2goSIE4GFisnZDDCmgs3t11kbotnzoPoHLod1zHOTMvGYQi0DhxFJvap4Nov1BZ X-Received: by 10.50.32.71 with SMTP id g7mr4786380igi.4.1423844481829; Fri, 13 Feb 2015 08:21:21 -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 n4sm3470444igr.15.2015.02.13.08.21.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 08:21:21 -0800 (PST) Message-ID: <54DE2480.7060501@andyet.net> Date: Fri, 13 Feb 2015 09:21:20 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ben Campbell References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> <54DD6CCA.2020605@andyet.net> <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> <54DD7626.40704@andyet.net> In-Reply-To: <54DD7626.40704@andyet.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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: Fri, 13 Feb 2015 16:21:45 -0000 On 2/12/15 8:57 PM, Peter Saint-Andre - &yet wrote: > On 2/12/15 8:30 PM, Ben Campbell wrote: >> >> >> >>> On Feb 12, 2015, at 9:17 PM, Peter Saint-Andre - &yet >>> wrote: >>> >>>> On 2/12/15 7:58 PM, Ben Campbell wrote: >>>> >>>>> On Feb 12, 2015, at 4:28 PM, Peter Saint-Andre - &yet >>>>> wrote: >>>>> >>>>>> On 2/11/15 8:07 PM, Ben Campbell wrote: >>>>>> >>>>>> (While I'm still standing in it--what happens in stox-chat if >>>>>> the MSRP side sends a message larger than the largest allowed? >>>>>> Apologies if the draft talks about that--I don't have it in front >>>>>> of me.) >>>>> >>>>> That's messy. :/ >>>>> >>>>> Ideally we'd be talking about unchunked MSRP messages. >>>> >>>> Yes, or a message reassembled from chunks by the gateway. >>> >>> Ah, true. That might give us a way out. >>> >>>>> In RFC 3921/6121 we don't have the concept of chunking afor regular >>>>> chat messages, and the only chunking method we have in XMPP is not >>>>> used for chat messages but for file transfer (XEP-0047). For chat >>>>> purposes, a typical XMPP client won't have the necessary >>>>> application logic to handle chunked messages ... >>>> >>>> Right, that would be the gateway's problem. I had assumed that the >>>> since the gateway is for all practical purposes the MSRP endpoint, it >>>> would reassemble any chunks before sending toward the XMPP side. >>> >>> Right. >>> >>>>> and an MSRP-to-XMPP gateway can't assume that it's OK to chunk a >>>>> message. >>>> >>>> Hmm, you've lost me here. >>> >>> That's because I was thinking out loud. :-) >>> >>>> Do you mean the gateway can't assume it's >>>> okay to chunk towards the XMPP client (which makes sense) or towards >>>> the MSRP client? >>> >>> Towards the XMPP client. But as you say that's not necessary. >>> >>>>> However, I don't see a way in RFC 4975 for an entity such as a >>>>> gateway to advertise that it doesn't support chunking. >>>> >>>> There's not a way, because the assumption has always been that any >>>> MSRP endpoint can at least receive chunked messages. >>>> >>>>> Although in theory the max-size a-line could help, that applies to >>>>> full messages before chunking. I also don't see a way in RFC 4975 >>>>> to reject a particular MSRP SEND because it's too big. >>>> >>>> You can sort of do this with 413. But I think it's the whole message >>>> size that is important here, not the size of a particular SEND >>>> request. >>> >>> Yes. >>> >>> Let me propose some text. Stay tuned... >> >> This seems like the right track, although it's worth considering how >> much buffering a gateway might be willing to do, and think about >> memory depletion attacks. This is mentioned in 4975, so it may already >> be covered well enough. > > True. > > Proposed text for a new section in stox-chat... > > ### > > 8. Message Size > > Unlike page-mode messaging [RFC3428] (which specifies that the size > of a MESSAGE request is not allowed to exceed 1300 bytes), session- > mode messaging [RFC4975] can be used to send larger messages. MSRP > includes a chunking mechanism such that larger messages can be broken > up into multiple MSRP SEND requests. Because the MSRP gateway at an > XMPP service acts as an MSRP endpoint, it is responsible for > receiving chunked messages and reconstructing them into a single > message for delivery toward the XMPP recipient. (Naturally, > implementations need to be careful about accepting very large > messages; see Section 14.5 of [RFC4975].) > > Although there is no hard limit on the size of an XMPP stanza, in > practice most XMPP services (at least on the public Internet) are > configured with a maximum stanza size in order to help prevent denial > of service attacks. As specified in Section 13.12 of [RFC6120], this > maximum is not allowed to be less than 10,000 bytes. > > The administrators of an XMPP service need to ensure the associated > MSRP gateway is configured with the same or smaller maximum MSRP > message size as the maximum XMPP stanza size; this enables the > gateway to return an appropriate value for the SDP "max-size" > attribute and to properly handle messages larger than the configured > limits. > > If an MSRP-to-XMPP gateway implementation receives an MSRP message > that exceeds its configured limit as just described, it MUST return > an MSRP 413 error (e.g., in response to the first SEND request whose > Byte-Range header field indicates a byte total exceeding the limit). > > ### Ben, let me know if that text looks OK. It seems that we'll want to add a pointer from the -groupchat document to this section, too, eh? I think this is the last open issue from your reviews, so once you say it's OK I'll submit revised I-Ds for -im, -chat, and -groupchat. Thanks! Peter -- Peter Saint-Andre https://andyet.com/ From nobody Fri Feb 13 15:06:43 2015 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 722E21A008A for ; Fri, 13 Feb 2015 15:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 tMt76BZob43L for ; Fri, 13 Feb 2015 15:06:30 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C5E1A036D for ; Fri, 13 Feb 2015 15:06:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 270602082B for ; Fri, 13 Feb 2015 18:06:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute6.internal (MEProxy); Fri, 13 Feb 2015 18:06:17 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=7wM07I555VmTwH3kUBHK+SoCQ1U=; b=cgxtHr8y2ybUCVbm5gW77 5DoYjCzG6rXRalAkb9zJIsWa0Aj4qU0uuPKrh96BlfnGdXi8ikRLGrhCzx0kUMlg xOn2OWu0d2937Yud0OOt8M75LujsH45YQHHDdgx87IuK53Pl1ypMNAPVuO0Q5fc4 MraPImg8AaNMMtLBBoQ2jU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=7wM07I555VmTwH3kUBHK+So CQ1U=; b=YN+IoXJ8KmFZ20p+zFtHq7h23X918NV24D9awwCz/1WqGay9JySu8TB N/821jUbbssp9o3DFHhU+VUpxDBy7V17eReKv42OvJR8mtJsVWdAqN804v6riu1o yE5UaeVxiWAv8++HD+oO5YUl4j+v0vgwh74Z26uYFdYOcMZ3gW0Y= X-Sasl-enc: McueCiLIM2Ahf5zmVQgpeiJYthpOcVGp4TUykyCsn+rv 1423868777 Received: from dhcp-171-68-20-114.cisco.com (unknown [171.68.20.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F1656801F6; Fri, 13 Feb 2015 18:06:16 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54DC1A52.8070401@andyet.net> Date: Fri, 13 Feb 2015 15:06:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3EDB02F9-7BB8-46D8-A58B-43F8C76DF22F@cooperw.in> References: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in> <54CFA75F.2040605@andyet.net> <31B110BC-C8B0-48B0-BD24-2F7F7DCA1ED6@cooperw.in> <54DC16B3.2020205@andyet.net> <54DC1A52.8070401@andyet.net> To: Peter Saint-Andre - &yet X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: stox@ietf.org Subject: Re: [Stox] AD evaluation: draft-ietf-stox-chat-08 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: Fri, 13 Feb 2015 23:06:39 -0000 On Feb 11, 2015, at 7:13 PM, Peter Saint-Andre - &yet = wrote: > On 2/11/15 7:57 PM, Peter Saint-Andre - &yet wrote: >> On 2/9/15 4:44 PM, Alissa Cooper wrote: >>> On Feb 2, 2015, at 8:35 AM, Peter Saint-Andre - &yet >>> wrote: >>>=20 >>>> On 1/31/15 5:09 PM, Alissa Cooper wrote: >>>>=20 >>>>> =3D Section 7 =3D Is all of the delivery report behavior meant to = be >>>>> entirely optional to support, or should there be some normative >>>>> requirements listed in this section? >>>>=20 >>>> IMHO this is entirely optional (as with Section 6). >>>=20 >>> I think the difference between Section 6 and Section 7 is that = Section >>> 6 at least gives a little narrative description of how to do the >>> mapping for composing notifications, whereas in Section 7 there is = no >>> such description, it=92s just illustrated by examples. So I would >>> suggest adding a sentence or two that generically describes what the >>> gateway in each direction should do to map an MSRP REPORT to an XMPP >>> message receipt request/response and vice versa. This is obviously a >>> small thing but seems like good practice. This can be dealt with >>> during IETF LC. >>=20 >> Yes, I see your point. Will add. >=20 > Here is proposed text. >=20 > ### >=20 > An XMPP Message Receipts element of xmlns=3D'urn:xmpp:receipts'/> is to be mapped to an MSRP = Success-Report > header field with a value of "yes", and an XMPP Message Receipts > element of is to be mapped = to > an MSRP REPORT request. >=20 > A Success-Report header field with a value of "yes" in an MSRP SEND > request is to be mapped to an XMPP Message Receipts element of > , and an MSRP REPORT request = is > to be mapped to an XMPP message containing only a Message Receipts > element of . >=20 > There are no other suggested mappings (e.g., for the MSRP Failure- > Report header field). >=20 > ### Thanks, this looks good. Alissa >=20 > Peter >=20 > --=20 > Peter Saint-Andre > https://andyet.com/ From nobody Fri Feb 13 19:21:06 2015 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 6E2A31A1A1E; Fri, 13 Feb 2015 19:21:03 -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 TGbCfUdX0nuO; Fri, 13 Feb 2015 19:21:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FA11A0173; Fri, 13 Feb 2015 19:21:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032101.17212.17617.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:02 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-im-12.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, 14 Feb 2015 03:21:03 -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): Instant Messaging Authors : Peter Saint-Andre Avshalom Houri Joe Hildebrand Filename : draft-ietf-stox-im-12.txt Pages : 12 Date : 2015-02-13 Abstract: This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-im-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-12 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 Feb 13 19:21:13 2015 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 03D3C1A0371; Fri, 13 Feb 2015 19:21:05 -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 XLvjXLLgRZ1Y; Fri, 13 Feb 2015 19:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA61A03A0; Fri, 13 Feb 2015 19:21:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032102.17212.26734.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:02 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-im-12.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, 14 Feb 2015 03:21:05 -0000 A new version (-12) has been submitted for draft-ietf-stox-im: http://www.ietf.org/internet-drafts/draft-ietf-stox-im-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-12 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. IETF Secretariat. From nobody Fri Feb 13 19:21:14 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6DD901A0371; Fri, 13 Feb 2015 19:21:05 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D3C1A0371; Fri, 13 Feb 2015 19:21:05 -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 XLvjXLLgRZ1Y; Fri, 13 Feb 2015 19:21:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AA61A03A0; Fri, 13 Feb 2015 19:21:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032102.17212.26734.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:02 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-im-12.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, 14 Feb 2015 03:21:05 -0000 A new version (-12) has been submitted for draft-ietf-stox-im: http://www.ietf.org/internet-drafts/draft-ietf-stox-im-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-im/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-im-12 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. IETF Secretariat. From nobody Fri Feb 13 19:21:18 2015 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 15D571A1AB0; Fri, 13 Feb 2015 19:21:16 -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 o-XJ7Jvx93os; Fri, 13 Feb 2015 19:21:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C761A1A03A0; Fri, 13 Feb 2015 19:21:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032113.30812.64059.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:13 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-chat-10.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, 14 Feb 2015 03:21:16 -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): One-to-One Text Chat Sessions Authors : Peter Saint-Andre Salvatore Loreto Filename : draft-ietf-stox-chat-10.txt Pages : 19 Date : 2015-02-13 Abstract: This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-stox-chat-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-10 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 Feb 13 19:21:22 2015 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 045D21A1AB1; Fri, 13 Feb 2015 19:21:18 -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 H-HIWUxR0qXk; Fri, 13 Feb 2015 19:21:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38F1A1A99; Fri, 13 Feb 2015 19:21:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032114.30812.96396.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:14 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-chat-10.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, 14 Feb 2015 03:21:18 -0000 A new version (-10) has been submitted for draft-ietf-stox-chat: http://www.ietf.org/internet-drafts/draft-ietf-stox-chat-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-10 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. IETF Secretariat. From nobody Fri Feb 13 19:21:23 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 602371A1A99; Fri, 13 Feb 2015 19:21:18 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045D21A1AB1; Fri, 13 Feb 2015 19:21:18 -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 H-HIWUxR0qXk; Fri, 13 Feb 2015 19:21:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38F1A1A99; Fri, 13 Feb 2015 19:21:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032114.30812.96396.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:14 -0800 Archived-At: Subject: [Stox] New Version Notification - draft-ietf-stox-chat-10.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, 14 Feb 2015 03:21:18 -0000 A new version (-10) has been submitted for draft-ietf-stox-chat: http://www.ietf.org/internet-drafts/draft-ietf-stox-chat-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-stox-chat/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-chat-10 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. IETF Secretariat. From nobody Fri Feb 13 19:21:38 2015 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 A6CB01A1AAF; Fri, 13 Feb 2015 19:21:27 -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 IAydpr0xjPJK; Fri, 13 Feb 2015 19:21:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6DD1A0404; Fri, 13 Feb 2015 19:21:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150214032125.27576.26657.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 19:21:25 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-10.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, 14 Feb 2015 03:21:27 -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-10.txt Pages : 41 Date : 2015-02-13 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-10 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 Feb 13 19:26:23 2015 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 38AE51A0173 for ; Fri, 13 Feb 2015 19:26:21 -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 qOllOh8uqSrT for ; Fri, 13 Feb 2015 19:26:19 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C756C1A0A85 for ; Fri, 13 Feb 2015 19:26:19 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id l13so14379987iga.5 for ; Fri, 13 Feb 2015 19:26:19 -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:content-type:content-transfer-encoding; bh=hdjkfrAMX1YiMJkA4CQYqhUo/qhPWhPjulsnB7diEJA=; b=ErC2G1VQ9+4NUja1tyP9htH69FcvNkMi/YA7GDt+EezRLaQjafvoWcr6sEOO/fTNcq 5AtZ8IT+7FZaDL30WgCbmHS+9AlB6+A18H6DHt9O3jouId4Heuz/US6Z4I5sxpCEGP53 0tRzbdjRA+0F/BBRXb1Q63zQTYkFYfMEhi6ZlZ5vM8kfrirNPTvTkmgxjXrmn4SEtY0M gMhuzhxwh5WeZ/iktci+uEkx1jvRnxPRYRcyu/ROUW9uSkFgwHCIGw0MU4eRKuWeNgU0 LYrBgW2e8N9DZ+8I5t3oV9uUnOjpof7FNK4dTjgCOaEQy6cGkPqqlR4KM+h1yagU3t/r myrA== X-Gm-Message-State: ALoCoQl48IuINLn3I+rgnq15Pnvwaxc9OVa7oq1JNCszpHPZpKCWi4mSru6YLX+z+wTeO1i8e84f X-Received: by 10.50.143.106 with SMTP id sd10mr7964736igb.17.1423884379206; Fri, 13 Feb 2015 19:26:19 -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 yq1sm4390124igb.21.2015.02.13.19.26.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Feb 2015 19:26:18 -0800 (PST) Message-ID: <54DEC059.4040303@andyet.net> Date: Fri, 13 Feb 2015 20:26:17 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "stox@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Stox] updated I-Ds 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, 14 Feb 2015 03:26:21 -0000 I just submitted -im-12, -chat-10, and -groupchat-10 to address feedback from Ben Campbell and Alissa Cooper. I think these are ready for IETF Last Call now. Enjoy! :-) Peter From nobody Fri Feb 13 20:52:09 2015 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 55CCE1A0210 for ; Fri, 13 Feb 2015 20:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Eu7mQwI2lg_r for ; Fri, 13 Feb 2015 20:51:56 -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 DB8061A0252 for ; Fri, 13 Feb 2015 20:51:56 -0800 (PST) Received: from [172.16.4.239] (75-146-141-17-NewMexico.hfc.comcastbusiness.net [75.146.141.17]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t1E4phc1085069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 22:51:45 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 75-146-141-17-NewMexico.hfc.comcastbusiness.net [75.146.141.17] claimed to be [172.16.4.239] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Campbell X-Mailer: iPad Mail (12B466) In-Reply-To: <54DE2480.7060501@andyet.net> Date: Fri, 13 Feb 2015 21:51:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54DC0CE3.8090405@andyet.net> <54DC1441.2090305@andyet.net> <54DD28F4.7070200@andyet.net> <54DD6CCA.2020605@andyet.net> <5228A173-7B2F-49BA-AA38-F63B70B8DD39@nostrum.com> <54DD7626.40704@andyet.net> <54DE2480.7060501@andyet.net> To: Peter Saint-Andre - &yet Archived-At: Cc: "stox@ietf.org" , Alissa Cooper , "draft-ietf-stox-im.all@tools.ietf.org" Subject: Re: [Stox] Comments on draft-ietf-stox-im-11 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, 14 Feb 2015 04:52:01 -0000 On Feb 13, 2015, at 9:21 AM, Peter Saint-Andre - &yet wro= te: >> Proposed text for a new section in stox-chat... >>=20 >> ### >>=20 >> 8. Message Size >>=20 >> Unlike page-mode messaging [RFC3428] (which specifies that the size >> of a MESSAGE request is not allowed to exceed 1300 bytes), session- >> mode messaging [RFC4975] can be used to send larger messages. MSRP >> includes a chunking mechanism such that larger messages can be broken >> up into multiple MSRP SEND requests. Because the MSRP gateway at an >> XMPP service acts as an MSRP endpoint, it is responsible for >> receiving chunked messages and reconstructing them into a single >> message for delivery toward the XMPP recipient. (Naturally, >> implementations need to be careful about accepting very large >> messages; see Section 14.5 of [RFC4975].) >>=20 >> Although there is no hard limit on the size of an XMPP stanza, in >> practice most XMPP services (at least on the public Internet) are >> configured with a maximum stanza size in order to help prevent denial >> of service attacks. As specified in Section 13.12 of [RFC6120], this >> maximum is not allowed to be less than 10,000 bytes. >>=20 >> The administrators of an XMPP service need to ensure the associated >> MSRP gateway is configured with the same or smaller maximum MSRP >> message size as the maximum XMPP stanza size; this enables the >> gateway to return an appropriate value for the SDP "max-size" >> attribute and to properly handle messages larger than the configured >> limits. >>=20 >> If an MSRP-to-XMPP gateway implementation receives an MSRP message >> that exceeds its configured limit as just described, it MUST return >> an MSRP 413 error (e.g., in response to the first SEND request whose >> Byte-Range header field indicates a byte total exceeding the limit). >>=20 >> ### >=20 > Ben, let me know if that text looks OK. It seems that we'll want to add a p= ointer from the -groupchat document to this section, too, eh? Yes, and probably.=20 >=20 > I think this is the last open issue from your reviews, so once you say it'= s OK I'll submit revised I-Ds for -im, -chat, and -groupchat. Agreed.= From nobody Sun Feb 15 07:25:03 2015 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 45F5B1A7002; Sun, 15 Feb 2015 07:25:01 -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 3Ezd5F1QE27A; Sun, 15 Feb 2015 07:24:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0C1A1BC6; Sun, 15 Feb 2015 07:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152459.13589.36970.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:24:59 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Sun, 15 Feb 2015 15:25:01 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Sun Feb 15 07:25:05 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9AAF91A7005; Sun, 15 Feb 2015 07:25:01 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F5B1A7002; Sun, 15 Feb 2015 07:25:01 -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 3Ezd5F1QE27A; Sun, 15 Feb 2015 07:24:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B0C1A1BC6; Sun, 15 Feb 2015 07:24:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152459.13589.36970.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:24:59 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Sun, 15 Feb 2015 15:25:01 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Sun Feb 15 07:25:54 2015 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 D12411A6FFF; Sun, 15 Feb 2015 07:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 4387C_1rY_3W; Sun, 15 Feb 2015 07:25:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 883791A1BC6; Sun, 15 Feb 2015 07:25:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152551.14126.60837.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:25:51 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] Telechat update notice: 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: Sun, 15 Feb 2015 15:25:53 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Sun Feb 15 07:26:00 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 348461A7003; Sun, 15 Feb 2015 07:25:53 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12411A6FFF; Sun, 15 Feb 2015 07:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 4387C_1rY_3W; Sun, 15 Feb 2015 07:25:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 883791A1BC6; Sun, 15 Feb 2015 07:25:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152551.14126.60837.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:25:51 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] Telechat update notice: 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: Sun, 15 Feb 2015 15:25:53 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Sun Feb 15 07:26:29 2015 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 8EE101A7004; Sun, 15 Feb 2015 07:26:27 -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 8Vlpuljkqcyw; Sun, 15 Feb 2015 07:26:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7D1A7001; Sun, 15 Feb 2015 07:26:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152626.11362.85449.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:26:26 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Sun, 15 Feb 2015 15:26:27 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Sun Feb 15 07:26:30 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DC60C1A700B; Sun, 15 Feb 2015 07:26:27 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE101A7004; Sun, 15 Feb 2015 07:26:27 -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 8Vlpuljkqcyw; Sun, 15 Feb 2015 07:26:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A7D1A7001; Sun, 15 Feb 2015 07:26:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152626.11362.85449.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:26:26 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Sun, 15 Feb 2015 15:26:28 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Sun Feb 15 07:27:02 2015 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 A4BAC1A7005; Sun, 15 Feb 2015 07:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 vhrzEcW1cXef; Sun, 15 Feb 2015 07:26:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDB31A7003; Sun, 15 Feb 2015 07:26:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152656.6889.73191.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:26:56 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] Telechat update notice: 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: Sun, 15 Feb 2015 15:26:58 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Sun Feb 15 07:27:04 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E2C121A700B; Sun, 15 Feb 2015 07:26:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BAC1A7005; Sun, 15 Feb 2015 07:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 vhrzEcW1cXef; Sun, 15 Feb 2015 07:26:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDB31A7003; Sun, 15 Feb 2015 07:26:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150215152656.6889.73191.idtracker@ietfa.amsl.com> Date: Sun, 15 Feb 2015 07:26:56 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] Telechat update notice: 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: Sun, 15 Feb 2015 15:26:59 -0000 Placed on agenda for telechat - 2015-03-05 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Mon Feb 16 06:29:29 2015 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 24C2D1A889A; Mon, 16 Feb 2015 06:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 0che47q6DCxO; Mon, 16 Feb 2015 06:29:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BF31A1B98; Mon, 16 Feb 2015 06:29:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150216142925.22331.41143.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:29:25 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 14:29:27 -0000 The IESG has received a request from the SIP-TO-XMPP WG (stox) to consider the following document: - 'Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 16 06:29:37 2015 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 D46951A88A3; Mon, 16 Feb 2015 06:29:30 -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 E0xNuXunbQGv; Mon, 16 Feb 2015 06:29:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFC1A8894; Mon, 16 Feb 2015 06:29:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216142926.22331.14843.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:29:26 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Mon, 16 Feb 2015 14:29:31 -0000 Last call has been made for draft-ietf-stox-chat and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Mon Feb 16 06:29:40 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4E8131A88AD; Mon, 16 Feb 2015 06:29:31 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46951A88A3; Mon, 16 Feb 2015 06:29:30 -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 E0xNuXunbQGv; Mon, 16 Feb 2015 06:29:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFFC1A8894; Mon, 16 Feb 2015 06:29:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216142926.22331.14843.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:29:26 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Mon, 16 Feb 2015 14:29:31 -0000 Last call has been made for draft-ietf-stox-chat and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Mon Feb 16 06:47:09 2015 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 48A901A1B85; Mon, 16 Feb 2015 06:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 sIhCn8vsCX7W; Mon, 16 Feb 2015 06:47:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1125A1A1AE8; Mon, 16 Feb 2015 06:47:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150216144702.26701.41615.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:47:02 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 14:47:04 -0000 The IESG has received a request from the SIP-TO-XMPP WG (stox) to consider the following document: - 'Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 16 06:57:55 2015 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 23B8D1A1BBF; Mon, 16 Feb 2015 06:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 AJUjTpRgPH7z; Mon, 16 Feb 2015 06:57:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 671C01A1B65; Mon, 16 Feb 2015 06:57:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150216145751.30054.51287.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:57:51 -0800 Archived-At: Cc: stox@ietf.org Subject: [Stox] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 14:57:53 -0000 The IESG has received a request from the SIP-TO-XMPP WG (stox) to consider the following document: - 'Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a bidirectional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-stox-im/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-stox-im/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Feb 16 06:58:06 2015 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 321E91A1BFE; Mon, 16 Feb 2015 06:57:58 -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 EZmcackTVsxs; Mon, 16 Feb 2015 06:57:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 263B41A1BC3; Mon, 16 Feb 2015 06:57:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216145753.30054.62330.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:57:53 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Mon, 16 Feb 2015 14:57:58 -0000 Last call has been made for draft-ietf-stox-im and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Mon Feb 16 06:58:08 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EB5C51A1E0F; Mon, 16 Feb 2015 06:57:59 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321E91A1BFE; Mon, 16 Feb 2015 06:57:58 -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 EZmcackTVsxs; Mon, 16 Feb 2015 06:57:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 263B41A1BC3; Mon, 16 Feb 2015 06:57:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150216145753.30054.62330.idtracker@ietfa.amsl.com> Date: Mon, 16 Feb 2015 06:57:53 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Mon, 16 Feb 2015 14:58:00 -0000 Last call has been made for draft-ietf-stox-im and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Mon Feb 16 10:01:56 2015 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 EA1E91A2130 for ; Mon, 16 Feb 2015 10:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 YgiXjgxgtHMA for ; Mon, 16 Feb 2015 10:01:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055EE1A3BA9 for ; Mon, 16 Feb 2015 10:01:52 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B2A59207EA for ; Mon, 16 Feb 2015 13:01:49 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 16 Feb 2015 13:01:50 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; s=mesmtp; bh=2MlsInGsvKgNWeT9t PKB8PQDkwM=; b=wOR3yUWRG58YyFVx97D1LuA+C3kpkZzNuiw/uUsZP5tuqX8R7 3xyuUSeAtykD6FHpYmE/AozJm2mA/XQEZho2d/SxbkbDBROqXf1gdG9KpdOesNWe mXom25N0XKV99vVOII0HUyU8zlTrJTfC8+mTpHQiwlEdzNSUpwrXsaOsz4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type :content-transfer-encoding:subject:message-id:date:to :mime-version; s=smtpout; bh=2MlsInGsvKgNWeT9tPKB8PQDkwM=; b=Bwk fwQ7obHD2mQctvUQ0n2NtPD1W/ecX6GN2/g9ZV1HU4mtvxgUJOvP4RuvZh8HhD7w pC01Lh9SHf+wS8ed8AU5qU8CxvasNrWesEsz2xN9ux1yxwgjeakK7rGoZxO78PEq 1+CYoXUpa7tDhURo5ZkifKXcq95WQCuDRnwcpo1k= X-Sasl-enc: b+Hc6EG4eolL10B2T1SSlVIIZwUBo4qEuk7ljfTDP7xR 1424109709 Received: from dhcp-171-68-20-114.cisco.com (unknown [171.68.20.114]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D740C002A5 for ; Mon, 16 Feb 2015 13:01:49 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <10AC61C0-04EB-42B7-9816-A215B0463E75@cooperw.in> Date: Mon, 16 Feb 2015 10:01:48 -0800 To: stox@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Stox] Documents in IETF LC 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: Mon, 16 Feb 2015 18:01:55 -0000 The -im, -chat, and -groupchat documents are now in IETF LC. There were = a fair number of changes that resulted from my reviews and Ben=92s, so = folks in the WG should have a look and send comments during IETF LC if = they have them.=20 Alissa= From nobody Wed Feb 18 16:13:45 2015 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 2AC9E1A0AC8 for ; Wed, 18 Feb 2015 16:13:41 -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 IgCqzDR8cCgw for ; Wed, 18 Feb 2015 16:13:37 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD6E1A1B91 for ; Wed, 18 Feb 2015 16:13:37 -0800 (PST) Received: by ierx19 with SMTP id x19so5689129ier.3 for ; Wed, 18 Feb 2015 16:13:36 -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=+2FJDD/CWBx9d5QamJNa2KPzTZHZ0bubRtvYmATbSp0=; b=C5AxU5wbPoCIW7IZisU7Ita+a5RUrpnu8vvNWL13uxbxKGH8kKh8oUzzN6MN8LjKml o6X/QxQ+wQe/M9uDan3CuQpT8jK/8LCS7CSN5e7gVaPduHi23z4ZXrreIvVpj4kNrysI 33dv51I4j3DmyStoGt/fKMHcZVIfXvTIBsoYrbcNRc0e+N8MstevxoNW2dQ6akZ+DkNl 5bsxRM686FaYlfZ8HCESFCTgVy2y08U+lHE07y+2+9Vw85MMIA50R1EBQexJ5WVQG1nM JZUe2zY8m1zucGz+iMkEsXBPEhhAr6+MC9Nri387E8psKOIC1Qs0zRg3t12UIPom0EZw uyiA== X-Gm-Message-State: ALoCoQnV0mR//NRrVyqil8LSX2wo3oOpSRzPngcQRdiknKVVfbmcV7pxbsRPzGDn3thGNAhDb8D8 X-Received: by 10.50.25.166 with SMTP id d6mr6388694igg.41.1424304816732; Wed, 18 Feb 2015 16:13:36 -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 g195sm5691758iog.24.2015.02.18.16.13.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Feb 2015 16:13:36 -0800 (PST) Message-ID: <54E52AAF.1040407@andyet.net> Date: Wed, 18 Feb 2015 17:13:35 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "stox@ietf.org" References: <20150219001237.28306.18206.idtracker@ietfa.amsl.com> In-Reply-To: <20150219001237.28306.18206.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150219001237.28306.18206.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Stox] Fwd: New Version Notification for draft-saintandre-stox-7248bis-01.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: Thu, 19 Feb 2015 00:13:41 -0000 I fixed the CSeq values... -------- Forwarded Message -------- Subject: New Version Notification for draft-saintandre-stox-7248bis-01.txt Date: Wed, 18 Feb 2015 16:12:37 -0800 From: internet-drafts@ietf.org To: Peter Saint-Andre , Peter Saint-Andre A new version of I-D, draft-saintandre-stox-7248bis-01.txt has been successfully submitted by Peter Saint-Andre and posted to the IETF repository. Name: draft-saintandre-stox-7248bis Revision: 01 Title: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence Document date: 2015-02-18 Group: Individual Submission Pages: 27 URL: http://www.ietf.org/internet-drafts/draft-saintandre-stox-7248bis-01.txt Status: https://datatracker.ietf.org/doc/draft-saintandre-stox-7248bis/ Htmlized: http://tools.ietf.org/html/draft-saintandre-stox-7248bis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-saintandre-stox-7248bis-01 Abstract: This document defines a bi-directional protocol mapping for the exchange of presence information between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP). This document obsoletes RFC 7248. 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. The IETF Secretariat -- Peter Saint-Andre https://andyet.com/ From nobody Mon Feb 23 23:54:02 2015 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 A17B51A870D for ; Mon, 23 Feb 2015 23:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 raiszRGWbXPr for ; Mon, 23 Feb 2015 23:53:58 -0800 (PST) Received: from nok-msg-2.service.capgemini.fi (nok-msg-2.service.capgemini.fi [145.247.12.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024221A870C for ; Mon, 23 Feb 2015 23:53:57 -0800 (PST) Received: from unknown (HELO NOKWDCFIEXCH02P.nnok.nokia.com) ([10.50.38.50]) by noi-msg-2.service.capgemini.fi with ESMTP; 24 Feb 2015 09:53:55 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) by NOKWDCFIEXCH02P.nnok.nokia.com (10.50.38.50) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 24 Feb 2015 09:53:55 +0200 Received: from NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe]) by NOKWDCFIEXCH02P.nnok.nokia.com ([fe80::99d1:400a:d939:3ebe%17]) with mapi id 15.00.0995.028; Tue, 24 Feb 2015 09:53:55 +0200 From: "Isomaki Markus (Nokia-TECH/Espoo)" To: "stox@ietf.org" Thread-Topic: WG adoption and WGLC on draft-saintandre-stox-7248bis Thread-Index: AdBQA4z7chEikKMORAmzLTSKfVBwPA== Date: Tue, 24 Feb 2015 07:53:54 +0000 Message-ID: <3384940524514bf9a723c2aacaec430d@NOKWDCFIEXCH02P.nnok.nokia.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.50.32.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Stox] WG adoption and WGLC on draft-saintandre-stox-7248bis 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, 24 Feb 2015 07:54:00 -0000 Hi, STOX Presence specification was published as RFC already back in May 2014 (= https://datatracker.ietf.org/doc/rfc7248/). Only a few days later it was di= scovered it has errors on how the message flows were drawn. Basically, in 7= 248 message flows, SIP-to-XMPP gateway takes care of all messages oriented = from the SIP side, while a logically separate XMPP-to-SIP GW takes care of = all messages oriented from the XMPP side. The problem in those flows is tha= t even individual transactions are split across two GWs in this manner: the= response is handled by a different GW than the request. This would cause p= roblems to state maintenance in the GWs. See more details in http://www.iet= f.org/mail-archive/web/stox/current/msg00507.html.=20 This could be fixed by issuing an errata, but fixing message flow diagrams = in an errata is not the cleanest approach. So, Peter has submitted an entir= ely new (bis) version of the document (https://datatracker.ietf.org/doc/dra= ft-saintandre-stox-7248bis/), which when published as RFC would obsolete 72= 48. In practice the difference between 7248bis and 7248 is merely an editor= ial correction. STOX co-chairs are proposing that the best way forward indeed is the public= ation of 7248bis as an RFC. This is to our understanding the preference of = the RAI ADs too. As this should be a relatively simple (editorial) matter, = the chairs are proposing the following: 1.) draft-saintandre-stox-7248bis is adopted as STOX WG document. 2.) A WGLC is initiated on the WG document as soon as it is available. If someone has issues why this should not be done or has questions or comme= nts, please post them on the STOX mailing list within a week, i.e. latest o= n March 3. If there are no issues, the chairs will start the WGLC on March = 4. (On the WGLC we want a couple of reviews to make sure there are no bugs = left this time :-) Regards, Markus and Yana From nobody Tue Feb 24 14:06:22 2015 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 5644F1A903D; Tue, 24 Feb 2015 14:06:20 -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 7jISupX86-ZA; Tue, 24 Feb 2015 14:06:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F811A9038; Tue, 24 Feb 2015 14:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224220617.20803.64351.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 14:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Tue, 24 Feb 2015 22:06:20 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Tue Feb 24 14:06:23 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7E19A1A904D; Tue, 24 Feb 2015 14:06:20 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5644F1A903D; Tue, 24 Feb 2015 14:06:20 -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 7jISupX86-ZA; Tue, 24 Feb 2015 14:06:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F811A9038; Tue, 24 Feb 2015 14:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150224220617.20803.64351.idtracker@ietfa.amsl.com> Date: Tue, 24 Feb 2015 14:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Tue, 24 Feb 2015 22:06:20 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ From nobody Tue Feb 24 20:22:25 2015 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 B00E61A1B88 for ; Tue, 24 Feb 2015 20:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 0Q9Vq3gSFxdd for ; Tue, 24 Feb 2015 20:22:23 -0800 (PST) Received: from mail-ig0-f178.google.com (mail-ig0-f178.google.com [209.85.213.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F3A1A1AB8 for ; Tue, 24 Feb 2015 20:22:23 -0800 (PST) Received: by mail-ig0-f178.google.com with SMTP id hl2so2835664igb.5 for ; Tue, 24 Feb 2015 20:22:22 -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=nMPQrutEjG9NiY/KGc9TO53VXc5YNcSVQM7TtS2zETg=; b=QKJDsQypEJ4odBAtU10OUo3EIJg6JjGa+/O6RLRWvG/KoBto4I3NefTHBQVaSF5jYe 0C+3H19oryTbagmA9frmVs09Q1JFsfZFA175m34jGbYW6fMc3x7dsv6+/6OID/Z2ZI7B puf9q101xu7M75mTPqTmaqlaR8tAEo3cXqpbldY05d32KkXxuZC7t0TRaE8DFG1acqwE vmHVAu9EwMUSNDscLoQzobrvVb+fLKdZ6R9WAHK/xXRNrMwbyek1OM5OTFX/Rns/o4NT 2mTRnU2MP8ZY8XwjtR1c8kvCfosQFEkB72yUod6YXcFiEPXjeKL1BWGvE5GlkyioJqBL 8vWg== X-Gm-Message-State: ALoCoQmz0R5b87kpRJf1l1nKwDZO9km2MspkzfNq7jsTOlCzF0s2NxsnLHh/kewfqnDqRzTcO71m X-Received: by 10.42.104.68 with SMTP id q4mr1743589ico.35.1424838142594; Tue, 24 Feb 2015 20:22:22 -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 a31sm9222404ioj.42.2015.02.24.20.22.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 20:22:21 -0800 (PST) Message-ID: <54ED4DFB.4090104@andyet.net> Date: Tue, 24 Feb 2015 21:22:19 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <52CEDF2D.9090607@alum.mit.edu> <532A62D5.3060200@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: stox@ietf.org, Paul Kyzivat Subject: Re: [Stox] STOX Virtual Interim Meeting 2013-12-17 Minutes 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: Wed, 25 Feb 2015 04:22:24 -0000 Old thread alert! On 3/25/14 2:50 AM, Saúl Ibarra Corretgé wrote: > Hi, > > On Mar 20, 2014, at 4:39 AM, Peter Saint-Andre wrote: > >> Paul, thanks for the feedback and my apologies for the extremely slow reply. >> >> On 1/9/14, 10:41 AM, Paul Kyzivat wrote: >>> As requested, I have taken a look at treatment of Hold in section 6 of >>> draft-ietf-stox-media-02. >>> >>> The draft says: >>> >>> The same semantics are also >>> supported by Jingle through the "senders" element and its "initiator" >>> and "responder" values. >>> >>> [example to follow] >>> >>> In addition to these semantics however Jingle also defines a more >>> concise way for achieving the same, which consists in sending a >>> "hold" command within a "session-info" action: >>> >>> Before I can make any useful comments I need to get educated on some >>> aspects of xmpp. (I *browsed* XEP 0166, but couldn't quickly figure this >>> out.) Hopefully somebody can clue me in on the following: >>> >>> 1) I see that the "senders" element has values that correspond 1:1 with >>> SDP sendrecv/sendonly/recvonly/inactive. Are there equivalent >>> constraints on O/A behavior? Specifically that: >>> >>> Offer Permissible Answer >>> ----- ------------------ >>> sendrecv sendrecv/sendonly/recvonly/inactive >>> sendonly recvonly/inactive >>> recvonly sendonly/inactive >>> inactive inactive >> >> Although those constraints look reasonable, I think the original Jingle authors were not aware of them when defining the protocol. In general, Jingle implementations are simpler than SIP implementations, and might tend to assume senders='both' / a=sendrecv. Also, not all uses of the 'senders' attribute quite follow the offer/answer model - see, for instance, the content-modify action: >> > > Hum. Actually the XEP does mention compatibility with SDP O/A model: > > "Which parties in the session will be generating content (i.e., the direction in which a Jingle session is active); the allowable values are "both", "initiator", "none", and "responder" (where the default is "both"). Note that the defined values of the 'senders' attribute in Jingle correspond to the SDP attributes of "sendrecv", "sendonly", "inactive", and "recvonly" defined in RFC 4566 [30] and used in the offer-answer model RFC 3264." True. > However that element is *optional* except for content-modify. IIRC we did discuss about recommended practices, since this didn't seem to be very used out there. FWIW, when I worked on the SIP-XMPP gateway functionality for SylkServer I relied solely on session-info with 'hold'. This does of course limit the possible translation scenarios (ie, starting a session with a=inactive) though. In part it's optional because it has a default value of "both" (if the 'senders' attribute is not included, "both" applies). Looking at this again, I think the constraints that Jonathan mentions are fine, and of course they're consistent with RFC 3264, too. The only tricky bit is how to handle the content-modify action in Jingle, since it could be used to do something like change 'senders' from "initiator" ( = sendonly) to "responder" ( = recvonly) and AFAIK that's not something you can do in offer/answer without sending a new offer (and in Jingle it can be done mid-session, not in response to the original offer). Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Feb 24 20:35:59 2015 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 8A7BE1A1AB8 for ; Tue, 24 Feb 2015 20:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, 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 5GKQTYIULEGx for ; Tue, 24 Feb 2015 20:35:56 -0800 (PST) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB2B1A1A7E for ; Tue, 24 Feb 2015 20:35:56 -0800 (PST) Received: by iecvy18 with SMTP id vy18so1868673iec.13 for ; Tue, 24 Feb 2015 20:35:55 -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=plyy6j+zlEOYKfZS3uxFNR6GjCyPyfxFJUg55l3J8dg=; b=UWG9d5vE9ga0YMDRa0R7HYUJRgFO5q6UNQJwApKw14dk9CQZM3MdpUoxGBOoLtRqyV LE9ayQsB/KPLsteiAftg42j1CWEH05yFzibmHsC9tN3SbC0lqPzhgS2B9HjAAiYnxZt5 CJNCv+280+H6nphmay677TY8dpf+6CrzzRaB0vqRABiouCv8kDQjAKz5rFroz0J9Ikqz gBy0yFigLzsfd8kc8Ye1fqG1/79tU5cSWAuhW8H+AxrgcHBlDKCQoWWU30ieZb+uhzxD RkVYnDHaSSAZSN2YXowSvlBgOA/Fsunf7/Wol3wcYJbeVHoIEvruak3pI8vZlYX7asL3 b48Q== X-Gm-Message-State: ALoCoQm+WekmU0GEKOXzwvryJ6BmUK5ozV/jTfDFffaB1XmTe1IFbs1H/pDlL3vOiHfQRyI03ilM X-Received: by 10.50.111.168 with SMTP id ij8mr2195327igb.43.1424838955245; Tue, 24 Feb 2015 20:35:55 -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 m5sm9181271ige.5.2015.02.24.20.35.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 20:35:54 -0800 (PST) Message-ID: <54ED5128.40704@andyet.net> Date: Tue, 24 Feb 2015 21:35:52 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <1CFAA181-4E37-42EF-A5B4-70737C697B9E@vidyo.com> <532A6584.7000105@stpeter.im> <7D07DA47-ED22-47F6-A892-0541B83A60F9@ag-projects.com> In-Reply-To: <7D07DA47-ED22-47F6-A892-0541B83A60F9@ag-projects.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Jonathan Lennox , "stox@ietf.org" Subject: Re: [Stox] stox-media: format parameter translation 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: Wed, 25 Feb 2015 04:35:58 -0000 On 3/25/14 2:58 AM, Saúl Ibarra Corretgé wrote: > > On Mar 20, 2014, at 4:50 AM, Peter Saint-Andre wrote: > >> On 1/9/14, 10:22 AM, Jonathan Lennox wrote: >>> This is the issue I brought up at the Interim -- I'll try to put it >>> in writing. >>> >>> The point I raised is that the stox-media draft's section on format >>> parameter translation should try to focus on media types which are >>> actually used by existing, deployed Jingle clients, since this is >>> probably a relatively small set. The important question is which >>> payload formats in use by existing Jingle clients have SDP fmtp >>> formats that don't follow the normal semicolon-separated parameter >>> model. >>> >>> I of course haven't done a full inventory of such payload formats, >>> but two that seem reasonably likely and I think should be >>> particularly called out are: >>> >>> audio/telephone-event: RFC 4733: the fmtp contains the value of an >>> implicit "events" parameter. >> >> That one seems relevant. >> >>> audio/red: RFC 2198, with its media type registration in RFC 3555: >>> the fmtp is the payload types of the encompassed formats. The RFC >>> 3555 definition of the actual media type parameters is weird (in an >>> attempt to make it self-contained), and I doubt that any Jingle >>> client that does RED would actually use it that way. So we need to >>> figure out what any actual Jingle implementations do. >>> >>> Does anyone have a reasonably-authoritative list of which RTP payload >>> formats are supported by existing Jingle clients? >> >> I do not, but it's a small enough universe that we can poll the developers. (I expect it's mostly limited to common audio and video payloads - Speex, Opus, etc. - but we'll find out.) >> >>> Does anyone know >>> of any other real-world usage of codecs that have unusual fmtp >>> encodings? >> >> I think audio/telephone-event is a possibility. >> >>> Someone on the call mentioned that they thought that >>> Speex's was weird, but as far as I can tell, it's a normal >>> semicolon-separated encoding. >> >> Agreed. >> > > Same goes for H264 format AFAIS. It has many parameters, but in the end it's just a list of attribute=value separated by semicolons. Agreed. I'm doing some research into the most common payload types and will report back soon regarding my findings. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Tue Feb 24 20:38:15 2015 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 DB9AC1A1AB8 for ; Tue, 24 Feb 2015 20:38:13 -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 n9u2rzwVb9Hg for ; Tue, 24 Feb 2015 20:38:11 -0800 (PST) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26DE1A1A7E for ; Tue, 24 Feb 2015 20:38:10 -0800 (PST) Received: by iecar1 with SMTP id ar1so2027612iec.0 for ; Tue, 24 Feb 2015 20:38:10 -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=7Tq1JKDTOvFlXsxpAU8/ZfkaUy+ybnkW3wcj3iUslRA=; b=bY7Rmmids8lYi4ptlHcUKa3EDJk4QFKsY70wnbSk6OF1UroWXBNoK9VyWtBI8Tt0Yz tqAi1rxpj/2Tpvy4Yb918HGE5FHCnlRStA63srx/beO7P5yg8GiOaPt7VOQBIZuP9Lf0 u+1c+hXKDpbTib9rv0mOZGXGDHjM9jFUynGj7mZwjJwvgetCdyWHrSAPgolwWye/MA7k cR1AtjvNsneqY6xypSOJreVidGWnrzUskwBwQA/85vP7AFnS3InreOJmTV9/0mMd5hSJ YtXFHo+gOuf0f9tDRtEhYi8XwCn5B4W9A9+MA7/Sep+OyipEvNnJBxSTt+EcDTAlC6Fe sPSw== X-Gm-Message-State: ALoCoQklZVd/wCU9Vcv9hjfnHCwgi08J7aGFvgxmNP+06eEN8LAU/s50q+Izc9T9Pk6/2hNVkFck X-Received: by 10.42.166.134 with SMTP id o6mr996885icy.79.1424839090265; Tue, 24 Feb 2015 20:38:10 -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 qs3sm9180318igb.8.2015.02.24.20.38.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Feb 2015 20:38:09 -0800 (PST) Message-ID: <54ED51AF.5040403@andyet.net> Date: Tue, 24 Feb 2015 21:38:07 -0700 From: Peter Saint-Andre - &yet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Jonathan Lennox References: <26E25338-948C-43FA-A0AE-880BD1CB49B0@vidyo.com> <532A645A.3080605@stpeter.im> <5331BED1.3070202@jitsi.org> <5331FF4D.8010900@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "stox@ietf.org" , Emil Ivov , =?windows-1252?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [Stox] Stox-media: Should XEP-176 translations have Require: ice? 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: Wed, 25 Feb 2015 04:38:14 -0000 On 3/26/14 9:50 AM, Jonathan Lennox wrote: > > On Mar 25, 2014, at 6:12 PM, Peter Saint-Andre > wrote: > >> On 3/25/14, 12:03 PM, Jonathan Lennox wrote: >>> >>> On Mar 25, 2014, at 1:37 PM, Emil Ivov >> > wrote: >>> >>>> On 25.03.14, 15:15, Jonathan Lennox wrote: >>>>> >>>>> On Mar 25, 2014, at 4:55 AM, Saúl Ibarra Corretgé >>>>> > wrote: >>>>>>> >>>>>>> >>>>>>>> It occurred to me that SIP has a way of saying "do ICE, or >>>>>>>> fail the call": putting a "Require: ice" SIP option tag >>>>>>>> (from RFC 5768) in the SIP INVITE. >>>>>>>> >>>>>>>> Should we recommend this? It clearly has the right >>>>>>>> semantics, and will prevent interop failure when a non-ICE >>>>>>>> SIP endpoint answers a XEP-176 Jingle call. >>>>>>> >>>>>>> Theoretically that makes sense. >>>>>> >>>>>> Agreed. Maybe a gateway could do ICE on behalf of the non-ICE >>>>>> capable endpoint, so can we say this is implementation specific >>>>>> and thus add a MAY to it? >>>>> >>>>> Right, of course. I was talking about how you’d want to handle a >>>>> signaling-only gateway. >>>> >>>> There's also "XEP-0177: Jingle Raw UDP Transport Method" which is >>>> basically equivalent to ICE-less SIP. >>>> >>>> That said, I don't mind mandating ICE at all. >>> >>> Right, but there’s no way for a Jingle client to offer a choice >>> between XEP-176 and XEP-177, whereas RFC 5245 requires that both ICE >>> and fallback non-ICE be supported. >> >> Well, an XMPP initiator would not offer the ice-udp transport method >> if the responder didn't advertise support via XMPP service discovery >> (i.e., only advertised support for raw-udp). So, in general, fallback >> shouldn't really be necessary. However, we have defined a protocol >> flow for it just in case: >> >> http://xmpp.org/extensions/xep-0176.html#fallback > > The problem with that flow is the statement "Based on capabilities > information, the gateway knows that the SIP endpoint does not support > ICE”. Unfortunately, SIP doesn’t really have any workable way of > providing capabilities information, which is why RFC 5245 (and so much > of the rest of SIP) is single-exchange fallback. > > An alternative flow is possible, where you only send the > transport-replace on the Jingle side if the SIP answer indicates no ICE > support, and then send a SIP re-INVITE with the addresses in the > transport-accept. It’ll result a fairly substantial post-answer delay > before the media will get through, though. > > Here’s a sketch: > > Romeo Gateway Juliet > | | | > | session-initiate | | > | (audio definition) | | > |------------------------>| | > | ack | | > |<------------------------| SIP INVITE (ICE) | > | |------------------------>| > | transport-replace | 200 OK (Raw UDP) | > | (Raw UDP) |<------------------------| > |<------------------------| | > | ack | | > |------------------------>| | > | transport-accept | | > |------------------------>| | > | ack | | > |<------------------------| SIP INVITE (Raw UDP) | > | |------------------------>| > | | 200 OK (Raw UDP) | > | session-accept |<------------------------| > |<------------------------| | > | ack | | > |------------------------>| | > | MEDIA SESSION | > |<=================================================>| > | | | > That seems reasonable but I'll give it more thought soon. > This flow also relies on the SIP side not changing its local IP address > and port in response to a re-INVITE with a changed address, or the XMPP > side not changing its in response to a transport-replace maintaining raw > UDP; otherwise, the gateway can get into an infinite > re-INVITE/transport-replace loop. Yes, we'll want to document those possibilities. Peter -- Peter Saint-Andre https://andyet.com/ From nobody Thu Feb 26 09:40:53 2015 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 4B3D51A891A; Tue, 24 Feb 2015 13:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1vnd3Sukys0m; Tue, 24 Feb 2015 13:22:14 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B9E1A88BF; Tue, 24 Feb 2015 13:22:14 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t1OLMEl6009727; Tue, 24 Feb 2015 21:22:14 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 939ABC207C6; Tue, 24 Feb 2015 21:22:14 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150216142925.22331.20632.idtracker@ietfa.amsl.com> References: <20150216142925.22331.20632.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #808977 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 24 Feb 2015 21:22:14 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 09:40:52 -0800 Cc: stox@ietf.org, iesg@ietf.org, draft-ietf-stox-chat.all@ietf.org, stox-chairs@ietf.org Subject: [Stox] [IANA #808977] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:22:16 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-stox-chat-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Mon Feb 16 14:29:51 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the SIP-TO-XMPP WG (stox) to > consider the following document: > - 'Interworking between the Session Initiation Protocol (SIP) and the > Extensible Messaging and Presence Protocol (XMPP): One-to-One Text > Chat Sessions' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a one-to-one chat > session between a user of the Session Initiation Protocol (SIP) and a > user of the Extensible Messaging and Presence Protocol (XMPP). > Specifically for SIP text chat, this document specifies a mapping to > the Message Session Relay Protocol (MSRP). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Feb 26 09:41:09 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-chat.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 688681A88BF; Tue, 24 Feb 2015 13:22:16 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-chat.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3D51A891A; Tue, 24 Feb 2015 13:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1vnd3Sukys0m; Tue, 24 Feb 2015 13:22:14 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B9E1A88BF; Tue, 24 Feb 2015 13:22:14 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t1OLMEl6009727; Tue, 24 Feb 2015 21:22:14 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 939ABC207C6; Tue, 24 Feb 2015 21:22:14 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150216142925.22331.20632.idtracker@ietfa.amsl.com> References: <20150216142925.22331.20632.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #808977 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Tue, 24 Feb 2015 21:22:14 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 09:41:07 -0800 Cc: stox@ietf.org, iesg@ietf.org, draft-ietf-stox-chat.all@ietf.org, stox-chairs@ietf.org Subject: [Stox] [IANA #808977] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2015 21:22:16 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-stox-chat-10, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Mon Feb 16 14:29:51 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the SIP-TO-XMPP WG (stox) to > consider the following document: > - 'Interworking between the Session Initiation Protocol (SIP) and the > Extensible Messaging and Presence Protocol (XMPP): One-to-One Text > Chat Sessions' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a bidirectional protocol mapping for the > exchange of instant messages in the context of a one-to-one chat > session between a user of the Session Initiation Protocol (SIP) and a > user of the Extensible Messaging and Presence Protocol (XMPP). > Specifically for SIP text chat, this document specifies a mapping to > the Message Session Relay Protocol (MSRP). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-stox-chat/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Feb 26 09:41:24 2015 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 207C71A1B0E; Thu, 26 Feb 2015 09:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 v44BbtUFSAcw; Thu, 26 Feb 2015 09:12:16 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA641A1A32; Thu, 26 Feb 2015 09:12:16 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t1QHCGxa025574; Thu, 26 Feb 2015 17:12:16 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 2F2DBC20284; Thu, 26 Feb 2015 17:12:16 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150216145751.30054.68218.idtracker@ietfa.amsl.com> References: <20150216145751.30054.68218.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #808986 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 26 Feb 2015 17:12:16 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 09:41:19 -0800 Cc: stox@ietf.org, yana@jitsi.org, draft-ietf-stox-im.all@ietf.org, stox-chairs@ietf.org Subject: [Stox] [IANA #808986] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:12:18 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-stox-im-12, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Mon Feb 16 14:58:17 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the SIP-TO-XMPP WG (stox) to > consider the following document: > - 'Interworking between the Session Initiation Protocol (SIP) and the > Extensible Messaging and Presence Protocol (XMPP): Instant > Messaging' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a bidirectional protocol mapping for the > exchange of single instant messages between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-stox-im/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-stox-im/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Feb 26 09:41:35 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4781C1A1A32; Thu, 26 Feb 2015 09:12:18 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207C71A1B0E; Thu, 26 Feb 2015 09:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 v44BbtUFSAcw; Thu, 26 Feb 2015 09:12:16 -0800 (PST) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA641A1A32; Thu, 26 Feb 2015 09:12:16 -0800 (PST) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t1QHCGxa025574; Thu, 26 Feb 2015 17:12:16 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 2F2DBC20284; Thu, 26 Feb 2015 17:12:16 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150216145751.30054.68218.idtracker@ietfa.amsl.com> References: <20150216145751.30054.68218.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #808986 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 26 Feb 2015 17:12:16 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Thu, 26 Feb 2015 09:41:35 -0800 Cc: stox@ietf.org, yana@jitsi.org, draft-ietf-stox-im.all@ietf.org, stox-chairs@ietf.org Subject: [Stox] [IANA #808986] Last Call: (Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging) to Proposed Standard X-BeenThere: stox@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: SIP-TO-XMPP Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 17:12:18 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-stox-im-12, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Mon Feb 16 14:58:17 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the SIP-TO-XMPP WG (stox) to > consider the following document: > - 'Interworking between the Session Initiation Protocol (SIP) and the > Extensible Messaging and Presence Protocol (XMPP): Instant > Messaging' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-02. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document defines a bidirectional protocol mapping for the > exchange of single instant messages between the Session Initiation > Protocol (SIP) and the Extensible Messaging and Presence Protocol > (XMPP). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-stox-im/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-stox-im/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Thu Feb 26 10:06:25 2015 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 143E31A88D0; Thu, 26 Feb 2015 10:06:23 -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 HcLb-Nnxbtti; Thu, 26 Feb 2015 10:06:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D611C1A90BF; Thu, 26 Feb 2015 10:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226180617.13383.42805.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 10:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Thu, 26 Feb 2015 18:06:23 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/ From nobody Thu Feb 26 10:06:27 2015 Return-Path: X-Original-To: expand-draft-ietf-stox-im.all@virtual.ietf.org Delivered-To: stox@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 458221A90AD; Thu, 26 Feb 2015 10:06:23 -0800 (PST) X-Original-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-stox-im.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143E31A88D0; Thu, 26 Feb 2015 10:06:23 -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 HcLb-Nnxbtti; Thu, 26 Feb 2015 10:06:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D611C1A90BF; Thu, 26 Feb 2015 10:06:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226180617.13383.42805.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 10:06:17 -0800 From: IETF Secretariat Archived-At: Subject: [Stox] ID Tracker State Update Notice: 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: Thu, 26 Feb 2015 18:06:23 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-stox-im/