From miguel.a.garcia@ericsson.com Tue Sep 4 06:35:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0A21F8543 for ; Tue, 4 Sep 2012 06:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HEqMPL4+1Ur for ; Tue, 4 Sep 2012 06:35:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 35A2821F852C for ; Tue, 4 Sep 2012 06:35:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-ab-504603b31c2f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C6.DB.17130.3B306405; Tue, 4 Sep 2012 15:35:47 +0200 (CEST) Received: from [159.107.24.194] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Tue, 4 Sep 2012 15:35:46 +0200 Message-ID: <504603AF.50006@ericsson.com> Date: Tue, 4 Sep 2012 15:35:43 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Simple WG References: <5046030A.5070902@ericsson.com> In-Reply-To: <5046030A.5070902@ericsson.com> X-Forwarded-Message-Id: <5046030A.5070902@ericsson.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnluLIzCtJLcpLzFFi42KZGfG3Vnczs1uAwa9mCYuFE/+xOjB6LFny kymAMYrLJiU1J7MstUjfLoErY9mCp6wFH+wqzlycw9zA+MGwi5GTQ0LARGLNm3ksELaYxIV7 69m6GLk4hAROMUq8PdEE5axmlGjbfpwNpIpXQFPixabdTCA2i4CKxO2Nm5lBbDYBc4nWjRvZ QWxRgUCJdVf/sEPUC0qcnPkEbIOIgLzEi9m/wHqFBVIkTh+YwgpiCwloSyxt2whmcwroSDy8 dpoN4iJziT3zf4LNYRawkFj85iCULS+x/e0cZoheTYnJN5cyT2AUnIVk3SwkLbOQtCxgZF7F KJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYmAe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZ qakFqUXxRaU5qcWHGJk4OKUaGDPumTU1H5293ruw/p1DQa/U09luW4p9DG+l5sYWax+J27W1 Vdtj0dmH1WVb3nEsei2VOt00Peu6Rbr/pXPfKkx7Lwon7Q1wN1F6sO2Vnn3bLY+id76xrhlH F8TtdLIL0Sv2s/OdVJAvki5s3e31qOKjc/SjA/sn9+wNFLw5800l01MNvv7FSizFGYmGWsxF xYkAf+wvWxoCAAA= Subject: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 13:35:50 -0000 I am forwarding this discussion/comments with Adrian Farrel in case someone has an opinion different than the one I expressed. -------- Original Message -------- Subject: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) Date: Tue, 4 Sep 2012 15:32:58 +0200 From: Miguel A. Garcia To: Adrian Farrel CC: The IESG , "simple-chairs@tools.ietf.org" , "draft-ietf-simple-chat@tools.ietf.org" Hi Adrian: Thanks for your comments. Please find some answers inline. On 04/09/2012 14:16, Adrian Farrel wrote: > Adrian Farrel has entered the following ballot position for > draft-ietf-simple-chat-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks, this is a well-written and easy-to-read document. Just a couple > (well, three) of small issues that I would like to Discuss. > > --- > > Surpised that there are no requirements on authetication or control of > admission to chat rooms. Was this topic discussed by the WG and left out > on purpose (in which case we should add a note to that effect), was it > forgotten (in which case we should address it), or is it not relevant > for this type of chat (in which case you just need to explain it to me)? This draft expands on many others, including SIP, conferences, SDP, and MSRP. Authentication and authorization lies withing those protocols. In particular, this draft builds on RFC 4353 (SIP Conferencing Framework), which in Section 7 says: Conferences frequently require security features in order to properly operate. The conference policy may dictate that only certain participants can join, or that certain participants can create new policies. Generally speaking, conference applications are very concerned about authorization decisions. Having mechanisms for establishing and enforcing such authorization rules is a central concept throughout this document. Of course, authorization rules require authentication. Normal SIP authentication mechanisms should suffice for the conference authorization mechanisms described here. > > I would assume that the INVITE can be policed in some way. The best I > could find was in Section 5.2 > > Participants usually join the chat room by sending an INVITE request > to the chat room URI. As long as the chat room policy allows, the > INVITE request is accepted by the focus and the user is brought into > the actual chat room. > > Indeed, there are several mentions of things being allowed according to > chat-room policy, but no wider discussion of the full set of policy > attributes, or how chat room policy is set. Right, perhaps the text could be improved by replacing the above paragraph with this one: Participants usually join the chat room by sending an INVITE request to the chat room URI. The chat room them uses regular SIP mechanisms to authenticate the participant. This may include, e.g., client certificates, SIP Digest authentication [RFC3261], asserted network identity [RFC3325], etc. As long as the user is authenticated, the INVITE request is accepted by the focus and the user is brought into the actual chat room. Now, about the policy of the chat room. I think you have a good point. There should be a single place where we can list all the policy attributes and their semantics. Currently these are spread throughout the document, making it difficult to keep track of them. To address this issue, I suggest to add a new section 4.1, (inside the Overview of Operation), that briefly lists all those policy attributes and refers to sections where they are described in the appropriate context. > > --- > > Section 6.1 > > On sending a regular message the sender MUST populate the To header > of the Message/CPIM wrapper with the URI of the chat room. The > sender SHOULD populate the From header of the Message/CPIM wrapper > with a proper identifier by which the user is recognized in the chat > room. > > I'm uncomfortable with the "SHOULD" here. It implies that you can think > of a good reason why the sender MAY use some other (improper) identifier > or no identifier at all. Can you either give an example (perhaps: "The > sender MAY set an arbitrary and meaningless value in order to hide its > identitiy"), or tighten the SHOULD to a MUST. Honestly, I don't remember any scenario where a participant could populate the From header of the Message/CPIM wrapper with some other identifier. Even if the user is using an Anonymous URI at the SIP level, he should use the same URI in Message/CPIM, in which case the MUST is still valid. I proposed to replace the SHOULD with a MUST. > > --- > > Section 6.1 > > An MSRP > switch that uses this fast forwarding procedure MUST temporarily > store the Message-Id of the MSRP message to correlate the different > chunks, as well as it MUST temporarily store the list of recipients > to which the initial chunks were delivered. > > The motivaiton is clear. I think you could add that the storage can be > released when the last chunk is seen. But what happens when the last > chunk is not seen (or delayed)? How temporary is the storage, and how is > it released? Yes, we can add that the temporary storage is released when the last chunk is seen or after a reasonable time passes. > > Or do we assume that because MSRP uses TCP (or similar) that loss will > always be accompanied by connection failure and so that is the only > trigger needed to abandon temporary storage? Yes, on one side, the assumption is that if a last chunk is not seen is because there has been a transport failure. Since TCP is used, then the TCP connection was broken, and is in the process of being re-established. I am more concerned about what happens if the last chunk is not seen at all, I am not sure the state the MSRP session will be, even if the connection is re-established. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 4 > > In order to enter a chat room, one must first be created. > > Obviously, I spend to much time hanging out with the Queen, but when you > say "one must be created" I suspect you meant the chat room, not one's > self. Maybe reword as... > > Before a chat room can be entered, it must be created. > Ok. > --- > > Section 6.1 (trivial nit) > > The SEND request MUST contain a top-level wrapper of type 'Message/ > CPIM' according to RFC 3862 [RFC3862]. The actual instant message > payload MUST be included as payload of the 'Message/CPIM' wrapper and > MAY be of any type negotiated in the SDP 'accept-types' attribute > according to the MSRP rules. > > I think s/MAY/may/. That is, a type must be set, and the type must be > only one of those that has been negotiated. > > I think this MAY should actually be a MUST, because as you said, a types must be said, and this type cannot be anyone, but it MUST be one of those negotiated. I like the "according to the MSRP rules", as a mechanism to indicate that we are not mandating something new, but just copying what MSRP mandates. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Tue Sep 4 07:12:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6E21F8476 for ; Tue, 4 Sep 2012 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mn2ZxS84BbOh for ; Tue, 4 Sep 2012 07:12:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F077B21F8471 for ; Tue, 4 Sep 2012 07:12:10 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q84EC45s045193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Sep 2012 09:12:04 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504603AF.50006@ericsson.com> Date: Tue, 4 Sep 2012 09:12:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <275B9667-FE83-47C1-A888-EDC517976499@nostrum.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:12:13 -0000 (As Chair) Everyone please note that Miguel's response involves some teaks to = normative language. They are small, but still substantive. This email = will serve to vet any such changes with the working group--if you = have any objection, please say so ASAP. Thanks! Ben. On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" = wrote: > I am forwarding this discussion/comments with Adrian Farrel in case = someone has an opinion different than the one I expressed. >=20 >=20 > -------- Original Message -------- > Subject: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: = (with DISCUSS and COMMENT) > Date: Tue, 4 Sep 2012 15:32:58 +0200 > From: Miguel A. Garcia > To: Adrian Farrel > CC: The IESG , "simple-chairs@tools.ietf.org" = , "draft-ietf-simple-chat@tools.ietf.org" = >=20 > Hi Adrian: >=20 > Thanks for your comments. Please find some answers inline. >=20 > On 04/09/2012 14:16, Adrian Farrel wrote: >> Adrian Farrel has entered the following ballot position for >> draft-ietf-simple-chat-16: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> Thanks, this is a well-written and easy-to-read document. Just a = couple >> (well, three) of small issues that I would like to Discuss. >>=20 >> --- >>=20 >> Surpised that there are no requirements on authetication or control = of >> admission to chat rooms. Was this topic discussed by the WG and left = out >> on purpose (in which case we should add a note to that effect), was = it >> forgotten (in which case we should address it), or is it not relevant >> for this type of chat (in which case you just need to explain it to = me)? >=20 > This draft expands on many others, including SIP, conferences, SDP, = and > MSRP. Authentication and authorization lies withing those protocols. >=20 > In particular, this draft builds on RFC 4353 (SIP Conferencing > Framework), which in Section 7 says: >=20 > Conferences frequently require security features in order to = properly > operate. The conference policy may dictate that only certain > participants can join, or that certain participants can create new > policies. Generally speaking, conference applications are very > concerned about authorization decisions. Having mechanisms for > establishing and enforcing such authorization rules is a central > concept throughout this document. >=20 > Of course, authorization rules require authentication. Normal SIP > authentication mechanisms should suffice for the conference > authorization mechanisms described here. >=20 >=20 >>=20 >> I would assume that the INVITE can be policed in some way. The best I >> could find was in Section 5.2 >>=20 >> Participants usually join the chat room by sending an INVITE = request >> to the chat room URI. As long as the chat room policy allows, the >> INVITE request is accepted by the focus and the user is brought = into >> the actual chat room. >>=20 >> Indeed, there are several mentions of things being allowed according = to >> chat-room policy, but no wider discussion of the full set of policy >> attributes, or how chat room policy is set. >=20 > Right, perhaps the text could be improved by replacing the above > paragraph with this one: >=20 > Participants usually join the chat room by sending an INVITE request = to > the chat room URI. The chat room them uses regular SIP mechanisms to > authenticate the participant. This may include, e.g., client > certificates, SIP Digest authentication [RFC3261], asserted network > identity [RFC3325], etc. As long as the user is authenticated, the = INVITE > request is accepted by the focus and the user is brought into > the actual chat room. >=20 >=20 > Now, about the policy of the chat room. I think you have a good point. > There should be a single place where we can list all the policy > attributes and their semantics. Currently these are spread throughout = the > document, making it difficult to keep track of them. >=20 > To address this issue, I suggest to add a new section 4.1, (inside the > Overview of Operation), that briefly lists all those policy attributes > and refers to sections where they are described in the appropriate = context. >=20 >>=20 >> --- >>=20 >> Section 6.1 >>=20 >> On sending a regular message the sender MUST populate the To = header >> of the Message/CPIM wrapper with the URI of the chat room. The >> sender SHOULD populate the =46rom header of the Message/CPIM = wrapper >> with a proper identifier by which the user is recognized in the = chat >> room. >>=20 >> I'm uncomfortable with the "SHOULD" here. It implies that you can = think >> of a good reason why the sender MAY use some other (improper) = identifier >> or no identifier at all. Can you either give an example (perhaps: = "The >> sender MAY set an arbitrary and meaningless value in order to hide = its >> identitiy"), or tighten the SHOULD to a MUST. >=20 > Honestly, I don't remember any scenario where a participant could > populate the =46rom header of the Message/CPIM wrapper with some other > identifier. Even if the user is using an Anonymous URI at the SIP = level, > he should use the same URI in Message/CPIM, in which case the MUST is > still valid. >=20 > I proposed to replace the SHOULD with a MUST. >=20 >=20 >>=20 >> --- >>=20 >> Section 6.1 >>=20 >> An MSRP >> switch that uses this fast forwarding procedure MUST temporarily >> store the Message-Id of the MSRP message to correlate the = different >> chunks, as well as it MUST temporarily store the list of = recipients >> to which the initial chunks were delivered. >>=20 >> The motivaiton is clear. I think you could add that the storage can = be >> released when the last chunk is seen. But what happens when the last >> chunk is not seen (or delayed)? How temporary is the storage, and how = is >> it released? >=20 > Yes, we can add that the temporary storage is released when the last > chunk is seen or after a reasonable time passes. >>=20 >> Or do we assume that because MSRP uses TCP (or similar) that loss = will >> always be accompanied by connection failure and so that is the only >> trigger needed to abandon temporary storage? >=20 > Yes, on one side, the assumption is that if a last chunk is not seen = is > because there has been a transport failure. Since TCP is used, then = the > TCP connection was broken, and is in the process of being = re-established. > I am more concerned about what happens if the last chunk is not seen = at > all, I am not sure the state the MSRP session will be, even if the > connection is re-established. >=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 4 >>=20 >> In order to enter a chat room, one must first be created. >>=20 >> Obviously, I spend to much time hanging out with the Queen, but when = you >> say "one must be created" I suspect you meant the chat room, not = one's >> self. Maybe reword as... >>=20 >> Before a chat room can be entered, it must be created. >>=20 >=20 > Ok. >=20 >=20 >> --- >>=20 >> Section 6.1 (trivial nit) >>=20 >> The SEND request MUST contain a top-level wrapper of type = 'Message/ >> CPIM' according to RFC 3862 [RFC3862]. The actual instant message >> payload MUST be included as payload of the 'Message/CPIM' wrapper = and >> MAY be of any type negotiated in the SDP 'accept-types' attribute >> according to the MSRP rules. >>=20 >> I think s/MAY/may/. That is, a type must be set, and the type must be >> only one of those that has been negotiated. >>=20 >>=20 >=20 > I think this MAY should actually be a MUST, because as you said, a = types > must be said, and this type cannot be anyone, but it MUST be one of = those > negotiated. >=20 > I like the "according to the MSRP rules", as a mechanism to indicate = that > we are not mandating something new, but just copying what MSRP = mandates. >=20 > /Miguel > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Tue Sep 4 07:26:07 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1924911E8097 for ; Tue, 4 Sep 2012 07:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ans0lw0Jb0aO for ; Tue, 4 Sep 2012 07:26:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62AE721F84DF for ; Tue, 4 Sep 2012 07:26:06 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q84EQ337046463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Sep 2012 09:26:03 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504603AF.50006@ericsson.com> Date: Tue, 4 Sep 2012 09:26:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 14:26:07 -0000 (As individual) Hi, I agree with Miguel's responses except as noted inline Thanks! Ben. On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" = wrote: >=20 >>=20 >> --- >>=20 >> Section 6.1 >>=20 >> An MSRP >> switch that uses this fast forwarding procedure MUST temporarily >> store the Message-Id of the MSRP message to correlate the = different >> chunks, as well as it MUST temporarily store the list of = recipients >> to which the initial chunks were delivered. >>=20 >> The motivaiton is clear. I think you could add that the storage can = be >> released when the last chunk is seen. But what happens when the last >> chunk is not seen (or delayed)? How temporary is the storage, and how = is >> it released? >=20 > Yes, we can add that the temporary storage is released when the last > chunk is seen or after a reasonable time passes. The "how long to wait for a chunk" problem is no different than for any = other endpoint, is it, other than possibly differences of scale? I = suggest we refer back to 4975 for this, with the possible note to the = effect of "This is no different than for any MSRP endpoint that receives = a chunked message. However, since a conference switch will typically = participate many sessions at one time, storage management may be more = critical" >>=20 >> Or do we assume that because MSRP uses TCP (or similar) that loss = will >> always be accompanied by connection failure and so that is the only >> trigger needed to abandon temporary storage? >=20 > Yes, on one side, the assumption is that if a last chunk is not seen = is > because there has been a transport failure. Since TCP is used, then = the > TCP connection was broken, and is in the process of being = re-established. > I am more concerned about what happens if the last chunk is not seen = at > all, I am not sure the state the MSRP session will be, even if the > connection is re-established. Keep in mind there could be an MSRP relay between the sender and the = switch, so the transport connection may not be direct. But again, this = is no different than for any other MSRP endpoint. >=20 >=20 >> --- >>=20 >> Section 6.1 (trivial nit) >>=20 >> The SEND request MUST contain a top-level wrapper of type = 'Message/ >> CPIM' according to RFC 3862 [RFC3862]. The actual instant message >> payload MUST be included as payload of the 'Message/CPIM' wrapper = and >> MAY be of any type negotiated in the SDP 'accept-types' attribute >> according to the MSRP rules. >>=20 >> I think s/MAY/may/. That is, a type must be set, and the type must be >> only one of those that has been negotiated. >>=20 >>=20 >=20 > I think this MAY should actually be a MUST, because as you said, a = types > must be said, and this type cannot be anyone, but it MUST be one of = those > negotiated. This is already mandated in RFC4975 (as you go on to say...). The only = thing new is the normative requirement for a particular wrapper type. It = might be worth commenting that this is accomplished by putting only = Message/CPIM in accept-types, and all allowed leaf types in = accept-wrapped-types. >=20 > I like the "according to the MSRP rules", as a mechanism to indicate = that > we are not mandating something new, but just copying what MSRP = mandates. >=20 ... in which case it should be stated descriptively, not normatively. From pkyzivat@alum.mit.edu Tue Sep 4 08:29:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8B21F864D for ; Tue, 4 Sep 2012 08:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmsnvabln743 for ; Tue, 4 Sep 2012 08:29:51 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 586D121F863C for ; Tue, 4 Sep 2012 08:29:51 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id v0hY1j0011ap0As5C3Vupe; Tue, 04 Sep 2012 15:29:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id v3WJ1j00N3ZTu2S3i3WJLg; Tue, 04 Sep 2012 15:30:18 +0000 Message-ID: <50461E6D.8040803@alum.mit.edu> Date: Tue, 04 Sep 2012 11:29:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: simple@ietf.org References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> In-Reply-To: <504603AF.50006@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 15:29:52 -0000 On 9/4/12 9:35 AM, Miguel A. Garcia wrote: >> Section 6.1 >> >> An MSRP >> switch that uses this fast forwarding procedure MUST temporarily >> store the Message-Id of the MSRP message to correlate the different >> chunks, as well as it MUST temporarily store the list of recipients >> to which the initial chunks were delivered. >> >> The motivaiton is clear. I think you could add that the storage can be >> released when the last chunk is seen. But what happens when the last >> chunk is not seen (or delayed)? How temporary is the storage, and how is >> it released? > > Yes, we can add that the temporary storage is released when the last > chunk is seen or after a reasonable time passes. >> >> Or do we assume that because MSRP uses TCP (or similar) that loss will >> always be accompanied by connection failure and so that is the only >> trigger needed to abandon temporary storage? > > Yes, on one side, the assumption is that if a last chunk is not seen is > because there has been a transport failure. Since TCP is used, then the > TCP connection was broken, and is in the process of being re-established. > I am more concerned about what happens if the last chunk is not seen at > all, I am not sure the state the MSRP session will be, even if the > connection is re-established. Because a failed TCP connection may be reestablished, and the chunk sent over the new connection, you can't use connection loss as a trigger for giving up on incomplete chunked messages. The receiver has no firm way to distinguish between a chunk that has been a chunk that has been lost and one that has simply been delayed. This has to be dealt with via implementation policies and heuristics. Thanks, Paul From ben@nostrum.com Tue Sep 4 09:07:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4509811E808A for ; Tue, 4 Sep 2012 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUVul8bDUaSB for ; Tue, 4 Sep 2012 09:07:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4F521F84A0 for ; Tue, 4 Sep 2012 09:07:27 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q84G7OU5056107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Sep 2012 11:07:24 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50461E6D.8040803@alum.mit.edu> Date: Tue, 4 Sep 2012 11:07:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2012 16:07:28 -0000 On Sep 4, 2012, at 10:29 AM, Paul Kyzivat wrote: > On 9/4/12 9:35 AM, Miguel A. Garcia wrote: >=20 >>> Section 6.1 >>>=20 >>> An MSRP >>> switch that uses this fast forwarding procedure MUST temporarily >>> store the Message-Id of the MSRP message to correlate the = different >>> chunks, as well as it MUST temporarily store the list of = recipients >>> to which the initial chunks were delivered. >>>=20 >>> The motivaiton is clear. I think you could add that the storage can = be >>> released when the last chunk is seen. But what happens when the last >>> chunk is not seen (or delayed)? How temporary is the storage, and = how is >>> it released? >>=20 >> Yes, we can add that the temporary storage is released when the last >> chunk is seen or after a reasonable time passes. >>>=20 >>> Or do we assume that because MSRP uses TCP (or similar) that loss = will >>> always be accompanied by connection failure and so that is the only >>> trigger needed to abandon temporary storage? >>=20 >> Yes, on one side, the assumption is that if a last chunk is not seen = is >> because there has been a transport failure. Since TCP is used, then = the >> TCP connection was broken, and is in the process of being = re-established. >> I am more concerned about what happens if the last chunk is not seen = at >> all, I am not sure the state the MSRP session will be, even if the >> connection is re-established. >=20 > Because a failed TCP connection may be reestablished, and the chunk = sent over the new connection, you can't use connection loss as a trigger = for giving up on incomplete chunked messages. >=20 > The receiver has no firm way to distinguish between a chunk that has = been a chunk that has been lost and one that has simply been delayed. = This has to be dealt with via implementation policies and heuristics. That's a good point. While a connection failure ends the "session", the = endpoints can attempt to reestablish a new session and send the = remaining chunks over it. So I concur the best we can offer is to wait a = "reasonable time". I can see "reasonable" being different for a = high-volume switch than for an end-user endpoint. >=20 > Thanks, > Paul > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Wed Sep 5 00:15:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833BC21F849D for ; Wed, 5 Sep 2012 00:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGi1FthT0qff for ; Wed, 5 Sep 2012 00:15:51 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4411E80D3 for ; Wed, 5 Sep 2012 00:15:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-5b-5046fc256078 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EA.BB.11467.52CF6405; Wed, 5 Sep 2012 09:15:50 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 09:15:49 +0200 Message-ID: <5046FC24.8030604@ericsson.com> Date: Wed, 5 Sep 2012 09:15:48 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vlftj1uAweodjBbzO0+zWyyc+I/V gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MqY9O4wU8FGxYoti14wNjAulupi5OSQEDCR aJnzgRnCFpO4cG89WxcjF4eQwClGiTndzUwgCSGB1YwSX08adDFycPAKaEvMW6sLEmYRUJHo eXyeDcRmEzCXaN24kR3EFhUIlFh39Q+YzSsgKHFy5hMWEFtEQEniefNWMJtZQF5i4eZmRhBb WKBQYse9h1CraiQ2f5sLdg+ngL3E7FOLWCHqbSUuzLkO17v97RxmiHpNick3lzJPYBSchWTd LCQts5C0LGBkXsUonJuYmZNebqiXWpSZXFycn6dXnLqJERioB7f81t3BeOqcyCFGaQ4WJXFe rqT9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYDZ5NfG6cVy6Z9PrzZLMCNrY7L/lWKEWb b961X/i+Sq1uvM3LK6EPg+ZL5lxqeJGTEZguUnHPfmHi+6rp284eP+kfHPHE/aZiz58X2zq0 zGskTTM2rJOJ+XJQQvzSCXulMybrt7Spf1+z03PJ8182VT+ZL+iKO+90lBFv0Ysp7ruSdlv8 98nNSizFGYmGWsxFxYkASLFr6CICAAA= Cc: Simple WG Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:15:52 -0000 Hi Ben, Thanks for your comments On 04/09/2012 16:26, Ben Campbell wrote: > (As individual) > > Hi, > > I agree with Miguel's responses except as noted inline > > Thanks! > > Ben. > > On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" > wrote: >> >>> >>> --- >>> >>> Section 6.1 >>> >>> An MSRP switch that uses this fast forwarding procedure MUST >>> temporarily store the Message-Id of the MSRP message to correlate >>> the different chunks, as well as it MUST temporarily store the >>> list of recipients to which the initial chunks were delivered. >>> >>> The motivaiton is clear. I think you could add that the storage >>> can be released when the last chunk is seen. But what happens when >>> the last chunk is not seen (or delayed)? How temporary is the >>> storage, and how is it released? >> >> Yes, we can add that the temporary storage is released when the >> last chunk is seen or after a reasonable time passes. > > The "how long to wait for a chunk" problem is no different than for > any other endpoint, is it, other than possibly differences of scale? I > suggest we refer back to 4975 for this, with the possible note to the > effect of "This is no different than for any MSRP endpoint that > receives a chunked message. However, since a conference switch will > typically participate many sessions at one time, storage management > may be more critical" I would like to include a reference to the section in RFC 4975 that discusses this topic. I guess it is Section 5.3, when it discusses what happens if a transport connection fails. > >>> >>> Or do we assume that because MSRP uses TCP (or similar) that loss >>> will always be accompanied by connection failure and so that is >>> the only trigger needed to abandon temporary storage? >> >> Yes, on one side, the assumption is that if a last chunk is not seen >> is because there has been a transport failure. Since TCP is used, >> then the TCP connection was broken, and is in the process of being >> re-established. I am more concerned about what happens if the last >> chunk is not seen at all, I am not sure the state the MSRP session >> will be, even if the connection is re-established. > > Keep in mind there could be an MSRP relay between the sender and the > switch, so the transport connection may not be direct. But again, this > is no different than for any other MSRP endpoint. Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975. > >> >> >>> --- >>> >>> Section 6.1 (trivial nit) >>> >>> The SEND request MUST contain a top-level wrapper of type >>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>> instant message payload MUST be included as payload of the >>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the >>> SDP 'accept-types' attribute according to the MSRP rules. >>> >>> I think s/MAY/may/. That is, a type must be set, and the type must >>> be only one of those that has been negotiated. >>> >>> >> >> I think this MAY should actually be a MUST, because as you said, a >> types must be said, and this type cannot be anyone, but it MUST be >> one of those negotiated. > > This is already mandated in RFC4975 (as you go on to say...). The only > thing new is the normative requirement for a particular wrapper type. > It might be worth commenting that this is accomplished by putting only > Message/CPIM in accept-types, and all allowed leaf types in > accept-wrapped-types. Ok, we can clarify it. Actually, we do not mention what can go in an accept-wrapped-types, because it was obvious that any type can go in. But it might be worth adding some explicit mention to it. > >> >> I like the "according to the MSRP rules", as a mechanism to indicate >> that we are not mandating something new, but just copying what MSRP >> mandates. >> > > ... in which case it should be stated descriptively, not normatively. Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I think the text ought to say: "According to RFC 4975, the endpoint needs to ...". This is makes it clear, and we do not over-specify. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 5 00:19:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EB421E809C for ; Wed, 5 Sep 2012 00:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCUb9zeKvDma for ; Wed, 5 Sep 2012 00:19:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2251021F84AF for ; Wed, 5 Sep 2012 00:19:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-5c-5046fcf78b42 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6A.6C.11467.7FCF6405; Wed, 5 Sep 2012 09:19:19 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 09:19:18 +0200 Message-ID: <5046FCF6.6060902@ericsson.com> Date: Wed, 5 Sep 2012 09:19:18 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> In-Reply-To: <5046FC24.8030604@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvre73P24BButXKFjM7zzNbrFw4j9W ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjRTdHwWvlihcnGpgaGFfIdDFyckgImEhM /dLBCGGLSVy4t56ti5GLQ0jgFKPEsXcLmSGc1YwSE5b/Ywap4hXQlpj+dxGYzSKgIrF11XoW EJtNwFyideNGdhBbVCBQYt3VP+wQ9YISJ2c+AasREVCSeN68FcxmFpCXWLi5GWyzsEChxI57 D5kgls1hlDh+ZglYM6eAjsSUtw9ZIRpsJS7MuQ7XvP3tHLAjhAQ0JSbfXMo8gVFwFpJ9s5C0 zELSsoCReRWjcG5iZk56uaFealFmcnFxfp5eceomRmCwHtzyW3cH46lzIocYpTlYlMR5uZL2 +wsJpCeWpGanphakFsUXleakFh9iZOLglGpgzMpTENe6vkSPR8D2tU3fgemPq+aWrDocHPPh ZsMuPr1t6zJevQm7Xu2l7lvc3rTi0I9Nv8vXVUyfkqumdXhlkqLqSW4JD3kppUv6t+ZfNnPf OPvKXdnwO/0rGz5tD22fbutws7/qsJTWNH+WrJsd69+arDS+8CDmAP+6DHaJgz/W/fnXZfrw qBJLcUaioRZzUXEiAMlHZOQkAgAA Cc: Simple WG Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:19:23 -0000 In my previous e-mail, please s/5.3/5.4 To be explicit: the MSRP Connection Model is described in Section 5.4 of RFC 4975. /Miguel On 05/09/2012 9:15, Miguel A. Garcia wrote: > Hi Ben, > > Thanks for your comments > > On 04/09/2012 16:26, Ben Campbell wrote: >> (As individual) >> >> Hi, >> >> I agree with Miguel's responses except as noted inline >> >> Thanks! >> >> Ben. >> >> On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" >> wrote: >>> >>>> >>>> --- >>>> >>>> Section 6.1 >>>> >>>> An MSRP switch that uses this fast forwarding procedure MUST >>>> temporarily store the Message-Id of the MSRP message to correlate >>>> the different chunks, as well as it MUST temporarily store the >>>> list of recipients to which the initial chunks were delivered. >>>> >>>> The motivaiton is clear. I think you could add that the storage >>>> can be released when the last chunk is seen. But what happens when >>>> the last chunk is not seen (or delayed)? How temporary is the >>>> storage, and how is it released? >>> >>> Yes, we can add that the temporary storage is released when the >>> last chunk is seen or after a reasonable time passes. >> >> The "how long to wait for a chunk" problem is no different than for >> any other endpoint, is it, other than possibly differences of scale? I >> suggest we refer back to 4975 for this, with the possible note to the >> effect of "This is no different than for any MSRP endpoint that >> receives a chunked message. However, since a conference switch will >> typically participate many sessions at one time, storage management >> may be more critical" > > > I would like to include a reference to the section in RFC 4975 that > discusses this topic. I guess it is Section 5.3, when it discusses what > happens if a transport connection fails. > >> >>>> >>>> Or do we assume that because MSRP uses TCP (or similar) that loss >>>> will always be accompanied by connection failure and so that is >>>> the only trigger needed to abandon temporary storage? >>> >>> Yes, on one side, the assumption is that if a last chunk is not seen >>> is because there has been a transport failure. Since TCP is used, >>> then the TCP connection was broken, and is in the process of being >>> re-established. I am more concerned about what happens if the last >>> chunk is not seen at all, I am not sure the state the MSRP session >>> will be, even if the connection is re-established. >> >> Keep in mind there could be an MSRP relay between the sender and the >> switch, so the transport connection may not be direct. But again, this >> is no different than for any other MSRP endpoint. > > Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975. > >> >>> >>> >>>> --- >>>> >>>> Section 6.1 (trivial nit) >>>> >>>> The SEND request MUST contain a top-level wrapper of type >>>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>> instant message payload MUST be included as payload of the >>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the >>>> SDP 'accept-types' attribute according to the MSRP rules. >>>> >>>> I think s/MAY/may/. That is, a type must be set, and the type must >>>> be only one of those that has been negotiated. >>>> >>>> >>> >>> I think this MAY should actually be a MUST, because as you said, a >>> types must be said, and this type cannot be anyone, but it MUST be >>> one of those negotiated. >> >> This is already mandated in RFC4975 (as you go on to say...). The only >> thing new is the normative requirement for a particular wrapper type. >> It might be worth commenting that this is accomplished by putting only >> Message/CPIM in accept-types, and all allowed leaf types in >> accept-wrapped-types. > > Ok, we can clarify it. Actually, we do not mention what can go in an > accept-wrapped-types, because it was obvious that any type can go in. But > it might be worth adding some explicit mention to it. > >> >>> >>> I like the "according to the MSRP rules", as a mechanism to indicate >>> that we are not mandating something new, but just copying what MSRP >>> mandates. >>> >> >> ... in which case it should be stated descriptively, not normatively. > > Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I > think the text ought to say: "According to RFC 4975, the endpoint needs > to ...". This is makes it clear, and we do not over-specify. > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 5 00:30:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021B221F853E for ; Wed, 5 Sep 2012 00:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-GWSBwH620V for ; Wed, 5 Sep 2012 00:30:25 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A38D21F8518 for ; Wed, 5 Sep 2012 00:30:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-0d-5046ff8f34f5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D2.6E.11467.F8FF6405; Wed, 5 Sep 2012 09:30:23 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 09:30:22 +0200 Message-ID: <5046FF8E.60800@ericsson.com> Date: Wed, 5 Sep 2012 09:30:22 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Kyzivat References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> In-Reply-To: <50461E6D.8040803@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+JvrW7/f7cAg/M9ehbzO0+zW6zYcIDV YuHEf6wOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mta33GIr2MFZ8XneT7YG xl3sXYycHBICJhJzb7yAssUkLtxbz9bFyMUhJHCKUeL0qcvMEM5qRonf508zg1TxCmhK3Lrw mwnEZhFQkVi/sZUVxGYTMJdo3bgRbJKoQKDEuqt/2CHqBSVOznzC0sXIwSEioCExaasaSJhZ wF3iyOUVjCC2sEChxI57D5lASoQEMiW6ZliDhDkFdCS+TvzPClFuK3FhznUWCFteYvvbOWDX CAFdM/nmUuYJjIKzkCybhaRlFpKWBYzMqxiFcxMzc9LLDfVSizKTi4vz8/SKUzcxAoP34Jbf ujsYT50TOcQozcGiJM7LlbTfX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMju/y8jDLL/S13 HkyryPx54an/Npn4CHu9Z90Tv2hc7Z7wf0rre/s1Ut+ZVqzL3rPOdX+8xJTNZctmqLFO+zvd LOcGx6nC14kn/vktU7Re/6CAmz00Knd9UMQRQcOFi3lnhipI1cexhhk1ZsgFKb3a7H9SX/31 0xg7kUtFqjM2PWrdw/bU0FJRiaU4I9FQi7moOBEAOLU8OSwCAAA= Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 07:30:26 -0000 Thank you Paul, I think you are right, under failure circumstances chunks might be sent over different MSRP sessions, if a new session is re-established. So, I believe the only mechanism we have for a permanent deletion of a partially received message is set a timer. In a chat room environment, this means that when this type of failure occurs, the MSRP switch might have sent a number of chunks to the rest of the participants, leaving the total message incomplete at those endpoints. I wonder if the MSRP switch should, in this case, create an abort chunk ("#" flag) to avoid that the rest of the endpoints remain in a strange state. I think so. /Miguel On 04/09/2012 17:29, Paul Kyzivat wrote: > Because a failed TCP connection may be reestablished, and the chunk sent > over the new connection, you can't use connection loss as a trigger for > giving up on incomplete chunked messages. > > The receiver has no firm way to distinguish between a chunk that has > been a chunk that has been lost and one that has simply been delayed. > This has to be dealt with via implementation policies and heuristics. > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 5 06:32:58 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7123721F8433 for ; Wed, 5 Sep 2012 06:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLC4Fl-V70Iy for ; Wed, 5 Sep 2012 06:32:57 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B853A21F84CF for ; Wed, 5 Sep 2012 06:32:56 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-05-504754872bff Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 04.E3.17130.78457405; Wed, 5 Sep 2012 15:32:55 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 15:32:55 +0200 Message-ID: <50475485.70502@ericsson.com> Date: Wed, 5 Sep 2012 15:32:53 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Simple WG References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> In-Reply-To: <5046FCF6.6060902@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+JvrW57iHuAwZ3NFhbzO0+zWyyc+I/V gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mp4v9u9YLNlRW/7eZYGxuW6XYycHBICJhIb 19xig7DFJC7cWw9kc3EICZxilDg5s5UdwlnNKNE09zkjSBWvgKbEz2vrmEFsFgEViV1HzrCA 2GwC5hKtGzeyg9iiAoES667+YYeoFwQa9ASsRkRAXuLF7F9MIDazgJLEvu1HWEEWCAtMYZS4 vK2FEWLbHkaJacuWg93EKaAj8WPfbFaIDluJC3Ous0DY8hLb384Bu0II6KLJN5cyT2AUnIVk 4SwkLbOQtCxgZF7FKJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYrge3/DbYwbjpvtghRmkOFiVx Xj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGDXyuO3ct2f9MjLnY1nwfjX/otW7VT6s F+jYsH57epTuniMXn/bpa03v62Y4e2RussTaZ6e0rS6/jRNhbw78yBW4smje7Vom7wka9V9l ulk+eJwXKPfd4G27IC05pfmg6sW+fSe42t57Cpj//MBaaHL8QNf+nzHX+H7esZ+2QzBVOabg 3gmbYiWW4oxEQy3mouJEAFg3vNMlAgAA Subject: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:32:58 -0000 In relation with the issue of chunked messages, where the MSRP switch does not receive a last chunk due to, e.g., the sender's connection is dropped, I have a proposal and a doubt. Proposal: Once the MSRP switch receives the last chunk of a message, and that chunk is successfully sent to each of the recipients, the MSRP switch MUST discard the temporary storage of MSRP Message-ID and the associated list of recipients. In some occasions, a sender might suffer a transport error condition (such as loss of connectivity) that makes the sending of a message incomplete, e.g., some chunks were received by the MSRP switch, but not all of them. This is a behavior already considered in the core MSRP specification (see RFC 4575 Section 5.4). The problem in the context of a chat room lies with the usage of temporary storage for fast forwarding. In order to prevent attacks related to the exhaustion of temporary storage of chunked messages, on receiving a first chunk of a message, where the MSRP switch is using the fast forward method, the MSRP switch MUST set a timer for controlling the reception of the remaining chunks. This timer can be re-set every time a new chunk of the same message is received. When this timer fires, the MSRP switch MUST considered that the sending of the message was aborted, and MUST delete all the temporary storage pertaining to this message. Now the doubt. If the above condition happens, I would like to know what is best to do with respect the recipients. These are in a strange state, where they have received a number of chunks of a message, but not all the chunks, and they will not receive any more. What the MSRP switch can do: a) Nothing. The recipients have received a number of a chunks of a message; the message is not complete. The MSRP switch will send other messages (perhaps originated by other participants), but this chunked message will remain in the endpoints until the endpoint crashes^H^H^H^H^H^H^Hrecovers from that situation. b) A nice MSRP switch will create a new chunk, as it if were received from the sender, where there won't be any content, but just the abort flag "#". At least this one will have a bigger likelihood of endpoint recovery. I propose to do b). I guess there are no security issues, even if TLS is used, because the TLS connection is ending at the MSRP switch. Can anyone think of other options? Is option b) reasonable? /Miguel On 05/09/2012 9:19, Miguel A. Garcia wrote: > In my previous e-mail, please s/5.3/5.4 > > To be explicit: the MSRP Connection Model is described in Section 5.4 of > RFC 4975. > > /Miguel > > On 05/09/2012 9:15, Miguel A. Garcia wrote: >> Hi Ben, >> >> Thanks for your comments >> >> On 04/09/2012 16:26, Ben Campbell wrote: >>> (As individual) >>> >>> Hi, >>> >>> I agree with Miguel's responses except as noted inline >>> >>> Thanks! >>> >>> Ben. >>> >>> On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" >>> wrote: >>>> >>>>> >>>>> --- >>>>> >>>>> Section 6.1 >>>>> >>>>> An MSRP switch that uses this fast forwarding procedure MUST >>>>> temporarily store the Message-Id of the MSRP message to correlate >>>>> the different chunks, as well as it MUST temporarily store the >>>>> list of recipients to which the initial chunks were delivered. >>>>> >>>>> The motivaiton is clear. I think you could add that the storage >>>>> can be released when the last chunk is seen. But what happens when >>>>> the last chunk is not seen (or delayed)? How temporary is the >>>>> storage, and how is it released? >>>> >>>> Yes, we can add that the temporary storage is released when the >>>> last chunk is seen or after a reasonable time passes. >>> >>> The "how long to wait for a chunk" problem is no different than for >>> any other endpoint, is it, other than possibly differences of scale? I >>> suggest we refer back to 4975 for this, with the possible note to the >>> effect of "This is no different than for any MSRP endpoint that >>> receives a chunked message. However, since a conference switch will >>> typically participate many sessions at one time, storage management >>> may be more critical" >> >> >> I would like to include a reference to the section in RFC 4975 that >> discusses this topic. I guess it is Section 5.3, when it discusses what >> happens if a transport connection fails. >> >>> >>>>> >>>>> Or do we assume that because MSRP uses TCP (or similar) that loss >>>>> will always be accompanied by connection failure and so that is >>>>> the only trigger needed to abandon temporary storage? >>>> >>>> Yes, on one side, the assumption is that if a last chunk is not seen >>>> is because there has been a transport failure. Since TCP is used, >>>> then the TCP connection was broken, and is in the process of being >>>> re-established. I am more concerned about what happens if the last >>>> chunk is not seen at all, I am not sure the state the MSRP session >>>> will be, even if the connection is re-established. >>> >>> Keep in mind there could be an MSRP relay between the sender and the >>> switch, so the transport connection may not be direct. But again, this >>> is no different than for any other MSRP endpoint. >> >> Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975. >> >>> >>>> >>>> >>>>> --- >>>>> >>>>> Section 6.1 (trivial nit) >>>>> >>>>> The SEND request MUST contain a top-level wrapper of type >>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>>> instant message payload MUST be included as payload of the >>>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the >>>>> SDP 'accept-types' attribute according to the MSRP rules. >>>>> >>>>> I think s/MAY/may/. That is, a type must be set, and the type must >>>>> be only one of those that has been negotiated. >>>>> >>>>> >>>> >>>> I think this MAY should actually be a MUST, because as you said, a >>>> types must be said, and this type cannot be anyone, but it MUST be >>>> one of those negotiated. >>> >>> This is already mandated in RFC4975 (as you go on to say...). The only >>> thing new is the normative requirement for a particular wrapper type. >>> It might be worth commenting that this is accomplished by putting only >>> Message/CPIM in accept-types, and all allowed leaf types in >>> accept-wrapped-types. >> >> Ok, we can clarify it. Actually, we do not mention what can go in an >> accept-wrapped-types, because it was obvious that any type can go in. But >> it might be worth adding some explicit mention to it. >> >>> >>>> >>>> I like the "according to the MSRP rules", as a mechanism to indicate >>>> that we are not mandating something new, but just copying what MSRP >>>> mandates. >>>> >>> >>> ... in which case it should be stated descriptively, not normatively. >> >> Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I >> think the text ought to say: "According to RFC 4975, the endpoint needs >> to ...". This is makes it clear, and we do not over-specify. >> >> /Miguel >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Wed Sep 5 06:49:19 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863DD21F85E6 for ; Wed, 5 Sep 2012 06:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMopL5HGQhGE for ; Wed, 5 Sep 2012 06:49:19 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA21821F8546 for ; Wed, 5 Sep 2012 06:49:18 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q85DnETu097541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 08:49:14 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <5046FF8E.60800@ericsson.com> Date: Wed, 5 Sep 2012 08:49:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 13:49:19 -0000 On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" = wrote: > Thank you Paul, >=20 > I think you are right, under failure circumstances chunks might be = sent over different MSRP sessions, if a new session is re-established. >=20 > So, I believe the only mechanism we have for a permanent deletion of a = partially received message is set a timer. >=20 > In a chat room environment, this means that when this type of failure = occurs, the MSRP switch might have sent a number of chunks to the rest = of the participants, leaving the total message incomplete at those = endpoints. I wonder if the MSRP switch should, in this case, create an = abort chunk ("#" flag) to avoid that the rest of the endpoints remain in = a strange state. I think so. I agree. >=20 > /Miguel >=20 >=20 > On 04/09/2012 17:29, Paul Kyzivat wrote: >> Because a failed TCP connection may be reestablished, and the chunk = sent >> over the new connection, you can't use connection loss as a trigger = for >> giving up on incomplete chunked messages. >>=20 >> The receiver has no firm way to distinguish between a chunk that has >> been a chunk that has been lost and one that has simply been delayed. >> This has to be dealt with via implementation policies and heuristics. >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 5 07:35:49 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAD821F855B for ; Wed, 5 Sep 2012 07:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpTmuCw7M5BN for ; Wed, 5 Sep 2012 07:35:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BDCAF21F85A4 for ; Wed, 5 Sep 2012 07:35:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-e4-50476343550d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 57.AD.17130.34367405; Wed, 5 Sep 2012 16:35:47 +0200 (CEST) Received: from [159.107.24.207] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Wed, 5 Sep 2012 16:35:47 +0200 Message-ID: <50476342.8040809@ericsson.com> Date: Wed, 5 Sep 2012 16:35:46 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Simple WG References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> In-Reply-To: <5046FCF6.6060902@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvra5zsnuAwb8JRhbzO0+zWyyc+I/V gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MqYsaaTveCPRMXtWcdYGxj3CncxcnJICJhI 3Ho1nRHCFpO4cG89WxcjF4eQwClGia5V26Gc1YwSe2etYgKp4hXQlvjx4hdYB4uAisS32fNY QGw2AXOJ1o0b2UFsUYFAiXVX/7BD1AtKnJz5BKxGREBe4sXsX2BzmAWUJPZtP8IKskBYoIVR ov3QaiaIbXsYJaYtW84GUsUpoCPxY99sVogOW4kLc66zQNjyEtvfzmEGsYUENCUm31zKPIFR cBaShbOQtMxC0rKAkXkVo3BuYmZOerm5XmpRZnJxcX6eXnHqJkZgwB7c8ttgB+Om+2KHGKU5 WJTEefVU9/sLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYDyzOqC3iUdo2VlBrfKI+veeYT1G EY1d8jyCXEW1n/YsERZUuH1D73vtz6mzxJ7783w+rxvmtnPx6fPWMf1ePYeN6ye3b+M6k5A4 63x3VxojV5lgs1xboPr24K6sYzUF1vFXC5u4s/UVWWI63Zu+Xa/1TXe0OPVxfdTTj34H+bed /rU9KfKqEktxRqKhFnNRcSIAexV9JiYCAAA= Subject: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:35:49 -0000 I am now addressing the issue with accept-types and accept-wrapped-types. There are two affected sections: Section 5.2 discusses the SDP offer/answer when joining a chat room. The text now reads: The conference focus of a chat room MUST include support for a Message/CPIM top-level wrapper for the MSRP messages by setting the 'accept-types' MSRP media line attribute in the SDP offer or answer to include 'Message/CPIM'. The actual payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4575 for details). There is no default wrapped type. Typical wrapped type values can include: text/plain, text/html, image/jpeg, image/png, audio/mp3, etc. The other paragraph is in Section 6.1 (Regular messages), when we want to say that the MSRP SEND request needs to use one of the payloads negotiated in the accept-wrapped-types: The SEND request MUST contain a top-level wrapper of type 'Message/CPIM' according to RFC 3862. The actual instant message payload MUST be included as payload of the 'Message/CPIM' wrapper, and, according to RFC 4575, it needs to be one of those negotiated in the 'accept-wrapped-types' attribute in SDP. Please note that in this last paragraph there is a bug in the current version of the draft. The last sentence incorrectly pointed to the 'accept-types' attribute, rather than the 'accept-wrapped-types'. I believe the proposed text above is now correct. /Miguel On 05/09/2012 9:19, Miguel A. Garcia wrote: >>>> >>>>--- >>>> >>>> >>>> >>>>Section 6.1 (trivial nit) >>>> >>>> >>>> >>>>The SEND request MUST contain a top-level wrapper of type >>>> >>>>'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>> >>>>instant message payload MUST be included as payload of the >>>> >>>>'Message/CPIM' wrapper and MAY be of any type negotiated in the >>>> >>>>SDP 'accept-types' attribute according to the MSRP rules. >>>> >>>> >>>> >>>>I think s/MAY/may/. That is, a type must be set, and the type must >>>> >>>>be only one of those that has been negotiated. >>>> >>>> >>>> >>>> >>> >>> >>> >>>I think this MAY should actually be a MUST, because as you said, a >>> >>>types must be said, and this type cannot be anyone, but it MUST be >>> >>>one of those negotiated. >> >> >> >>This is already mandated in RFC4975 (as you go on to say...). The only >> >>thing new is the normative requirement for a particular wrapper type. >> >>It might be worth commenting that this is accomplished by putting only >> >>Message/CPIM in accept-types, and all allowed leaf types in >> >>accept-wrapped-types. >> >>Ok, we can clarify it. Actually, we do not mention what can go in an >>accept-wrapped-types, because it was obvious that any type can go in. But >>it might be worth adding some explicit mention to it. >> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Wed Sep 5 07:44:00 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D889A21F84D3 for ; Wed, 5 Sep 2012 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsuDvPs4deQO for ; Wed, 5 Sep 2012 07:44:00 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3369121F84C8 for ; Wed, 5 Sep 2012 07:44:00 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id vNyK1j0071wpRvQ55Sk39m; Wed, 05 Sep 2012 14:44:03 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id vSvV1j00j3ZTu2S3eSvVct; Wed, 05 Sep 2012 14:55:29 +0000 Message-ID: <5047652E.3050409@alum.mit.edu> Date: Wed, 05 Sep 2012 10:43:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:44:01 -0000 On 9/5/12 9:49 AM, Ben Campbell wrote: > > On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" wrote: > >> Thank you Paul, >> >> I think you are right, under failure circumstances chunks might be sent over different MSRP sessions, if a new session is re-established. >> >> So, I believe the only mechanism we have for a permanent deletion of a partially received message is set a timer. >> >> In a chat room environment, this means that when this type of failure occurs, the MSRP switch might have sent a number of chunks to the rest of the participants, leaving the total message incomplete at those endpoints. I wonder if the MSRP switch should, in this case, create an abort chunk ("#" flag) to avoid that the rest of the endpoints remain in a strange state. I think so. > > I agree. Will the MSRP switch necessarily *know* that this failure has occurred? The switch is not obligated to receive the complete message before forwarding. It needs to remember incomplete messages, but need not consume buffer space for them. So it may tolerate an incomplete message for a long time. *If* it decides to give up on a message with a missing chunk then I agree that it makes sense for it to tell the downstream recipients as suggested. But they had better not *depend* on this. Thanks, Paul >> >> /Miguel >> >> >> On 04/09/2012 17:29, Paul Kyzivat wrote: >>> Because a failed TCP connection may be reestablished, and the chunk sent >>> over the new connection, you can't use connection loss as a trigger for >>> giving up on incomplete chunked messages. >>> >>> The receiver has no firm way to distinguish between a chunk that has >>> been a chunk that has been lost and one that has simply been delayed. >>> This has to be dealt with via implementation policies and heuristics. >>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain > > From saul@ag-projects.com Wed Sep 5 07:46:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CB221F852C for ; Wed, 5 Sep 2012 07:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdR5zG0eYY00 for ; Wed, 5 Sep 2012 07:46:52 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E204621F84E1 for ; Wed, 5 Sep 2012 07:46:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E308DB014D; Wed, 5 Sep 2012 16:46:48 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 056C6B007E; Wed, 5 Sep 2012 16:46:48 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <50475485.70502@ericsson.com> Date: Wed, 5 Sep 2012 16:46:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0B734345-0245-4158-9F18-4B8372E01480@ag-projects.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50475485.70502@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:46:53 -0000 Hi, On Sep 5, 2012, at 3:32 PM, Miguel A. Garcia wrote: > In relation with the issue of chunked messages, where the MSRP switch = does not receive a last chunk due to, e.g., the sender's connection is = dropped, I have a proposal and a doubt. >=20 > Proposal: >=20 > Once the MSRP switch receives the last chunk of a message, > and that chunk is successfully sent to each of the > recipients, the MSRP switch MUST discard the temporary > storage of MSRP Message-ID and the associated list of > recipients. >=20 >=20 > In some occasions, a sender might suffer a transport error > condition (such as loss of connectivity) that makes the > sending of a message incomplete, e.g., some chunks were > received by the MSRP switch, but not all of them. This is a > behavior already considered in the core MSRP specification > (see RFC 4575 Section > 5.4). The problem in the context of a chat room lies with > the usage of temporary storage for fast forwarding. In order > to prevent attacks related to the exhaustion of temporary > storage of chunked messages, on receiving a first chunk of a > message, where the MSRP switch is using the fast forward > method, the MSRP switch MUST set a timer for controlling the > reception of the remaining chunks. This timer can be re-set > every time a new chunk of the same message is received. When > this timer fires, the MSRP switch MUST considered that the "the MSRP switch MUST consider that the" > sending of the message was aborted, and MUST delete all the > temporary storage pertaining to this message. >=20 > Now the doubt. If the above condition happens, I would like to know = what is best to do with respect the recipients. These are in a strange = state, where they have received a number of chunks of a message, but not = all the chunks, and they will not receive any more. What the MSRP switch = can do: >=20 > a) Nothing. The recipients have received a number of a chunks of a = message; the message is not complete. The MSRP switch will send other = messages (perhaps originated by other participants), but this chunked = message will remain in the endpoints until the endpoint = crashes^H^H^H^H^H^H^Hrecovers from that situation. >=20 > b) A nice MSRP switch will create a new chunk, as it if were received = from the sender, where there won't be any content, but just the abort = flag "#". At least this one will have a bigger likelihood of endpoint = recovery. >=20 > I propose to do b). I guess there are no security issues, even if TLS = is used, because the TLS connection is ending at the MSRP switch. >=20 > Can anyone think of other options? Is option b) reasonable? >=20 I agree with taking the b option approach, it's reasonable. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pkyzivat@alum.mit.edu Wed Sep 5 07:51:53 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0556621F8621 for ; Wed, 5 Sep 2012 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvBkChRbK3zp for ; Wed, 5 Sep 2012 07:51:52 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0CC21F861E for ; Wed, 5 Sep 2012 07:51:51 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id vNS01j00B1HzFnQ53Srvrj; Wed, 05 Sep 2012 14:51:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id vSru1j00C3ZTu2S3aSruyW; Wed, 05 Sep 2012 14:51:54 +0000 Message-ID: <50476706.3080406@alum.mit.edu> Date: Wed, 05 Sep 2012 10:51:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: simple@ietf.org References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> <5047652E.3050409@alum.mit.edu> In-Reply-To: <5047652E.3050409@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 14:51:53 -0000 I just went back and checked the draft text again, and conclude that my comment didn't make much sense. I was thinking the concern was with message buffer space. I see now that it was only concerned with buffering the message id and list of recipients. This is likely to be a low burden, so the server might be willing to buffer a lot of this sort of state. But it will still eventually need to give up on it. And the proposal is valid when it does give up. Thanks, Paul On 9/5/12 10:43 AM, Paul Kyzivat wrote: > On 9/5/12 9:49 AM, Ben Campbell wrote: >> >> On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" >> wrote: >> >>> Thank you Paul, >>> >>> I think you are right, under failure circumstances chunks might be >>> sent over different MSRP sessions, if a new session is re-established. >>> >>> So, I believe the only mechanism we have for a permanent deletion of >>> a partially received message is set a timer. >>> >>> In a chat room environment, this means that when this type of failure >>> occurs, the MSRP switch might have sent a number of chunks to the >>> rest of the participants, leaving the total message incomplete at >>> those endpoints. I wonder if the MSRP switch should, in this case, >>> create an abort chunk ("#" flag) to avoid that the rest of the >>> endpoints remain in a strange state. I think so. >> >> I agree. > > Will the MSRP switch necessarily *know* that this failure has occurred? > > The switch is not obligated to receive the complete message before > forwarding. It needs to remember incomplete messages, but need not > consume buffer space for them. So it may tolerate an incomplete message > for a long time. > > *If* it decides to give up on a message with a missing chunk then I > agree that it makes sense for it to tell the downstream recipients as > suggested. But they had better not *depend* on this. > > Thanks, > Paul > >>> >>> /Miguel >>> >>> >>> On 04/09/2012 17:29, Paul Kyzivat wrote: >>>> Because a failed TCP connection may be reestablished, and the chunk >>>> sent >>>> over the new connection, you can't use connection loss as a trigger for >>>> giving up on incomplete chunked messages. >>>> >>>> The receiver has no firm way to distinguish between a chunk that has >>>> been a chunk that has been lost and one that has simply been delayed. >>>> This has to be dealt with via implementation policies and heuristics. >>>> >>> >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Wed Sep 5 09:10:30 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCF821F86A8 for ; Wed, 5 Sep 2012 09:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycyggfKA6Wce for ; Wed, 5 Sep 2012 09:10:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACEF21F869E for ; Wed, 5 Sep 2012 09:10:29 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q85GAQXX012527 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 11:10:26 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <5047652E.3050409@alum.mit.edu> Date: Wed, 5 Sep 2012 11:10:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3235228C-2D59-4F44-9B6E-659BD9838B5F@nostrum.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> <5047652E.3050409@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:10:30 -0000 On Sep 5, 2012, at 9:43 AM, Paul Kyzivat wrote: > On 9/5/12 9:49 AM, Ben Campbell wrote: >>=20 >> On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" = wrote: >>=20 >>> Thank you Paul, >>>=20 >>> I think you are right, under failure circumstances chunks might be = sent over different MSRP sessions, if a new session is re-established. >>>=20 >>> So, I believe the only mechanism we have for a permanent deletion of = a partially received message is set a timer. >>>=20 >>> In a chat room environment, this means that when this type of = failure occurs, the MSRP switch might have sent a number of chunks to = the rest of the participants, leaving the total message incomplete at = those endpoints. I wonder if the MSRP switch should, in this case, = create an abort chunk ("#" flag) to avoid that the rest of the endpoints = remain in a strange state. I think so. >>=20 >> I agree. >=20 > Will the MSRP switch necessarily *know* that this failure has = occurred? >=20 > The switch is not obligated to receive the complete message before = forwarding. It needs to remember incomplete messages, but need not = consume buffer space for them. So it may tolerate an incomplete message = for a long time. >=20 > *If* it decides to give up on a message with a missing chunk then I = agree that it makes sense for it to tell the downstream recipients as = suggested. But they had better not *depend* on this. Agreed. The final recipients must be able to deal with missing chunks, = regardless of what the switch does. On reflection, it doesn't seem like = the switch has to keep all that much state if it's doing fast = forwarding, i.e. it doesn't to store chunks for reassembly like the = final recipient does. So I'd almost see this is a "MAY discard the = message-id after some reasonable period of time, based on local policy." I first thought we needed the abort chunk--but it's really just an = optimization. I wonder if it's worth it to introduce a need to originate = content. Are there situations where it could do harm? S/MIME signed = content might be one, but I guess if all the chunks don't make it, the = signature is toast anyway. >=20 > Thanks, > Paul >=20 >>>=20 >>> /Miguel >>>=20 >>>=20 >>> On 04/09/2012 17:29, Paul Kyzivat wrote: >>>> Because a failed TCP connection may be reestablished, and the chunk = sent >>>> over the new connection, you can't use connection loss as a trigger = for >>>> giving up on incomplete chunked messages. >>>>=20 >>>> The receiver has no firm way to distinguish between a chunk that = has >>>> been a chunk that has been lost and one that has simply been = delayed. >>>> This has to be dealt with via implementation policies and = heuristics. >>>>=20 >>>=20 >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>=20 >>=20 >=20 From ben@nostrum.com Wed Sep 5 09:12:21 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBD521F857D for ; Wed, 5 Sep 2012 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJ+0vF-tEYFR for ; Wed, 5 Sep 2012 09:12:21 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C9B7C21F86AF for ; Wed, 5 Sep 2012 09:12:20 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q85GCHdO012712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 11:12:17 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50476706.3080406@alum.mit.edu> Date: Wed, 5 Sep 2012 11:12:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <23154E07-710B-4D46-A08C-0F74EB459F89@nostrum.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> <5047652E.3050409@alum.mit.edu> <50476706.3080406@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 16:12:21 -0000 On Sep 5, 2012, at 9:51 AM, Paul Kyzivat wrote: > I just went back and checked the draft text again, and conclude that = my comment didn't make much sense. I was thinking the concern was with = message buffer space. I see now that it was only concerned with = buffering the message id and list of recipients. This is likely to be a = low burden, so the server might be willing to buffer a lot of this sort = of state. But it will still eventually need to give up on it. And the = proposal is valid when it does give up. >=20 I agree with the comment you just withdrew :-) > Thanks, > Paul >=20 > On 9/5/12 10:43 AM, Paul Kyzivat wrote: >> On 9/5/12 9:49 AM, Ben Campbell wrote: >>>=20 >>> On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" >>> wrote: >>>=20 >>>> Thank you Paul, >>>>=20 >>>> I think you are right, under failure circumstances chunks might be >>>> sent over different MSRP sessions, if a new session is = re-established. >>>>=20 >>>> So, I believe the only mechanism we have for a permanent deletion = of >>>> a partially received message is set a timer. >>>>=20 >>>> In a chat room environment, this means that when this type of = failure >>>> occurs, the MSRP switch might have sent a number of chunks to the >>>> rest of the participants, leaving the total message incomplete at >>>> those endpoints. I wonder if the MSRP switch should, in this case, >>>> create an abort chunk ("#" flag) to avoid that the rest of the >>>> endpoints remain in a strange state. I think so. >>>=20 >>> I agree. >>=20 >> Will the MSRP switch necessarily *know* that this failure has = occurred? >>=20 >> The switch is not obligated to receive the complete message before >> forwarding. It needs to remember incomplete messages, but need not >> consume buffer space for them. So it may tolerate an incomplete = message >> for a long time. >>=20 >> *If* it decides to give up on a message with a missing chunk then I >> agree that it makes sense for it to tell the downstream recipients as >> suggested. But they had better not *depend* on this. >>=20 >> Thanks, >> Paul >>=20 >>>>=20 >>>> /Miguel >>>>=20 >>>>=20 >>>> On 04/09/2012 17:29, Paul Kyzivat wrote: >>>>> Because a failed TCP connection may be reestablished, and the = chunk >>>>> sent >>>>> over the new connection, you can't use connection loss as a = trigger for >>>>> giving up on incomplete chunked messages. >>>>>=20 >>>>> The receiver has no firm way to distinguish between a chunk that = has >>>>> been a chunk that has been lost and one that has simply been = delayed. >>>>> This has to be dealt with via implementation policies and = heuristics. >>>>>=20 >>>>=20 >>>> -- >>>> Miguel A. Garcia >>>> +34-91-339-3608 >>>> Ericsson Spain >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Wed Sep 5 11:54:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5966021F86BD for ; Wed, 5 Sep 2012 11:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fcv+jPaemg7J for ; Wed, 5 Sep 2012 11:54:25 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id 21EAF21F86BB for ; Wed, 5 Sep 2012 11:54:24 -0700 (PDT) Received: from [10.12.11.64] ([10.12.11.64]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q85IsGaN041453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 13:54:17 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50475485.70502@ericsson.com> Date: Wed, 5 Sep 2012 13:54:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9E77A625-F55A-4609-849F-3CD22D3B9F1E@estacado.net> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50475485.70502@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Cc: Simple WG Subject: Re: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 18:54:26 -0000 On Sep 5, 2012, at 8:32 AM, Miguel A. Garcia = wrote: > In relation with the issue of chunked messages, where the MSRP switch = does not receive a last chunk due to, e.g., the sender's connection is = dropped, I have a proposal and a doubt. >=20 > Proposal: >=20 > Once the MSRP switch receives the last chunk of a message, > and that chunk is successfully sent to each of the > recipients, the MSRP switch MUST discard the temporary > storage of MSRP Message-ID and the associated list of > recipients. >=20 >=20 > In some occasions, a sender might suffer a transport error > condition (such as loss of connectivity) that makes the > sending of a message incomplete, e.g., some chunks were > received by the MSRP switch, but not all of them. It's not limited to transport failures. For example, the sender could = lose power before completing the message. > This is a > behavior already considered in the core MSRP specification > (see RFC 4575 Section > 5.4). The problem in the context of a chat room lies with > the usage of temporary storage for fast forwarding. Seems like it would be even worse if you weren't doing fast forwarding. = Then the switch would be saving the chunk contents for reassembly, = wouldn't it? > In order > to prevent attacks related to the exhaustion of temporary > storage of chunked messages, on receiving a first chunk of a > message, where the MSRP switch is using the fast forward > method, the MSRP switch MUST set a timer for controlling the > reception of the remaining chunks. This timer can be re-set > every time a new chunk of the same message is received. When > this timer fires, the MSRP switch MUST considered that the > sending of the message was aborted, and MUST delete all the > temporary storage pertaining to this message. >=20 > Now the doubt. If the above condition happens, I would like to know = what is best to do with respect the recipients. These are in a strange = state, where they have received a number of chunks of a message, but not = all the chunks, and they will not receive any more. What the MSRP switch = can do: >=20 > a) Nothing. The recipients have received a number of a chunks of a = message; the message is not complete. The MSRP switch will send other = messages (perhaps originated by other participants), but this chunked = message will remain in the endpoints until the endpoint = crashes^H^H^H^H^H^H^Hrecovers from that situation. >=20 > b) A nice MSRP switch will create a new chunk, as it if were received = from the sender, where there won't be any content, but just the abort = flag "#". At least this one will have a bigger likelihood of endpoint = recovery. >=20 > I propose to do b). I guess there are no security issues, even if TLS = is used, because the TLS connection is ending at the MSRP switch. >=20 > Can anyone think of other options? Is option b) reasonable? >=20 Repeating a comment from a separate thread: On reflection, I'm not sure we need to be aggressive with the normative = language here. The receiving endpoints already have to be able to deal = with missing chunks. We are talking about optimizations here, not = interop-critical behavior. I would lean towards making it clear that a = switch doesn't have to keep the message-id and recipients around = forever, and allow it to send a cancelation chunk if it wants to, but = not require it. Specifically, something to the effect of the following: 1) The switch MAY discard the message state if it receives no chunks = within some reasonable time. The specific timeout value is a matter of = local policy, but SHOULD NOT be too short. For example, a time interval = on the order of a normal TCP timeout (i.e. around 9 minutes) would be = reasonable. A timeout on the order of a few seconds would not. 2) If a timeout occurs, or some other error occurs that prevents all = chunks from arriving at the switch, the switch MAY choose to send a = cancelation chunk. This is an optimization, since MSRP endpoints need to = be able to handle incomplete messages anyway. > /Miguel >=20 >=20 > On 05/09/2012 9:19, Miguel A. Garcia wrote: >> In my previous e-mail, please s/5.3/5.4 >>=20 >> To be explicit: the MSRP Connection Model is described in Section 5.4 = of >> RFC 4975. >>=20 >> /Miguel >>=20 >> On 05/09/2012 9:15, Miguel A. Garcia wrote: >>> Hi Ben, >>>=20 >>> Thanks for your comments >>>=20 >>> On 04/09/2012 16:26, Ben Campbell wrote: >>>> (As individual) >>>>=20 >>>> Hi, >>>>=20 >>>> I agree with Miguel's responses except as noted inline >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>> On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" >>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> Section 6.1 >>>>>>=20 >>>>>> An MSRP switch that uses this fast forwarding procedure MUST >>>>>> temporarily store the Message-Id of the MSRP message to correlate >>>>>> the different chunks, as well as it MUST temporarily store the >>>>>> list of recipients to which the initial chunks were delivered. >>>>>>=20 >>>>>> The motivaiton is clear. I think you could add that the storage >>>>>> can be released when the last chunk is seen. But what happens = when >>>>>> the last chunk is not seen (or delayed)? How temporary is the >>>>>> storage, and how is it released? >>>>>=20 >>>>> Yes, we can add that the temporary storage is released when the >>>>> last chunk is seen or after a reasonable time passes. >>>>=20 >>>> The "how long to wait for a chunk" problem is no different than for >>>> any other endpoint, is it, other than possibly differences of = scale? I >>>> suggest we refer back to 4975 for this, with the possible note to = the >>>> effect of "This is no different than for any MSRP endpoint that >>>> receives a chunked message. However, since a conference switch will >>>> typically participate many sessions at one time, storage management >>>> may be more critical" >>>=20 >>>=20 >>> I would like to include a reference to the section in RFC 4975 that >>> discusses this topic. I guess it is Section 5.3, when it discusses = what >>> happens if a transport connection fails. >>>=20 >>>>=20 >>>>>>=20 >>>>>> Or do we assume that because MSRP uses TCP (or similar) that loss >>>>>> will always be accompanied by connection failure and so that is >>>>>> the only trigger needed to abandon temporary storage? >>>>>=20 >>>>> Yes, on one side, the assumption is that if a last chunk is not = seen >>>>> is because there has been a transport failure. Since TCP is used, >>>>> then the TCP connection was broken, and is in the process of being >>>>> re-established. I am more concerned about what happens if the last >>>>> chunk is not seen at all, I am not sure the state the MSRP session >>>>> will be, even if the connection is re-established. >>>>=20 >>>> Keep in mind there could be an MSRP relay between the sender and = the >>>> switch, so the transport connection may not be direct. But again, = this >>>> is no different than for any other MSRP endpoint. >>>=20 >>> Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975. >>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>> --- >>>>>>=20 >>>>>> Section 6.1 (trivial nit) >>>>>>=20 >>>>>> The SEND request MUST contain a top-level wrapper of type >>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>>>> instant message payload MUST be included as payload of the >>>>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the >>>>>> SDP 'accept-types' attribute according to the MSRP rules. >>>>>>=20 >>>>>> I think s/MAY/may/. That is, a type must be set, and the type = must >>>>>> be only one of those that has been negotiated. >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> I think this MAY should actually be a MUST, because as you said, a >>>>> types must be said, and this type cannot be anyone, but it MUST be >>>>> one of those negotiated. >>>>=20 >>>> This is already mandated in RFC4975 (as you go on to say...). The = only >>>> thing new is the normative requirement for a particular wrapper = type. >>>> It might be worth commenting that this is accomplished by putting = only >>>> Message/CPIM in accept-types, and all allowed leaf types in >>>> accept-wrapped-types. >>>=20 >>> Ok, we can clarify it. Actually, we do not mention what can go in an >>> accept-wrapped-types, because it was obvious that any type can go = in. But >>> it might be worth adding some explicit mention to it. >>>=20 >>>>=20 >>>>>=20 >>>>> I like the "according to the MSRP rules", as a mechanism to = indicate >>>>> that we are not mandating something new, but just copying what = MSRP >>>>> mandates. >>>>>=20 >>>>=20 >>>> ... in which case it should be stated descriptively, not = normatively. >>>=20 >>> Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I >>> think the text ought to say: "According to RFC 4975, the endpoint = needs >>> to ...". This is makes it clear, and we do not over-specify. >>>=20 >>> /Miguel >>>=20 >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@estacado.net Wed Sep 5 12:05:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C00E21F86DB for ; Wed, 5 Sep 2012 12:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PCbvtbGAL8w for ; Wed, 5 Sep 2012 12:05:35 -0700 (PDT) Received: from estacado.net (vicuna.estacado.net [4.30.77.35]) by ietfa.amsl.com (Postfix) with ESMTP id A814121F865B for ; Wed, 5 Sep 2012 12:05:35 -0700 (PDT) Received: from [10.12.11.64] ([10.12.11.64]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id q85J5XaQ043061 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Sep 2012 14:05:33 -0500 (CDT) (envelope-from ben@estacado.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50476342.8040809@ericsson.com> Date: Wed, 5 Sep 2012 14:05:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Cc: Simple WG Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:05:36 -0000 On Sep 5, 2012, at 9:35 AM, Miguel A. Garcia = wrote: > I am now addressing the issue with accept-types and = accept-wrapped-types. >=20 > There are two affected sections: >=20 > Section 5.2 discusses the SDP offer/answer when joining a chat room. = The text now reads: >=20 > The conference focus of a chat room MUST include support for > a Message/CPIM top-level > wrapper for the MSRP messages by setting the 'accept-types' > MSRP media line attribute in the SDP > offer or answer to include 'Message/CPIM'. _only_ Message/CPIM, right? Or can other media types be included at the = root? > The > actual payload type is negotiated in the > 'accept-wrapped-types' attribute in SDP (see target=3D"RFC4575">RFC 4575 for details). There is no > default wrapped type. Typical wrapped type values can > include: text/plain, text/html, image/jpeg, image/png, > audio/mp3, etc. Assuming you mean 4975, it looks good. We could mention the use of "*", = but I think that's already covered by the reference, and we don't want = to restate too much here. >=20 >=20 > The other paragraph is in Section 6.1 (Regular messages), when we want = to say that the MSRP SEND request needs to use one of the payloads = negotiated in the accept-wrapped-types: >=20 > The SEND request MUST contain a top-level wrapper of type > 'Message/CPIM' according to RFC > 3862. The actual instant message payload MUST be > included as payload of the 'Message/CPIM' wrapper, and, > according to RFC 4575, it > needs to be one of those negotiated in the > 'accept-wrapped-types' attribute in SDP. >=20 > Please note that in this last paragraph there is a bug in the current = version of the draft. The last sentence incorrectly pointed to the = 'accept-types' attribute, rather than the 'accept-wrapped-types'. I = believe the proposed text above is now correct. Looks good, again assuming you mean 4975. >=20 > /Miguel >=20 >=20 > On 05/09/2012 9:19, Miguel A. Garcia wrote: >>>>> >>>>--- >>>>> >>>> >>>>> >>>>Section 6.1 (trivial nit) >>>>> >>>> >>>>> >>>>The SEND request MUST contain a top-level wrapper of type >>>>> >>>>'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>>> >>>>instant message payload MUST be included as payload of the >>>>> >>>>'Message/CPIM' wrapper and MAY be of any type negotiated in = the >>>>> >>>>SDP 'accept-types' attribute according to the MSRP rules. >>>>> >>>> >>>>> >>>>I think s/MAY/may/. That is, a type must be set, and the type = must >>>>> >>>>be only one of those that has been negotiated. >>>>> >>>> >>>>> >>>> >>>> >>> >>>> >>>I think this MAY should actually be a MUST, because as you said, = a >>>> >>>types must be said, and this type cannot be anyone, but it MUST = be >>>> >>>one of those negotiated. >>> >> >>> >>This is already mandated in RFC4975 (as you go on to say...). The = only >>> >>thing new is the normative requirement for a particular wrapper = type. >>> >>It might be worth commenting that this is accomplished by putting = only >>> >>Message/CPIM in accept-types, and all allowed leaf types in >>> >>accept-wrapped-types. >>>=20 >>> Ok, we can clarify it. Actually, we do not mention what can go in an >>> accept-wrapped-types, because it was obvious that any type can go = in. But >>> it might be worth adding some explicit mention to it. >>>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From adam@nostrum.com Wed Sep 5 12:09:45 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D818721F86CF for ; Wed, 5 Sep 2012 12:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5Vv8UTw5Tg3 for ; Wed, 5 Sep 2012 12:09:45 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A76721F86E3 for ; Wed, 5 Sep 2012 12:09:35 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q85J9Wrs030406 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 14:09:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5047A36C.1030609@nostrum.com> Date: Wed, 05 Sep 2012 14:09:32 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50475485.70502@ericsson.com> <9E77A625-F55A-4609-849F-3CD22D3B9F1E@estacado.net> In-Reply-To: <9E77A625-F55A-4609-849F-3CD22D3B9F1E@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2012 19:09:46 -0000 On 9/5/12 1:54 PM, Ben Campbell wrote: > On reflection, I'm not sure we need to be aggressive with the normative language here. The receiving endpoints already have to be able to deal with missing chunks. We are talking about optimizations here, not interop-critical behavior. I would lean towards making it clear that a switch doesn't have to keep the message-id and recipients around forever, and allow it to send a cancelation chunk if it wants to, but not require it. Specifically, something to the effect of the following: > > 1) The switch MAY discard the message state if it receives no chunks within some reasonable time. The specific timeout value is a matter of local policy, but SHOULD NOT be too short. For example, a time interval on the order of a normal TCP timeout (i.e. around 9 minutes) would be reasonable. A timeout on the order of a few seconds would not. > > 2) If a timeout occurs, or some other error occurs that prevents all chunks from arriving at the switch, the switch MAY choose to send a cancelation chunk. This is an optimization, since MSRP endpoints need to be able to handle incomplete messages anyway. I agree with this suggestion. I think making #2 optional makes sense, since it alleviates any of Miguel's concerns that sending the cancellation chunk might constitute an undue burden on the switch, while leaving open the ability of the switch to indicate that no further chunks will be arriving in a message. I also think leaving the exact implementation details of #1 at the discretion of the switch makes sense. For example -- it might be perfectly fine for the switch to keep the state around for as long as the session exists, possibly removing state bindings on a LRU-basis (so as to avoid excessive state utilization). For some architectures, this might make more sense than running strict timers. I also like the suggestion that any such state needs to stay around for at least as long as TCP retransmits information. It guarantees that the relay won't needlessly prevent delivery of a message by giving the underlying transport time to do everything it can. /a From miguel.a.garcia@ericsson.com Thu Sep 6 03:22:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EA021F84DF for ; Thu, 6 Sep 2012 03:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Uc0km1+lY9L for ; Thu, 6 Sep 2012 03:22:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CE82B21F84DD for ; Thu, 6 Sep 2012 03:22:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-ab-5048797ca4d3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 23.E6.11467.C7978405; Thu, 6 Sep 2012 12:22:52 +0200 (CEST) Received: from [159.107.24.196] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Thu, 6 Sep 2012 12:22:51 +0200 Message-ID: <50487977.5040401@ericsson.com> Date: Thu, 6 Sep 2012 12:22:47 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <50461E6D.8040803@alum.mit.edu> <5046FF8E.60800@ericsson.com> <5047652E.3050409@alum.mit.edu> <3235228C-2D59-4F44-9B6E-659BD9838B5F@nostrum.com> In-Reply-To: <3235228C-2D59-4F44-9B6E-659BD9838B5F@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+JvrW5NpUeAwY9f0hbzO0+zW6zYcIDV YuHEf6wOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4MuZ8qCh4I1Mxc/1b5gbG 12JdjJwcEgImEjuXv2aCsMUkLtxbz9bFyMUhJHCKUeJmwx5GCGc1o8TRJxPBqngFtCVW725m B7FZBFQk3pxrBbPZBMwlWjduBLNFBQIl1l39ww5RLyhxcuYTFhBbREBJ4nnzViCbg4NZIEDi 7ydlkLCwQKHEjnsPmSB29TJJfHszmw0kwSlgL3F8/1awvcwCthIX5lxngbDlJba/ncMMYgsJ aEpMvrmUeQKj4Cwk62YhaZmFpGUBI/MqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzA8D245bfu DsZT50QOMUpzsCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOj6zLvpfbVXwNbT ByYzpievXxT+NHW2x8G+XVGT5OY6iCnN3vJjr6p86Qob6eU9DbXcjmVHxWVK/+/g+TxX5XbZ yldcJh3WGWcO+VpembH2tW+O2Ma/d+78/v2v+ZbQqrOhezZcnCCtIjvxQwvTOZGlB+XjHy0N +nOwm38H908NG6+1d+pCp0xRYinOSDTUYi4qTgQApaByky0CAAA= Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 10:22:55 -0000 A couple of comments below. On 05/09/2012 18:10, Ben Campbell wrote: > > On Sep 5, 2012, at 9:43 AM, Paul Kyzivat > wrote: > >> On 9/5/12 9:49 AM, Ben Campbell wrote: >>> >>> On Sep 5, 2012, at 2:30 AM, "Miguel A. Garcia" >>> wrote: >>> >>>> Thank you Paul, >>>> >>>> I think you are right, under failure circumstances chunks might >>>> be sent over different MSRP sessions, if a new session is >>>> re-established. >>>> >>>> So, I believe the only mechanism we have for a permanent >>>> deletion of a partially received message is set a timer. >>>> >>>> In a chat room environment, this means that when this type of >>>> failure occurs, the MSRP switch might have sent a number of >>>> chunks to the rest of the participants, leaving the total >>>> message incomplete at those endpoints. I wonder if the MSRP >>>> switch should, in this case, create an abort chunk ("#" flag) to >>>> avoid that the rest of the endpoints remain in a strange state. >>>> I think so. >>> >>> I agree. >> >> Will the MSRP switch necessarily *know* that this failure has >> occurred? The only way for the MSRP switch to detect this failure is through a timer. >> >> The switch is not obligated to receive the complete message before >> forwarding. It needs to remember incomplete messages, but need not >> consume buffer space for them. So it may tolerate an incomplete >> message for a long time. >> >> *If* it decides to give up on a message with a missing chunk then I >> agree that it makes sense for it to tell the downstream recipients >> as suggested. But they had better not *depend* on this. > > Agreed. The final recipients must be able to deal with missing chunks, > regardless of what the switch does. The final recipients should be already be able to deal with missing chunks with regular MSRP (outside the chat context). An endpoint might be receiving MSRP chunks through a relay. The sender's connection with the relay goes down; the recipient should be able to deal with this case. > On reflection, it doesn't seem > like the switch has to keep all that much state if it's doing fast > forwarding, i.e. it doesn't to store chunks for reassembly like the > final recipient does. So I'd almost see this is a "MAY discard the > message-id after some reasonable period of time, based on local > policy." Sounds reasonable. > > I first thought we needed the abort chunk--but it's really just an > optimization. I wonder if it's worth it to introduce a need to > originate content. Are there situations where it could do harm? S/MIME > signed content might be one, but I guess if all the chunks don't make > it, the signature is toast anyway. Yeah, provoking an abort seems to be an optimization that the MSRP switch will do to the endpoints. Somehow I am leaning towards adding a "MAY" send an abort if this condition is detected. /Miguel > > >> >> Thanks, Paul >> >>>> >>>> /Miguel >>>> >>>> >>>> On 04/09/2012 17:29, Paul Kyzivat wrote: >>>>> Because a failed TCP connection may be reestablished, and the >>>>> chunk sent over the new connection, you can't use connection >>>>> loss as a trigger for giving up on incomplete chunked >>>>> messages. >>>>> >>>>> The receiver has no firm way to distinguish between a chunk >>>>> that has been a chunk that has been lost and one that has >>>>> simply been delayed. This has to be dealt with via >>>>> implementation policies and heuristics. >>>>> >>>> >>>> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >>> >>> >> > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Sep 6 03:27:55 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC56221F84F1 for ; Thu, 6 Sep 2012 03:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkcjjPm9Vbv9 for ; Thu, 6 Sep 2012 03:27:55 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A22F521F849A for ; Thu, 6 Sep 2012 03:27:54 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-a5-50487aa959d2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 57.97.11467.9AA78405; Thu, 6 Sep 2012 12:27:53 +0200 (CEST) Received: from [159.107.24.196] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Thu, 6 Sep 2012 12:27:53 +0200 Message-ID: <50487AA8.80708@ericsson.com> Date: Thu, 6 Sep 2012 12:27:52 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50475485.70502@ericsson.com> <0B734345-0245-4158-9F18-4B8372E01480@ag-projects.com> In-Reply-To: <0B734345-0245-4158-9F18-4B8372E01480@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre7KKo8Ag4v3jS2W7lvDYrFw4j9W ByaPlv5JLB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYdHoyY8Er8YpLG+8wNzCeEOpi5OSQEDCR 2P9qIguELSZx4d56ti5GLg4hgVOMEnv+L2UDSQgJrGaUONwbA2LzCmhKvJ+7GqyBRUBFYv+O 3YwgNpuAuUTrxo3sILaoQKDEuqt/2CHqBSVOznwCVi8i4CKxbMNOVhCbWUBeYuHmZkaQZcIC Mxgllnf1QG2eyCTx/8hLsKmcAs4SrQ1fmCE6bCUuzLnOAtPdvHU2M8R1mhKTby5lnsAoOAvJ wllIWmYhaVnAyLyKUTg3MTMnvdxQL7UoM7m4OD9Przh1EyMwXA9u+a27g/HUOZFDjNIcLEri vFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MApe8Grb/r3/+MKQee+3vNY+GHhz7ZUs peW3/YOWO/X3T+xXemLw/AaPr+82w5OP6varnMpco5XCv/DC1JvGp+62+J/2NtKt93WNXfRi 3a6VsbtTtsu/qMtZ3bJGs+f+Ac4N6y7tVZJOVK3bkuw0Q1jy5SsOg769ynYXg3uii73DLt6/ 8PuVf4QSS3FGoqEWc1FxIgBo8gMtJQIAAA== Cc: Simple WG Subject: Re: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 10:27:55 -0000 Thank you Saúl. /Miguel On 05/09/2012 16:46, Saúl Ibarra Corretgé wrote: > Hi, > > On Sep 5, 2012, at 3:32 PM, Miguel A. Garcia wrote: > >> In relation with the issue of chunked messages, where the MSRP switch does not receive a last chunk due to, e.g., the sender's connection is dropped, I have a proposal and a doubt. >> >> Proposal: >> >> Once the MSRP switch receives the last chunk of a message, >> and that chunk is successfully sent to each of the >> recipients, the MSRP switch MUST discard the temporary >> storage of MSRP Message-ID and the associated list of >> recipients. >> >> >> In some occasions, a sender might suffer a transport error >> condition (such as loss of connectivity) that makes the >> sending of a message incomplete, e.g., some chunks were >> received by the MSRP switch, but not all of them. This is a >> behavior already considered in the core MSRP specification >> (see RFC 4575 Section >> 5.4). The problem in the context of a chat room lies with >> the usage of temporary storage for fast forwarding. In order >> to prevent attacks related to the exhaustion of temporary >> storage of chunked messages, on receiving a first chunk of a >> message, where the MSRP switch is using the fast forward >> method, the MSRP switch MUST set a timer for controlling the >> reception of the remaining chunks. This timer can be re-set >> every time a new chunk of the same message is received. When >> this timer fires, the MSRP switch MUST considered that the > > "the MSRP switch MUST consider that the" > >> sending of the message was aborted, and MUST delete all the >> temporary storage pertaining to this message. >> >> Now the doubt. If the above condition happens, I would like to know what is best to do with respect the recipients. These are in a strange state, where they have received a number of chunks of a message, but not all the chunks, and they will not receive any more. What the MSRP switch can do: >> >> a) Nothing. The recipients have received a number of a chunks of a message; the message is not complete. The MSRP switch will send other messages (perhaps originated by other participants), but this chunked message will remain in the endpoints until the endpoint crashes^H^H^H^H^H^H^Hrecovers from that situation. >> >> b) A nice MSRP switch will create a new chunk, as it if were received from the sender, where there won't be any content, but just the abort flag "#". At least this one will have a bigger likelihood of endpoint recovery. >> >> I propose to do b). I guess there are no security issues, even if TLS is used, because the TLS connection is ending at the MSRP switch. >> >> Can anyone think of other options? Is option b) reasonable? >> > > I agree with taking the b option approach, it's reasonable. > > > Regards, > > -- > Saúl Ibarra Corretgé > AG Projects > > > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Sep 6 03:45:29 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D075521F861D for ; Thu, 6 Sep 2012 03:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.232 X-Spam-Level: X-Spam-Status: No, score=-6.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RQOXLMJdyq8 for ; Thu, 6 Sep 2012 03:45:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA521F84FA for ; Thu, 6 Sep 2012 03:45:28 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-70-50487ec692cf Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.E5.25676.6CE78405; Thu, 6 Sep 2012 12:45:26 +0200 (CEST) Received: from [159.107.24.196] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Thu, 6 Sep 2012 12:45:25 +0200 Message-ID: <50487EC4.3080703@ericsson.com> Date: Thu, 6 Sep 2012 12:45:24 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50475485.70502@ericsson.com> <9E77A625-F55A-4609-849F-3CD22D3B9F1E@estacado.net> In-Reply-To: <9E77A625-F55A-4609-849F-3CD22D3B9F1E@estacado.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM+Jvre6xOo8Ag19rlSyaH/5is1g48R+r A5PH46+zWD2WLPnJFMAUxWWTkpqTWZZapG+XwJUx420Da8GcgIq1r88yNjAucuhi5OSQEDCR mDXlGyuELSZx4d56ti5GLg4hgVOMEuf+tjBBOKsZJS5+6QSr4hXQlliy4S4LiM0ioCJx6MJ2 dhCbTcBconXjRjBbVCBQYt3VP+wQ9YISJ2c+AasXEVCWWLH/PFicWUBeYuHmZkaQBcICMxgl lnf1QK3uY5KYtu4G2DZOAQeJM5/+sUB02EpcmHOdBaZ7+9s5zCC2kICmxOSbS5knMArOQrJw FpKWWUhaFjAyr2IUzk3MzEkvN9JLLcpMLi7Oz9MrTt3ECAzYg1t+q+5gvHNO5BCjNAeLkjiv 9dY9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYRa9lSUwyZr60p3z3cw/hC/+j7gTefvUu 6KC66X9lxRidOSo/nk4MOLh1pdXnk14bdC2trp6Xe+zG7HXw1qq5uuYX32++vPHRq6U1vdZm xyae1Xo0b8brrY77a+d9MVZlLvjb+b32/4e8VJOofqaUWYtzDyZP1eH0frxtbk7QKc29a1Km 6HLNz1FiKc5INNRiLipOBACovE8mJgIAAA== Cc: Simple WG Subject: Re: [Simple] Timer for chunked messaging. Was [Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 10:45:30 -0000 Hi Ben: Some inline comments. On 05/09/2012 20:54, Ben Campbell wrote: > > On Sep 5, 2012, at 8:32 AM, Miguel A. Garcia > wrote: > >> In relation with the issue of chunked messages, where the MSRP >> switch does not receive a last chunk due to, e.g., the sender's >> connection is dropped, I have a proposal and a doubt. >> >> Proposal: >> >> Once the MSRP switch receives the last chunk of a message, and that >> chunk is successfully sent to each of the recipients, the MSRP >> switch MUST discard the temporary storage of MSRP Message-ID and the >> associated list of recipients. >> >> >> In some occasions, a sender might suffer a transport error condition >> (such as loss of connectivity) that makes the sending of a message >> incomplete, e.g., some chunks were received by the MSRP switch, but >> not all of them. > > It's not limited to transport failures. For example, the sender could > lose power before completing the message. True, that is another example of loss of connectivity. I will add it. > >> This is a behavior already considered in the core MSRP >> specification (see RFC 4575 Section >> 5.4). The problem in the context of a chat room lies with the usage >> of temporary storage for fast forwarding. > > Seems like it would be even worse if you weren't doing fast > forwarding. Then the switch would be saving the chunk contents for > reassembly, wouldn't it? Yeah, you hit a point that I was thinking yesterday when I was composing the text. The need of a timer to detect incomplete messages (due to chunk messaging) is not restricted to the fast forwarding mechanism, but it is also applicable when the non-fast forwarding mechanism is used. Let's keep this in mind. First I want to get the text correct and complete focusing on the fast forwarding mechanism. Then we will need to extrapolate it to the non-fast forwarding mechanism. > >> In order to prevent attacks related to the exhaustion of temporary >> storage of chunked messages, on receiving a first chunk of a >> message, where the MSRP switch is using the fast forward method, the >> MSRP switch MUST set a timer for controlling the reception of the >> remaining chunks. This timer can be re-set every time a new chunk of >> the same message is received. When this timer fires, the MSRP switch >> MUST considered that the sending of the message was aborted, and >> MUST delete all the temporary storage pertaining to this message. >> >> Now the doubt. If the above condition happens, I would like to know >> what is best to do with respect the recipients. These are in a >> strange state, where they have received a number of chunks of a >> message, but not all the chunks, and they will not receive any more. >> What the MSRP switch can do: >> >> a) Nothing. The recipients have received a number of a chunks of a >> message; the message is not complete. The MSRP switch will send >> other messages (perhaps originated by other participants), but this >> chunked message will remain in the endpoints until the endpoint >> crashes^H^H^H^H^H^H^Hrecovers from that situation. >> >> b) A nice MSRP switch will create a new chunk, as it if were >> received from the sender, where there won't be any content, but just >> the abort flag "#". At least this one will have a bigger likelihood >> of endpoint recovery. >> >> I propose to do b). I guess there are no security issues, even if >> TLS is used, because the TLS connection is ending at the MSRP >> switch. >> >> Can anyone think of other options? Is option b) reasonable? >> > > Repeating a comment from a separate thread: > > On reflection, I'm not sure we need to be aggressive with the > normative language here. The receiving endpoints already have to be > able to deal with missing chunks. We are talking about optimizations > here, not interop-critical behavior. I would lean towards making it > clear that a switch doesn't have to keep the message-id and recipients > around forever, and allow it to send a cancelation chunk if it wants > to, but not require it. Specifically, something to the effect of the > following: > > 1) The switch MAY discard the message state if it receives no chunks > within some reasonable time. The specific timeout value is a matter of > local policy, but SHOULD NOT be too short. For example, a time > interval on the order of a normal TCP timeout (i.e. around 9 minutes) > would be reasonable. A timeout on the order of a few seconds would > not. > > 2) If a timeout occurs, or some other error occurs that prevents all > chunks from arriving at the switch, the switch MAY choose to send a > cancelation chunk. This is an optimization, since MSRP endpoints need > to be able to handle incomplete messages anyway. Totally agreed. I will work to reflect this in the draft. /Miguel > > > >> /Miguel >> >> >> On 05/09/2012 9:19, Miguel A. Garcia wrote: >>> In my previous e-mail, please s/5.3/5.4 >>> >>> To be explicit: the MSRP Connection Model is described in Section >>> 5.4 of RFC 4975. >>> >>> /Miguel >>> >>> On 05/09/2012 9:15, Miguel A. Garcia wrote: >>>> Hi Ben, >>>> >>>> Thanks for your comments >>>> >>>> On 04/09/2012 16:26, Ben Campbell wrote: >>>>> (As individual) >>>>> >>>>> Hi, >>>>> >>>>> I agree with Miguel's responses except as noted inline >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" >>>>> wrote: >>>>>> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 6.1 >>>>>>> >>>>>>> An MSRP switch that uses this fast forwarding procedure >>>>>>> MUST temporarily store the Message-Id of the MSRP message >>>>>>> to correlate the different chunks, as well as it MUST >>>>>>> temporarily store the list of recipients to which the >>>>>>> initial chunks were delivered. >>>>>>> >>>>>>> The motivaiton is clear. I think you could add that the >>>>>>> storage can be released when the last chunk is seen. But >>>>>>> what happens when the last chunk is not seen (or delayed)? >>>>>>> How temporary is the storage, and how is it released? >>>>>> >>>>>> Yes, we can add that the temporary storage is released when >>>>>> the last chunk is seen or after a reasonable time passes. >>>>> >>>>> The "how long to wait for a chunk" problem is no different >>>>> than for any other endpoint, is it, other than possibly >>>>> differences of scale? I suggest we refer back to 4975 for >>>>> this, with the possible note to the effect of "This is no >>>>> different than for any MSRP endpoint that receives a chunked >>>>> message. However, since a conference switch will typically >>>>> participate many sessions at one time, storage management may >>>>> be more critical" >>>> >>>> >>>> I would like to include a reference to the section in RFC 4975 >>>> that discusses this topic. I guess it is Section 5.3, when it >>>> discusses what happens if a transport connection fails. >>>> >>>>> >>>>>>> >>>>>>> Or do we assume that because MSRP uses TCP (or similar) >>>>>>> that loss will always be accompanied by connection failure >>>>>>> and so that is the only trigger needed to abandon >>>>>>> temporary storage? >>>>>> >>>>>> Yes, on one side, the assumption is that if a last chunk is >>>>>> not seen is because there has been a transport failure. >>>>>> Since TCP is used, then the TCP connection was broken, and >>>>>> is in the process of being re-established. I am more >>>>>> concerned about what happens if the last chunk is not seen >>>>>> at all, I am not sure the state the MSRP session will be, >>>>>> even if the connection is re-established. >>>>> >>>>> Keep in mind there could be an MSRP relay between the sender >>>>> and the switch, so the transport connection may not be direct. >>>>> But again, this is no different than for any other MSRP >>>>> endpoint. >>>> >>>> Exactly. Here we clearly need to refer to Section 5.3 of RFC >>>> 4975. >>>> >>>>> >>>>>> >>>>>> >>>>>>> --- >>>>>>> >>>>>>> Section 6.1 (trivial nit) >>>>>>> >>>>>>> The SEND request MUST contain a top-level wrapper of type >>>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The >>>>>>> actual instant message payload MUST be included as payload >>>>>>> of the 'Message/CPIM' wrapper and MAY be of any type >>>>>>> negotiated in the SDP 'accept-types' attribute according >>>>>>> to the MSRP rules. >>>>>>> >>>>>>> I think s/MAY/may/. That is, a type must be set, and the >>>>>>> type must be only one of those that has been negotiated. >>>>>>> >>>>>>> >>>>>> >>>>>> I think this MAY should actually be a MUST, because as you >>>>>> said, a types must be said, and this type cannot be anyone, >>>>>> but it MUST be one of those negotiated. >>>>> >>>>> This is already mandated in RFC4975 (as you go on to say...). >>>>> The only thing new is the normative requirement for a >>>>> particular wrapper type. It might be worth commenting that >>>>> this is accomplished by putting only Message/CPIM in >>>>> accept-types, and all allowed leaf types in >>>>> accept-wrapped-types. >>>> >>>> Ok, we can clarify it. Actually, we do not mention what can go >>>> in an accept-wrapped-types, because it was obvious that any type >>>> can go in. But it might be worth adding some explicit mention to >>>> it. >>>> >>>>> >>>>>> >>>>>> I like the "according to the MSRP rules", as a mechanism to >>>>>> indicate that we are not mandating something new, but just >>>>>> copying what MSRP mandates. >>>>>> >>>>> >>>>> ... in which case it should be stated descriptively, not >>>>> normatively. >>>> >>>> Hmmm, that is true. I suggest to move away from >>>> MUST/MAY/must/may. I think the text ought to say: "According to >>>> RFC 4975, the endpoint needs to ...". This is makes it clear, >>>> and we do not over-specify. >>>> >>>> /Miguel >>>> >>> >> >> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >> _______________________________________________ Simple mailing list >> Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Thu Sep 6 05:28:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B82B21F85C0 for ; Thu, 6 Sep 2012 05:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.234 X-Spam-Level: X-Spam-Status: No, score=-6.234 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2yWPTpHht4d for ; Thu, 6 Sep 2012 05:28:49 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 086E421F8594 for ; Thu, 6 Sep 2012 05:28:48 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-d8-504896ff7c35 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0E.22.17130.FF698405; Thu, 6 Sep 2012 14:28:47 +0200 (CEST) Received: from [159.107.24.196] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Thu, 6 Sep 2012 14:28:47 +0200 Message-ID: <504896FD.1010407@ericsson.com> Date: Thu, 6 Sep 2012 14:28:45 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> In-Reply-To: <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvre7/aR4BBhsPyVg0P/zFZrFw4j9W ByaPx19nsXosWfKTKYApissmJTUnsyy1SN8ugSvjWMc61oIlahUT5/9mamCcIdfFyMEhIWAi sf9aehcjJ5ApJnHh3nq2LkYuDiGBU4wSm7/MZYJwVjNK7Ph3gRWkildAW+L478dgNouAikTX mkYmEJtNwFyideNGdhBbVCBQYt3VP+wQ9YISJ2c+YQGxRQSUJVbsPw8WZxaQl1i4uZkRZIGw QAejRN+a2+wQ2yYwSTy92APWwSngIHFnxQ1WiA5biQtzrrPAdG9/O4cZxBYS0JSYfHMp8wRG wVlIFs5C0jILScsCRuZVjMK5iZk56eXmeqlFmcnFxfl5esWpmxiB4Xpwy2+DHYyb7osdYpTm YFES59VT3e8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFO/MRh4aMPhI5tZFTyflH4eWX1 wZllbEt8dwcsDD4n9OrhkS9y1pLMqkvev5M8tkZx77uvJjtWPEmo5V9nk3HL9iWz1NdcBZFl Fvoc7mp93l9DqgM0pVqCzj+c/NCk+NWsm4V8rSwvCxW3Nb6pef8nWPG72ESZZcf3HHNgmR9i Ii9nKXlqQpcSS3FGoqEWc1FxIgBcsJL2JQIAAA== Cc: Simple WG Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 12:28:50 -0000 Hi Ben, Inline comments. On 05/09/2012 21:05, Ben Campbell wrote: > > On Sep 5, 2012, at 9:35 AM, Miguel A. Garcia wrote: > >> I am now addressing the issue with accept-types and accept-wrapped-types. >> >> There are two affected sections: >> >> Section 5.2 discusses the SDP offer/answer when joining a chat room. The text now reads: >> >> The conference focus of a chat room MUST include support for >> a Message/CPIM top-level >> wrapper for the MSRP messages by setting the 'accept-types' >> MSRP media line attribute in the SDP >> offer or answer to include 'Message/CPIM'. > > _only_ Message/CPIM, right? Or can other media types be included at the root? Well, I expect the UA to be common to chat (through chat server) and point-to-point instant messaging. If this is the case, the UA will add the accept-types including types that are supported and useful for both chat and point-to-point IM. Then the MSRP switch will response with only Message/CPIM. So, to summarize, the UA populatse the accept-types with all the formats that it supports, including Message/CPIM; the server will reply with Message/CPIM. The text to support this reads: The conference focus of a chat room MUST include support for a Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by setting the 'accept-types' MSRP media line attribute in the SDP offer or answer [RFC3264] to include 'Message/CPIM'. > >> The >> actual payload type is negotiated in the >> 'accept-wrapped-types' attribute in SDP (see > target="RFC4575">RFC 4575 for details). There is no >> default wrapped type. Typical wrapped type values can >> include: text/plain, text/html, image/jpeg, image/png, >> audio/mp3, etc. > > Assuming you mean 4975, it looks good. We could mention the use of "*", but I think that's already covered by the reference, and we don't want to restate too much here. > >> >> >> The other paragraph is in Section 6.1 (Regular messages), when we want to say that the MSRP SEND request needs to use one of the payloads negotiated in the accept-wrapped-types: >> >> The SEND request MUST contain a top-level wrapper of type >> 'Message/CPIM' according to RFC >> 3862. The actual instant message payload MUST be >> included as payload of the 'Message/CPIM' wrapper, and, >> according to RFC 4575, it >> needs to be one of those negotiated in the >> 'accept-wrapped-types' attribute in SDP. >> >> Please note that in this last paragraph there is a bug in the current version of the draft. The last sentence incorrectly pointed to the 'accept-types' attribute, rather than the 'accept-wrapped-types'. I believe the proposed text above is now correct. > > Looks good, again assuming you mean 4975. Ouch. Fixed now, yes 4975. I am fixing other similar errors. Thanks, Miguel > >> >> /Miguel >> >> >> On 05/09/2012 9:19, Miguel A. Garcia wrote: >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> Section 6.1 (trivial nit) >>>>>>>>>> >>>>>>>>>> The SEND request MUST contain a top-level wrapper of type >>>>>>>>>> 'Message/ CPIM' according to RFC 3862 [RFC3862]. The actual >>>>>>>>>> instant message payload MUST be included as payload of the >>>>>>>>>> 'Message/CPIM' wrapper and MAY be of any type negotiated in the >>>>>>>>>> SDP 'accept-types' attribute according to the MSRP rules. >>>>>>>>>> >>>>>>>>>> I think s/MAY/may/. That is, a type must be set, and the type must >>>>>>>>>> be only one of those that has been negotiated. >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> I think this MAY should actually be a MUST, because as you said, a >>>>>>>> types must be said, and this type cannot be anyone, but it MUST be >>>>>>>> one of those negotiated. >>>>>> >>>>>> This is already mandated in RFC4975 (as you go on to say...). The only >>>>>> thing new is the normative requirement for a particular wrapper type. >>>>>> It might be worth commenting that this is accomplished by putting only >>>>>> Message/CPIM in accept-types, and all allowed leaf types in >>>>>> accept-wrapped-types. >>>> >>>> Ok, we can clarify it. Actually, we do not mention what can go in an >>>> accept-wrapped-types, because it was obvious that any type can go in. But >>>> it might be worth adding some explicit mention to it. >>>> >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Thu Sep 6 13:12:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5620821F84CE for ; Thu, 6 Sep 2012 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2KK3Yex1m2C for ; Thu, 6 Sep 2012 13:12:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A12621F87A9 for ; Thu, 6 Sep 2012 13:12:14 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86KC96j078286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Sep 2012 15:12:09 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504896FD.1010407@ericsson.com> Date: Thu, 6 Sep 2012 15:12:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 20:12:23 -0000 On Sep 6, 2012, at 7:28 AM, Miguel A. Garcia = wrote: > Hi Ben, >=20 > Inline comments. >=20 > On 05/09/2012 21:05, Ben Campbell wrote: >>=20 >> On Sep 5, 2012, at 9:35 AM, Miguel A. Garcia = wrote: >>=20 >>> I am now addressing the issue with accept-types and = accept-wrapped-types. >>>=20 >>> There are two affected sections: >>>=20 >>> Section 5.2 discusses the SDP offer/answer when joining a chat room. = The text now reads: >>>=20 >>> The conference focus of a chat room MUST include support = for >>> a Message/CPIM top-level >>> wrapper for the MSRP messages by setting the 'accept-types' >>> MSRP media line attribute in the SDP= >>> offer or answer to include 'Message/CPIM'. >>=20 >> _only_ Message/CPIM, right? Or can other media types be included at = the root? >=20 > Well, I expect the UA to be common to chat (through chat server) and = point-to-point instant messaging. If this is the case, the UA will add = the accept-types including types that are supported and useful for both = chat and point-to-point IM. Then the MSRP switch will response with only = Message/CPIM. But the text talks about the what the conference focus sends, not UAs in = _general_. If the focus includes anything _other_ than Message/CPIM in = accept-types, it better be prepared to receive it. Is that the intent? >=20 > So, to summarize, the UA populatse the accept-types with all the = formats that it supports, including Message/CPIM; the server will reply = with Message/CPIM. The text to support this reads: >=20 > The conference focus of a chat room MUST include support for a > Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by > setting the 'accept-types' MSRP media line attribute in the SDP = offer > or answer [RFC3264] to include 'Message/CPIM'. From ben@nostrum.com Thu Sep 6 14:40:34 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0C821F8778 for ; Thu, 6 Sep 2012 14:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KflTZNs4WZ-b for ; Thu, 6 Sep 2012 14:40:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F26121F876C for ; Thu, 6 Sep 2012 14:40:29 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q86LeTxi087009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 6 Sep 2012 16:40:29 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 6 Sep 2012 16:40:26 -0500 References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> To: Simple WG Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [Simple] Fwd: Help the NomCom: Nominations and Feedback X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 21:40:34 -0000 Please help the NomCom in any way you can! Begin forwarded message: > From: NomCom Chair > Subject: Help the NomCom: Nominations and Feedback > Date: September 5, 2012 7:21:29 PM CDT > To: Working Group Chairs > > The IETF Nominations Committee (NomCom) is currently seeking > nominations for individuals to serve on the IESG, IAB, and IAOC. > Additionally, this is an announcement that the NomCom is seeking > feedback on individuals who have accepted nominations for IETF > leadership positions. > > It is very important to the NomCom process that we get input from a > broad spectrum of the community. Therefore, in case members of your > working group do not read the IETF announcement and discussion lists, > the NomCom would appreciate your help in disseminating the following > information. > > The NomCom website contains information about this year's NomCom > including the positions we are seeking to fill, and the qualifications > required for these positions: > > https://www.ietf.org/group/nomcom/2012/ > > The NomCom is accepting nominations until September 24. Nominations > for any position can be made using the following web tool: > > https://www.ietf.org/group/nomcom/2012/nominate > > Feedback about individuals who the NomCom is considering can be > providing using the following web tool: > > https://www.ietf.org/group/nomcom/2012/input > > The feedback tool provides a list of individuals who have agreed to be > considered for each position. We will be updating this list in the coming > weeks as more individuals accept nominations. > > Feedback provided to the NomCom is kept strictly confidential! > > Note that use of the NomCom web tools require an ietf.org (i.e., > datatracker) account. You can create an ietf.org account by visiting the > following URL: > > https://datatracker.ietf.org/accounts/create/ > > As an alternative to using the web tools, you can send email to the > NomCom at nomcom12@ietf.org to make a nomination or provide input to > the committee. > > Thank you for your help, > - Matt Lepinski > nomcom-chair@ietf.org From miguel.a.garcia@ericsson.com Fri Sep 7 01:42:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1198421F86FF for ; Fri, 7 Sep 2012 01:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.237 X-Spam-Level: X-Spam-Status: No, score=-6.237 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBdiF3iWRxEj for ; Fri, 7 Sep 2012 01:42:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4785321F86F6 for ; Fri, 7 Sep 2012 01:42:01 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-41-5049b35535b4 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 14.84.17130.553B9405; Fri, 7 Sep 2012 10:41:58 +0200 (CEST) Received: from [159.107.105.132] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.1; Fri, 7 Sep 2012 10:41:57 +0200 Message-ID: <5049B354.7060004@ericsson.com> Date: Fri, 7 Sep 2012 10:41:56 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> In-Reply-To: <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvrW7YZs8Ag57rHBbND3+xWczvPM1u sXDiP1YHZo/HX2exeixZ8pPJY9bOJywBzFFcNimpOZllqUX6dglcGe/n3WAqmMlSMenxDNYG xpXMXYycHBICJhKH375lh7DFJC7cW8/WxcjFISRwilFixry9UM4aRolF35azglTxCmhLNNz4 xNLFyMHBIqAisX+BFkiYTcBconXjRrBBogKBEuuu/mGHKBeUODnzCQuILSKgJPG8eSuYzSzg IDH72FN2kPnCAh2MEn1rbrNDLHvMJHHo/XWwbk4Be4nv8xsYITpsJS7MuQ7VLS+x/e0csBeE BDQlJt9cyjyBUXAWkoWzkLTMQtKygJF5FaNwbmJmTnq5uV5qUWZycXF+nl5x6iZGYAgf3PLb YAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCMW19XMlP054z4 +HiDyn+zpnXeOH2xPD5ge92DOamfjuU/Tq4on213sJ51beDUhzMce717ud6Yqu7ZKXnLJP5j 0H6pOyoZrSv9dHr/T+OUebvsWe/NWrPatU0boktYpZo36TtmhM8tS7l6oLN0zwQdLf6Dk22b Y1IFF2fWW5burbm5fP/ZFEklluKMREMt5qLiRACoSXWELwIAAA== Cc: Simple WG Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2012 08:42:02 -0000 On 06/09/2012 22:12, Ben Campbell wrote: > But the text talks about the what the conference focus sends, not UAs in_general_. If the focus includes anything_other_ than Message/CPIM in accept-types, it better be prepared to receive it. Is that the intent? Ben, I see your point. The conference focus MUST only send an accept-types of Message/CPIM. There is no reason for using any other value. I will revise this text to make clear the intention. BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Mon Sep 10 06:20:49 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AEFC21F85C0 for ; Mon, 10 Sep 2012 06:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIiMW2VUfd2Z for ; Mon, 10 Sep 2012 06:20:42 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6256D21F85B4 for ; Mon, 10 Sep 2012 06:20:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-3d-504de929ad7c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 66.84.11467.929ED405; Mon, 10 Sep 2012 15:20:41 +0200 (CEST) Received: from [159.107.24.223] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Mon, 10 Sep 2012 15:20:38 +0200 Message-ID: <504DE925.4050303@ericsson.com> Date: Mon, 10 Sep 2012 15:20:37 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Ben Campbell References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> In-Reply-To: <5049B354.7060004@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvra7mS98Ag4+3BC2aH/5is5jfeZrd YuHEf6wOzB6Pv85i9Viy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mk7Pe89S8Fep4uaVOawN jPukuxg5OSQETCQW7jnJAmGLSVy4t56ti5GLQ0jgFKPE4fs/2SGcNYwSS+dvB6viFdCWuDn9 HyuIzSKgKrHi5hUmEJtNwFyideNGdhBbVCBQYt3VP+wQ9YISJ2c+AesVEVCSeN68FcxmFnCQ mH3sKdgCYYEORom+NbehtjUzSxybdh5sKqeAjsT0798YITpsJS7MuQ7VLS+x/e0cZhBbSEBT YvLNpcwTGAVnIVk4C0nLLCQtCxiZVzEK5yZm5qSXG+qlFmUmFxfn5+kVp25iBAbxwS2/dXcw njoncohRmoNFSZyXK2m/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG4jmblrCe35Er/IL1 XPSN/shXk8RmaQRcWRF4f3vOtG13ZN/O2DL1ZvPhJ7v9p1+8ePpebE7da00+07Vt3Ce8T+nW b3LVXRb8Zev63Ct3g/ybqyNfsa6WLHl1JPF67wH+4Itn9Det/ucn9Cn32KnYMqm/x5+v3sTL vb1dSr/9x15GXpO0a94L7JRYijMSDbWYi4oTAUigWOEwAgAA Cc: Simple WG Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 13:20:49 -0000 Ben, and the SIMPLE WG: To clarify the usage of accept-types, I propose two paragraphs to Section 5.2 (Joining a chat room). The first paragraph is new and discusses the participant's SDP. Here, I propose not to add normative text mandating the UA to add 'a=accept-types:Message/CPIM' in SDP. The reason is that such normative text would require a mechanism for the UA to know in advance that it is joining a chat room, perhaps by examining the chat room URI. But in general, such mechanism does not exist. The UA will create an INVITE request with SDP, not knowing if at the other end there is a chat room or a regular user. If this SDP contains 'm=message', the attributes included afterwards will be the same, no matter whether the participant is joining a chat room or just another endpoint. Please verify that the proposed words are acceptable: "...needs to include at least... This participant's INVITE request contains an SDP body. This SDP body includes the description of MSRP 'message' media line as per RFC 4975 procedures [RFC4975]. This specification requires all instant messages to be wrapped in a Message/CPIM wrapper [RFC3862], therefore, the 'accept-types' attribute for the MSRP message media in the participant's SDP offer needs to include at least the value 'Message/CPIM', otherwise the conference focus will reject the request. The actual instant message payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). There is no default wrapped type. Typical wrapped type values can include: text/plain, text/html, image/jpeg, image/ png, audio/mp3, etc. It is RECOMMENDED that participant endpoints add an 'accept-wrapped-types' attribute to the MSRP 'message' media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975]. Now, the second paragraph was already present in the previous version, and is now divided into two paragraphs. It tackles the conference focus. I have added text to indicate that the focus must only accept Message/CPIM, and also that the focus should add an 'accept-wrapped-types'. The text reads: The conference focus of a chat room MUST only use a Message/CPIM [RFC3862] top-level wrapper as a payload of MSRP messages, and this needs to be declared in the SDP offer and answer as per regular RFC 4975 procedures [RFC4975]. This implies that if the conference focus receives from a participant's endpoint an SDP offer that does not include the value 'Message/CPIM' in the 'accept-types' attribute for the MSRP message media line, the conference focus SHOULD either reject the MSRP message media stream or the complete SDP offer by using regular SIP or SDP procedures (e.g., creating an SDP answer that sets to zero the port of the MSRP message media line, responding the INVITE with a 488 response, etc.). If the conference focus accepts the participant's SDP offer, when the conference focus generates the SDP answer, it MUST set the 'accept- types' attribute for the MSRP message media line to a value of 'Message/CPIM'. This specification requires all instant messages to be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' attribute in this SDP body contains a single value of 'Message/CPIM'. The actual instant message payload type is negotiated in the 'accept- wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). The conference focus SHOULD also add an 'accept-wrapped-types' attribute to the MSRP message media line in SDP containing the supported wrapped types. Please indicate if there are problems with the proposed text. /Miguel On 07/09/2012 10:41, Miguel A. Garcia wrote: > On 06/09/2012 22:12, Ben Campbell wrote: >> But the text talks about the what the conference focus sends, not UAs >> in_general_. If the focus includes anything_other_ than Message/CPIM >> in accept-types, it better be prepared to receive it. Is that the intent? > > Ben, I see your point. The conference focus MUST only send an > accept-types of Message/CPIM. There is no reason for using any other value. > > I will revise this text to make clear the intention. > > BR, > > Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Mon Sep 10 09:00:53 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6AE21F870E for ; Mon, 10 Sep 2012 09:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j63t-ZDw9rpN for ; Mon, 10 Sep 2012 09:00:52 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 680E921F86AB for ; Mon, 10 Sep 2012 09:00:52 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id xPHV1j0051YDfWL53U0vfK; Mon, 10 Sep 2012 16:00:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id xU0S1j00J3ZTu2S3gU0S6h; Mon, 10 Sep 2012 16:00:26 +0000 Message-ID: <504E0EB3.1010709@alum.mit.edu> Date: Mon, 10 Sep 2012 12:00:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: simple@ietf.org References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> In-Reply-To: <504DE925.4050303@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:00:53 -0000 On 9/10/12 9:20 AM, Miguel A. Garcia wrote: > Ben, and the SIMPLE WG: > > To clarify the usage of accept-types, I propose two paragraphs to > Section 5.2 (Joining a chat room). The first paragraph is new and > discusses the participant's SDP. Here, I propose not to add normative > text mandating the UA to add 'a=accept-types:Message/CPIM' in SDP. The > reason is that such normative text would require a mechanism for the UA > to know in advance that it is joining a chat room, perhaps by examining > the chat room URI. But in general, such mechanism does not exist. The UA > will create an INVITE request with SDP, not knowing if at the other end > there is a chat room or a regular user. If this SDP contains > 'm=message', the attributes included afterwards will be the same, no > matter whether the participant is joining a chat room or just another > endpoint. Please verify that the proposed words are acceptable: > "...needs to include at least... > > This participant's INVITE request contains an SDP body. This SDP There are possibilities beyond the one mentioned here: - the participant might send an INVITE without an offer. - the focus might send the INVITE, with or without an offer. > body includes the description of MSRP 'message' media line as per RFC > 4975 procedures [RFC4975]. This specification requires all instant > messages to be wrapped in a Message/CPIM wrapper [RFC3862], > therefore, the 'accept-types' attribute for the MSRP message media in > the participant's SDP offer needs to include at least the value > 'Message/CPIM', otherwise the conference focus will reject the > request. The actual instant message payload type is negotiated in > the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] > for details). There is no default wrapped type. Typical wrapped > type values can include: text/plain, text/html, image/jpeg, image/ > png, audio/mp3, etc. It is RECOMMENDED that participant endpoints > add an 'accept-wrapped-types' attribute to the MSRP 'message' media > line in SDP, where the supported wrapped types are declared, as per > RFC 4975 procedures [RFC4975]. So how about the following instead? This specification requires all instant messages to be wrapped in a Message/CPIM wrapper [RFC3862]. Therefore the 'accept-types' attribute for the MSRP message media in both the SDP offer and answer need to include at least the value 'Message/CPIM'. If not, the conference focus will reject the request. The actual instant message payload type is negotiated in the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). There is no default wrapped type. Typical wrapped type values can include: text/plain, text/html, image/jpeg, image/ png, audio/mp3, etc. It is RECOMMENDED that participant endpoints add an 'accept-wrapped-types' attribute to the MSRP 'message' media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975]. > Now, the second paragraph was already present in the previous version, > and is now divided into two paragraphs. It tackles the conference focus. > I have added text to indicate that the focus must only accept > Message/CPIM, and also that the focus should add an > 'accept-wrapped-types'. The text reads: > > The conference focus of a chat room MUST only use a Message/CPIM > [RFC3862] top-level wrapper as a payload of MSRP messages, and this > needs to be declared in the SDP offer and answer as per regular RFC > 4975 procedures [RFC4975]. This implies that if the conference focus > receives from a participant's endpoint an SDP offer that does not > include the value 'Message/CPIM' in the 'accept-types' attribute for > the MSRP message media line, the conference focus SHOULD either > reject the MSRP message media stream or the complete SDP offer by > using regular SIP or SDP procedures (e.g., creating an SDP answer > that sets to zero the port of the MSRP message media line, responding > the INVITE with a 488 response, etc.). > If the conference focus accepts the participant's SDP offer, when the > conference focus generates the SDP answer, it MUST set the 'accept- > types' attribute for the MSRP message media line to a value of > 'Message/CPIM'. This specification requires all instant messages to > be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' > attribute in this SDP body contains a single value of 'Message/CPIM'. > The actual instant message payload type is negotiated in the 'accept- > wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). > The conference focus SHOULD also add an 'accept-wrapped-types' > attribute to the MSRP message media line in SDP containing the > supported wrapped types. I'm not sure this says quite what you mean either. Couple of issues: - I guess the intent is that every message sent to/from the focus is wrapped in Messsage/CPIM. That is easy for messages *from* the focus. But to ensure it for messages *to* the focus I think you are trying to say that the SDP *from* the focus must include *only* message/CPIM in 'accept-types'. I think the MUST is in the wrong place above for that. - I am a little concerned that if you only allow message/CPIM, that you will be cutting off a point of extensibility. Some future extension may need to add something that requires a new mime type here - presumably one that is a functional superset of message/CPIM. But a mandatory requirement to include *only* message/CPIM will exclude such a future focus from being backward compatible with this spec. ISTM that the desired behavior is: - if focus is the answerer, and the offer doesn't include message/CPIM, then it can't support this spec on that m-line. It then MUST either reject the m-line, fail the call, or use this m-line in accord with some spec other than this one. (E.g. a future extension.) If the offer *does* include message/CPIM, and the focus wants to use this spec, then it MUST include *only* message/CPIM in 'accept-types'. - if the focus is the offerer, and wishes to support this spec, then it MUST include message/CPIM in 'accept-types'. It should only include other types in 'accept-types' if there are other alternative specs is is prepared to support. I don't have alternative text for that. It may be hard to write, and I'm not going to try unless the above is really the intent. Thanks, Paul > Please indicate if there are problems with the proposed text. > > /Miguel > > > > On 07/09/2012 10:41, Miguel A. Garcia wrote: >> On 06/09/2012 22:12, Ben Campbell wrote: >>> But the text talks about the what the conference focus sends, not UAs >>> in_general_. If the focus includes anything_other_ than Message/CPIM >>> in accept-types, it better be prepared to receive it. Is that the >>> intent? >> >> Ben, I see your point. The conference focus MUST only send an >> accept-types of Message/CPIM. There is no reason for using any other >> value. >> >> I will revise this text to make clear the intention. >> >> BR, >> >> Miguel > From ben@nostrum.com Mon Sep 10 09:22:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343121F8722 for ; Mon, 10 Sep 2012 09:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSgCEWiZS6PX for ; Mon, 10 Sep 2012 09:22:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id AFBCB21F872A for ; Mon, 10 Sep 2012 09:22:12 -0700 (PDT) Received: from [10.12.11.64] ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8AGMAB7008265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Sep 2012 11:22:11 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504E0EB3.1010709@alum.mit.edu> Date: Mon, 10 Sep 2012 11:22:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> <504E0EB3.1010709@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:22:13 -0000 On Sep 10, 2012, at 11:00 AM, Paul Kyzivat = wrote: > - I am a little concerned that if you only allow message/CPIM, that = you > will be cutting off a point of extensibility. Some future extension > may need to add something that requires a new mime type here - > presumably one that is a functional superset of message/CPIM. But > a mandatory requirement to include *only* message/CPIM will exclude > such a future focus from being backward compatible with this spec. I'm not sure that's a bad thing, since there's interop behavior that = depends on it's use. If you use something _other_ than message/CPIM, = some one will need to specify how you handle the behavior that is = dependent on it. A possible compromise might be something like "SHOULD include only = message/CPIM. While other types might be useful in the future, their use = is out of scope for this specification. Any chat mechanism that uses a = wrapper other than message/CPIM will need to specify how to encode and = interpret sender and recipient information to achieve similar behaviors = as in this document." From pkyzivat@alum.mit.edu Mon Sep 10 09:49:46 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CAE21E8041 for ; Mon, 10 Sep 2012 09:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iJyfRX9DwXu for ; Mon, 10 Sep 2012 09:49:46 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1B921E8037 for ; Mon, 10 Sep 2012 09:49:45 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id xQF51j0031ap0As55UppPK; Mon, 10 Sep 2012 16:49:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id xUqF1j0093ZTu2S3iUqFFs; Mon, 10 Sep 2012 16:50:15 +0000 Message-ID: <504E1A27.8000100@alum.mit.edu> Date: Mon, 10 Sep 2012 12:49:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: simple@ietf.org References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> <504E0EB3.1010709@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 16:49:47 -0000 On 9/10/12 12:22 PM, Ben Campbell wrote: > > On Sep 10, 2012, at 11:00 AM, Paul Kyzivat wrote: > >> - I am a little concerned that if you only allow message/CPIM, that you >> will be cutting off a point of extensibility. Some future extension >> may need to add something that requires a new mime type here - >> presumably one that is a functional superset of message/CPIM. But >> a mandatory requirement to include *only* message/CPIM will exclude >> such a future focus from being backward compatible with this spec. > > I'm not sure that's a bad thing, since there's interop behavior that depends on it's use. If you use something _other_ than message/CPIM, some one will need to specify how you handle the behavior that is dependent on it. The issue is with some future implementation that supports simple-chat and simple-chat-bis that uses message/CPIM++. The problem then arises only in the case that the focus generates the offer. It then wants to put "message/CPIM,message/CPIM++" in 'accept-types'. This should be fine for answerers that support only simple-chat as long as they don't get over-picky and declare the focus non-compliant for mentioning message/CPIM++. So it's just a matter of not forbidding the focus from including something else. > A possible compromise might be something like "SHOULD include only message/CPIM. While other types might be useful in the future, their use is out of scope for this specification. Any chat mechanism that uses a wrapper other than message/CPIM will need to specify how to encode and interpret sender and recipient information to achieve similar behaviors as in this document." Yes, something like that could work. Thanks, Paul From miguel.a.garcia@ericsson.com Tue Sep 11 05:46:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8506C21F8770 for ; Tue, 11 Sep 2012 05:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8g7BAdUyYfk for ; Tue, 11 Sep 2012 05:46:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBBA21F8751 for ; Tue, 11 Sep 2012 05:46:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-cc-504f32a01e94 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 20.90.11467.0A23F405; Tue, 11 Sep 2012 14:46:24 +0200 (CEST) Received: from [159.107.24.216] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Tue, 11 Sep 2012 14:46:24 +0200 Message-ID: <504F329F.6030703@ericsson.com> Date: Tue, 11 Sep 2012 14:46:23 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvre4CI/8Ag4ZjJhYnjhxkt1g48R+r A5PHlN8bWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx9PMCloLHEhVbp4o3MJ4U7mLk5JAQMJF4 03SODcIWk7hwbz2QzcUhJHCKUeLwzCmsEM4aRok7LXNYQap4BbQl1ux6xA5iswioSpw81c0I YrMJmEu0btwIFhcVCJY4t3EbG0S9oMTJmU9YQGwRAXmJF7N/MYHYzAK6Em+7ZoPVCwsYSXx8 8RQqbitxYc51FghbXmL72znMILaQgKbE5JtLmScw8s9CMnYWkpZZSFoWMDKvYhTOTczMSS83 1EstykwuLs7P0ytO3cQIDL2DW37r7mA8dU7kEKM0B4uSOC9X0n5/IYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYw1CxcVnrXuOv7+v7ODYfmcHQt1t+z+4/53Pw9TVvjUiIM7DGeY5s9Kzrq/ WOON3+adDH9ua7KWT1uatbjx+JmKO2J/zhn6RRpYdP5/E/b05omFM8JiCj+90Fyxa9eca+8L i4o5Hne5uEv4dB4zv8Kp++VQ9P7Qh0enuvSwbFTN2fbj96SHfXl7lViKMxINtZiLihMBFqLh SgsCAAA= Subject: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 12:46:27 -0000 Hi, the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a minimum set of supported types inside the Message/CPIM wrappers. While I was replying to Stephen Farrell's IESG review, he had a question, and that one brought me another one. I am seeking advice as for how to proceed. So, here are the questions: 1) Version -16 of the draft is a bit silent with respect 'accept-wrapped-types. I first proposed these two paragraphs to be added to version -17, however, I have concerns with one of them (see below). It is RECOMMENDED that participant endpoints add an 'accept-wrapped-types' attribute to the MSRP 'message' media line in SDP, where the supported wrapped types are declared, as per RFC 4975 procedures [RFC4975]. The conference focus SHOULD also add an 'accept-wrapped-types' attribute to the MSRP message media line in SDP containing the supported wrapped types. My question is... does the conference focus need to add an 'accept-wrapped-types'? The MSRP switch never interprets the actual payload contents, so, for the MSRP switch, the actual payload in instant messages is transparent. So, why should the MSRP switch care? Why should the focus add an 'accept-wrapped-types' at all? I propose to replace the initially proposed "SHOULD" with a "MAY" in the previous paragraph. 2) Stephen Farrel is questioning what should the MSRP switch do if one sender sends an instant message to the chat room, the message containing a type (inside Message/CPIM) that not all the recipients can understand. In other words, the MSRP switch/focus has received SDP indicating that an endpoint supports types A, B, and C. If another participant sends a message with type D, what should the MSRP switch do? Possibilities include: a) Do nothing; forward the message to D, he should deal with the issue. I don't like this, because it is bypassing the MSRP accept-* negotiation. b) Do not forward the message to this user, but forward to others who accept this type. It is possible that the MSRP switch injects a warning instant message to the sender, indicating this condition. c) Reject the message to the sender (i.e., do not forward to any user). I don't like this option either, because the poor sender has done nothing wrong. Additionally, this is the dictatorship of the minority (a few people who do not support a type that will be supported by the majority will impose their rules). And it will be so easy to kill a chat room by just logging in supporting only weird type that none else supports. So, probably b) is the less worst of all. Comments? I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types. Additionally, I expect implementations to add a "*" to indicate support for additional types that have not been explicitly listed, in which case, the MSRP switch will not do any filter, and it is about the endpoint to render the content or not. Comments? BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Tue Sep 11 07:24:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA73521F87FA for ; Tue, 11 Sep 2012 07:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvwqvJPjXeOd for ; Tue, 11 Sep 2012 07:24:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1326921F87AA for ; Tue, 11 Sep 2012 07:24:01 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BENwol036869 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 09:23:58 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504F329F.6030703@ericsson.com> Date: Tue, 11 Sep 2012 09:23:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> References: <504F329F.6030703@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 14:24:03 -0000 On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" = wrote: > Hi, >=20 > the chat draft uses the 'accept-wrapped-types' in SDP for negotiating = a minimum set of supported types inside the Message/CPIM wrappers. >=20 > While I was replying to Stephen Farrell's IESG review, he had a = question, and that one brought me another one. I am seeking advice as = for how to proceed. >=20 > So, here are the questions: >=20 > 1) Version -16 of the draft is a bit silent with respect = 'accept-wrapped-types. I first proposed these two paragraphs to be added = to version -17, however, I have concerns with one of them (see below). >=20 > It is RECOMMENDED that participant endpoints > add an 'accept-wrapped-types' attribute to the MSRP 'message' media > line in SDP, where the supported wrapped types are declared, as per > RFC 4975 procedures [RFC4975]. >=20 > The conference focus SHOULD also add an 'accept-wrapped-types' > attribute to the MSRP message media line in SDP containing the > supported wrapped types. >=20 > My question is... does the conference focus need to add an = 'accept-wrapped-types'? The MSRP switch never interprets the actual = payload contents, so, for the MSRP switch, the actual payload in instant = messages is transparent. So, why should the MSRP switch care? Why should = the focus add an 'accept-wrapped-types' at all? >=20 > I propose to replace the initially proposed "SHOULD" with a "MAY" in = the previous paragraph. I concur. It could use this to express policy about what types it = allows, but it could just set it to "*" if it doesn't care. Do we need to talk about what happens if a _recipient_ does not support = a type? I suppose the focus could set accept-wrapped-types based on what = all the participants have expressed--but that sounds like a recipe for = re-invite storms. The focus could send a 415 response to any type where = it knows that that one or more recipients cannot accept it. >=20 >=20 > 2) Stephen Farrel is questioning what should the MSRP switch do if one = sender sends an instant message to the chat room, the message containing = a type (inside Message/CPIM) that not all the recipients can understand. = In other words, the MSRP switch/focus has received SDP indicating that = an endpoint supports types A, B, and C. If another participant sends a = message with type D, what should the MSRP switch do? >=20 > Possibilities include: > a) Do nothing; forward the message to D, he should deal with the = issue. I don't like this, because it is bypassing the MSRP accept-* = negotiation. >=20 > b) Do not forward the message to this user, but forward to others who = accept this type. It is possible that the MSRP switch injects a warning = instant message to the sender, indicating this condition. >=20 > c) Reject the message to the sender (i.e., do not forward to any = user). I don't like this option either, because the poor sender has done = nothing wrong. Additionally, this is the dictatorship of the minority (a = few people who do not support a type that will be supported by the = majority will impose their rules). And it will be so easy to kill a chat = room by just logging in supporting only weird type that none else = supports. >=20 > So, probably b) is the less worst of all. Comments? >=20 See my previous comment. I'm on the fence between B and C. It seems like the undetermined state = of "some recipients got it but others didn't" is one of the worst = outcomes. I'm not sure I agree about the DoS issue--If a participant = wants to screw with the conference, there's lots of other ways he can do = so.=20 Another option would be to push a warning to the recipient saying that = the someone had sent a type that he had not expressed support for. > I also want to highlight that this is a bit theoretical problem. I = expect most implementations to support all commonly known types. If necessary, we could mandate a must-support leaf type (but I'm not = sure if I want to go there.) > Additionally, I expect implementations to add a "*" to indicate = support for additional types that have not been explicitly listed, in = which case, the MSRP switch will not do any filter, and it is about the = endpoint to render the content or not. What happens if the recipient sends a 415 response? I guess it's like = any other error. That means the sender doesn't learn about it unless the = switch synthesis some sort of warning, right? I also wonder if switches and/or chat participants should be a little = less generous about what types they accept in a chat. Otherwise, this = starts to look like a file transfer exploder :-) >=20 > Comments? >=20 > BR, >=20 > Miguel >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From pkyzivat@alum.mit.edu Tue Sep 11 08:32:54 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8067921F866D for ; Tue, 11 Sep 2012 08:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.424 X-Spam-Level: X-Spam-Status: No, score=-0.424 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB5wBSe5F3vt for ; Tue, 11 Sep 2012 08:32:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 93F9D21F8674 for ; Tue, 11 Sep 2012 08:32:53 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id xlo81j0051HzFnQ53rYwA6; Tue, 11 Sep 2012 15:32:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id xrYv1j00T3ZTu2S3arYvan; Tue, 11 Sep 2012 15:32:55 +0000 Message-ID: <504F59A3.9060909@alum.mit.edu> Date: Tue, 11 Sep 2012 11:32:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> In-Reply-To: <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 15:32:54 -0000 On 9/11/12 10:23 AM, Ben Campbell wrote: > > On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" wrote: > >> Hi, >> >> the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a minimum set of supported types inside the Message/CPIM wrappers. >> >> While I was replying to Stephen Farrell's IESG review, he had a question, and that one brought me another one. I am seeking advice as for how to proceed. >> >> So, here are the questions: >> >> 1) Version -16 of the draft is a bit silent with respect 'accept-wrapped-types. I first proposed these two paragraphs to be added to version -17, however, I have concerns with one of them (see below). >> >> It is RECOMMENDED that participant endpoints >> add an 'accept-wrapped-types' attribute to the MSRP 'message' media >> line in SDP, where the supported wrapped types are declared, as per >> RFC 4975 procedures [RFC4975]. >> >> The conference focus SHOULD also add an 'accept-wrapped-types' >> attribute to the MSRP message media line in SDP containing the >> supported wrapped types. >> >> My question is... does the conference focus need to add an 'accept-wrapped-types'? The MSRP switch never interprets the actual payload contents, so, for the MSRP switch, the actual payload in instant messages is transparent. So, why should the MSRP switch care? Why should the focus add an 'accept-wrapped-types' at all? >> >> I propose to replace the initially proposed "SHOULD" with a "MAY" in the previous paragraph. > > I concur. It could use this to express policy about what types it allows, but it could just set it to "*" if it doesn't care. +1 > Do we need to talk about what happens if a _recipient_ does not support a type? I suppose the focus could set accept-wrapped-types based on what all the participants have expressed--but that sounds like a recipe for re-invite storms. The focus could send a 415 response to any type where it knows that that one or more recipients cannot accept it. Isn't that what is discussed below? >> 2) Stephen Farrel is questioning what should the MSRP switch do if one sender sends an instant message to the chat room, the message containing a type (inside Message/CPIM) that not all the recipients can understand. In other words, the MSRP switch/focus has received SDP indicating that an endpoint supports types A, B, and C. If another participant sends a message with type D, what should the MSRP switch do? >> >> Possibilities include: >> a) Do nothing; forward the message to D, he should deal with the issue. I don't like this, because it is bypassing the MSRP accept-* negotiation. >> >> b) Do not forward the message to this user, but forward to others who accept this type. It is possible that the MSRP switch injects a warning instant message to the sender, indicating this condition. >> >> c) Reject the message to the sender (i.e., do not forward to any user). I don't like this option either, because the poor sender has done nothing wrong. Additionally, this is the dictatorship of the minority (a few people who do not support a type that will be supported by the majority will impose their rules). And it will be so easy to kill a chat room by just logging in supporting only weird type that none else supports. >> >> So, probably b) is the less worst of all. Comments? >> > > See my previous comment. > > I'm on the fence between B and C. It seems like the undetermined state of "some recipients got it but others didn't" is one of the worst outcomes. I'm not sure I agree about the DoS issue--If a participant wants to screw with the conference, there's lots of other ways he can do so. I prefer B to C. Otherwise you have given each endpoint a veto over what can be exchanged. In the extreme, one endpoint could indicate it doesn't support either plain text or html and effectively shut down the chatroom. It is however unpleasant for the sender not to know that some recipients didn't get his message. Perhaps the focus could send a message back to the sender indicating that some recipients couldn't receive his message. But this could get tiresome if you get this for every message you send. And it's hard to decide on what the message type and content should be. I think it is better to leave this as an implementation issue rather than a standards issue. > Another option would be to push a warning to the recipient saying that the someone had sent a type that he had not expressed support for. This has the same issues as sending a message back to the sender. And I think I prefer the same solution - leave it as an implementation issue. Perhaps for both, the draft can carry a note to implementers that they might want to consider this. >> I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types. > > If necessary, we could mandate a must-support leaf type (but I'm not sure if I want to go there.) I guess if anything it would be text/plain. But that might exclude certain specialized conferences where the messages are consumed by automata rather than displayed. (E.g. game systems.) Again I think it is sufficient as an implementation issue. Thanks, Paul >> Additionally, I expect implementations to add a "*" to indicate support for additional types that have not been explicitly listed, in which case, the MSRP switch will not do any filter, and it is about the endpoint to render the content or not. > > What happens if the recipient sends a 415 response? I guess it's like any other error. That means the sender doesn't learn about it unless the switch synthesis some sort of warning, right? > > I also wonder if switches and/or chat participants should be a little less generous about what types they accept in a chat. Otherwise, this starts to look like a file transfer exploder :-) > > >> >> Comments? >> >> BR, >> >> Miguel >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Tue Sep 11 09:06:28 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA1621F864A for ; Tue, 11 Sep 2012 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cBotcO9qZjZ for ; Tue, 11 Sep 2012 09:06:28 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4621F8611 for ; Tue, 11 Sep 2012 09:06:27 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BG6OJK046501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 11:06:25 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504F59A3.9060909@alum.mit.edu> Date: Tue, 11 Sep 2012 11:06:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0FEA7F94-13E3-4A19-ACD9-E43AACDF3BF4@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 16:06:29 -0000 On Sep 11, 2012, at 10:32 AM, Paul Kyzivat = wrote: > On 9/11/12 10:23 AM, Ben Campbell wrote: >>=20 >> On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" = wrote: >>=20 >>> Hi, >>>=20 >>> the chat draft uses the 'accept-wrapped-types' in SDP for = negotiating a minimum set of supported types inside the Message/CPIM = wrappers. >>>=20 >>> While I was replying to Stephen Farrell's IESG review, he had a = question, and that one brought me another one. I am seeking advice as = for how to proceed. >>>=20 >>> So, here are the questions: >>>=20 >>> 1) Version -16 of the draft is a bit silent with respect = 'accept-wrapped-types. I first proposed these two paragraphs to be added = to version -17, however, I have concerns with one of them (see below). >>>=20 >>> It is RECOMMENDED that participant endpoints >>> add an 'accept-wrapped-types' attribute to the MSRP 'message' = media >>> line in SDP, where the supported wrapped types are declared, as = per >>> RFC 4975 procedures [RFC4975]. >>>=20 >>> The conference focus SHOULD also add an 'accept-wrapped-types' >>> attribute to the MSRP message media line in SDP containing the >>> supported wrapped types. >>>=20 >>> My question is... does the conference focus need to add an = 'accept-wrapped-types'? The MSRP switch never interprets the actual = payload contents, so, for the MSRP switch, the actual payload in instant = messages is transparent. So, why should the MSRP switch care? Why should = the focus add an 'accept-wrapped-types' at all? >>>=20 >>> I propose to replace the initially proposed "SHOULD" with a "MAY" in = the previous paragraph. >>=20 >> I concur. It could use this to express policy about what types it = allows, but it could just set it to "*" if it doesn't care. >=20 > +1 >=20 >> Do we need to talk about what happens if a _recipient_ does not = support a type? I suppose the focus could set accept-wrapped-types based = on what all the participants have expressed--but that sounds like a = recipe for re-invite storms. The focus could send a 415 response to any = type where it knows that that one or more recipients cannot accept it. >=20 > Isn't that what is discussed below? Yep, reading linearly :-) >=20 >>> 2) Stephen Farrel is questioning what should the MSRP switch do if = one sender sends an instant message to the chat room, the message = containing a type (inside Message/CPIM) that not all the recipients can = understand. In other words, the MSRP switch/focus has received SDP = indicating that an endpoint supports types A, B, and C. If another = participant sends a message with type D, what should the MSRP switch do? >>>=20 >>> Possibilities include: >>> a) Do nothing; forward the message to D, he should deal with the = issue. I don't like this, because it is bypassing the MSRP accept-* = negotiation. >>>=20 >>> b) Do not forward the message to this user, but forward to others = who accept this type. It is possible that the MSRP switch injects a = warning instant message to the sender, indicating this condition. >>>=20 >>> c) Reject the message to the sender (i.e., do not forward to any = user). I don't like this option either, because the poor sender has done = nothing wrong. Additionally, this is the dictatorship of the minority (a = few people who do not support a type that will be supported by the = majority will impose their rules). And it will be so easy to kill a chat = room by just logging in supporting only weird type that none else = supports. >>>=20 >>> So, probably b) is the less worst of all. Comments? >>>=20 >>=20 >> See my previous comment. >>=20 >> I'm on the fence between B and C. It seems like the undetermined = state of "some recipients got it but others didn't" is one of the worst = outcomes. I'm not sure I agree about the DoS issue--If a participant = wants to screw with the conference, there's lots of other ways he can do = so. >=20 > I prefer B to C. Otherwise you have given each endpoint a veto over = what can be exchanged. In the extreme, one endpoint could indicate it = doesn't support either plain text or html and effectively shut down the = chatroom. >=20 > It is however unpleasant for the sender not to know that some = recipients didn't get his message. >=20 > Perhaps the focus could send a message back to the sender indicating = that some recipients couldn't receive his message. But this could get = tiresome if you get this for every message you send. And it's hard to = decide on what the message type and content should be. I think it is = better to leave this as an implementation issue rather than a standards = issue. >=20 >> Another option would be to push a warning to the recipient saying = that the someone had sent a type that he had not expressed support for. >=20 > This has the same issues as sending a message back to the sender. And = I think I prefer the same solution - leave it as an implementation = issue. >=20 > Perhaps for both, the draft can carry a note to implementers that they = might want to consider this. I can live with that. >=20 >>> I also want to highlight that this is a bit theoretical problem. I = expect most implementations to support all commonly known types. >>=20 >> If necessary, we could mandate a must-support leaf type (but I'm not = sure if I want to go there.) >=20 > I guess if anything it would be text/plain. But that might exclude = certain specialized conferences where the messages are consumed by = automata rather than displayed. (E.g. game systems.) >=20 > Again I think it is sufficient as an implementation issue. >=20 > Thanks, > Paul >=20 >>> Additionally, I expect implementations to add a "*" to indicate = support for additional types that have not been explicitly listed, in = which case, the MSRP switch will not do any filter, and it is about the = endpoint to render the content or not. >>=20 >> What happens if the recipient sends a 415 response? I guess it's like = any other error. That means the sender doesn't learn about it unless the = switch synthesis some sort of warning, right? >>=20 >> I also wonder if switches and/or chat participants should be a little = less generous about what types they accept in a chat. Otherwise, this = starts to look like a file transfer exploder :-) >>=20 >>=20 >>>=20 >>> Comments? >>>=20 >>> BR, >>>=20 >>> Miguel >>>=20 >>> -- >>> Miguel A. Garcia >>> +34-91-339-3608 >>> Ericsson Spain >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From eburger@standardstrack.com Tue Sep 11 11:17:01 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861CE21F8682 for ; Tue, 11 Sep 2012 11:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5rsYGSHE+1g for ; Tue, 11 Sep 2012 11:17:00 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 184FB21F867A for ; Tue, 11 Sep 2012 11:16:59 -0700 (PDT) Received: from 234.sub-174-238-196.myvzw.com ([174.238.196.234]:2840 helo=biz104.inmotionhosting.com) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TBV0u-000627-5s; Tue, 11 Sep 2012 11:16:45 -0700 Message-ID: From: "Eric Burger" To: pkyzivat@alum.mit.edu, simple@ietf.org Date: Tue, 11 Sep 2012 13:17:11 -0500 X-Mailer: Motorola android mail 1.0 MIME-Version: 1.0 X-Priority: 3 References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> In-Reply-To: <504F59A3.9060909@alum.mit.edu> Content-Type: multipart/alternative; boundary="Motorola-A-Mail-teFbaT-dujDJDOmx" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:17:01 -0000 --Motorola-A-Mail-teFbaT-dujDJDOmx Content-Type: text/plain; Format="Flowed"; DelSp="Yes"; charset="US-ASCII" Content-Transfer-Encoding: 7bit We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice). -- Sent from my mobile device. Thanks be to lemonade! http://www.standardstrack.com/ietf/lemonade/ -----Original message----- From: Paul Kyzivat To: simple@ietf.org Sent: Tue, Sep 11, 2012 15:33:00 GMT+00:00 Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' On 9/11/12 10:23 AM, Ben Campbell wrote: > > On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" wrote: > >> Hi, >> >> the chat draft uses the 'accept-wrapped-types' in SDP for negotiating a minimum set of supported types inside the Message/CPIM wrappers. >> >> While I was replying to Stephen Farrell's IESG review, he had a question, and that one brought me another one. I am seeking advice as for how to proceed. >> >> So, here are the questions: >> >> 1) Version -16 of the draft is a bit silent with respect 'accept-wrapped-types. I first proposed these two paragraphs to be added to version -17, however, I have concerns with one of them (see below). >> >> It is RECOMMENDED that participant endpoints >> add an 'accept-wrapped-types' attribute to the MSRP 'message' media >> line in SDP, where the supported wrapped types are declared, as per >> RFC 4975 procedures [RFC4975]. >> >> The conference focus SHOULD also add an 'accept-wrapped-types' >> attribute to the MSRP message media line in SDP containing the >> supported wrapped types. >> >> My question is... does the conference focus need to add an 'accept-wrapped-types'? The MSRP switch never interprets the actual payload contents, so, for the MSRP switch, the actual payload in instant messages is transparent. So, why should the MSRP switch care? Why should the focus add an 'accept-wrapped-types' at all? >> >> I propose to replace the initially proposed "SHOULD" with a "MAY" in the previous paragraph. > > I concur. It could use this to express policy about what types it allows, but it could just set it to "*" if it doesn't care. +1 > Do we need to talk about what happens if a _recipient_ does not support a type? I suppose the focus could set accept-wrapped-types based on what all the participants have expressed--but that sounds like a recipe for re-invite storms. The focus could send a 415 response to any type where it knows that that one or more recipients cannot accept it. Isn't that what is discussed below? >> 2) Stephen Farrel is questioning what should the MSRP switch do if one sender sends an instant message to the chat room, the message containing a type (inside Message/CPIM) that not all the recipients can understand. In other words, the MSRP switch/focus has received SDP indicating that an endpoint supports types A, B, and C. If another participant sends a message with type D, what should the MSRP switch do? >> >> Possibilities include: >> a) Do nothing; forward the message to D, he should deal with the issue. I don't like this, because it is bypassing the MSRP accept-* negotiation. >> >> b) Do not forward the message to this user, but forward to others who accept this type. It is possible that the MSRP switch injects a warning instant message to the sender, indicating this condition. >> >> c) Reject the message to the sender (i.e., do not forward to any user). I don't like this option either, because the poor sender has done nothing wrong. Additionally, this is the dictatorship of the minority (a few people who do not support a type that will be supported by the majority will impose their rules). And it will be so easy to kill a chat room by just logging in supporting only weird type that none else supports. >> >> So, probably b) is the less worst of all. Comments? >> > > See my previous comment. > > I'm on the fence between B and C. It seems like the undetermined state of "some recipients got it but others didn't" is one of the worst outcomes. I'm not sure I agree about the DoS issue--If a participant wants to screw with the conference, there's lots of other ways he can do so. I prefer B to C. Otherwise you have given each endpoint a veto over what can be exchanged. In the extreme, one endpoint could indicate it doesn't support either plain text or html and effectively shut down the chatroom. It is however unpleasant for the sender not to know that some recipients didn't get his message. Perhaps the focus could send a message back to the sender indicating that some recipients couldn't receive his message. But this could get tiresome if you get this for every message you send. And it's hard to decide on what the message type and content should be. I think it is better to leave this as an implementation issue rather than a standards issue. > Another option would be to push a warning to the recipient saying that the someone had sent a type that he had not expressed support for. This has the same issues as sending a message back to the sender. And I think I prefer the same solution - leave it as an implementation issue. Perhaps for both, the draft can carry a note to implementers that they might want to consider this. >> I also want to highlight that this is a bit theoretical problem. I expect most implementations to support all commonly known types. > > If necessary, we could mandate a must-support leaf type (but I'm not sure if I want to go there.) I guess if anything it would be text/plain. But that might exclude certain specialized conferences where the messages are consumed by automata rather than displayed. (E.g. game systems.) Again I think it is sufficient as an implementation issue. Thanks, Paul >> Additionally, I expect implementations to add a "*" to indicate support for additional types that have not been explicitly listed, in which case, the MSRP switch will not do any filter, and it is about the endpoint to render the content or not. > > What happens if the recipient sends a 415 response? I guess it's like any other error. That means the sender doesn't learn about it unless the switch synthesis some sort of warning, right? > > I also wonder if switches and/or chat participants should be a little less generous about what types they accept in a chat. Otherwise, this starts to look like a file transfer exploder :-) > > >> >> Comments? >> >> BR, >> >> Miguel >> >> -- >> Miguel A. Garcia >> +34-91-339-3608 >> Ericsson Spain >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple --Motorola-A-Mail-teFbaT-dujDJDOmx Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PHN0eWxlIHR5cGU9InRleHQvY3NzIj5ib2R5IHt3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IGJhY2tncm91bmQtY29sb3I6I2ZmZmZmZjt9PC9zdHlsZT48L2hlYWQ+PGJvZHk+PGRp diBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweCI+V2Ugc29s dmVkIHRoZSB0aHJlZS1vdXQtb2YtZm91ciBlbmRwb2ludHMgdW5kZXJzdGFuZCBEIHByb2JsZW0g eWVhcnMgYWdvLiBTZWUgUkZDIDM0NTkuIFVBQydzIG1hcmsgdGhlIG1lc3NhZ2UgYXMgY3JpdGlj YWwgKGdldHMgcmVqZWN0ZWQgaWYgdW5hYmxlIHRvIHNlbmQgdG8gYWxsIHJlY2lwaWVudHMpIG9y IG5vdCBjcml0aWNhbCAoZ2V0cyBzaWxlbnRseSBkcm9wcGVkIG9yIGRlc3RpbmF0aW9uIGdldHMg YSBub3RpY2UpLjxicj48YnI+LS08YnI+U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5r cyBiZSB0byBsZW1vbmFkZSEgPGEgaHJlZj0iaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20v aWV0Zi9sZW1vbmFkZS8iPmh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25h ZGUvPC9hPjwvZGl2Pjxicj48YnI+LS0tLS1PcmlnaW5hbCBtZXNzYWdlLS0tLS08YnI+PGJsb2Nr cXVvdGUgc3R5bGU9IjsgYm9yZGVyLWxlZnQ6IDJweCBzb2xpZCByZ2IoMTYsIDE2LCAyNTUpOyBt YXJnaW4tbGVmdDogNXB4OyBwYWRkaW5nLWxlZnQ6IDVweDsiPjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHgiPjxiPkZyb206IDwvYj5QYXVsIEt5eml2 YXQgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs8Yj48YnI+VG86IDwvYj5zaW1wbGVAaWV0 Zi5vcmc8Yj48YnI+U2VudDogPC9iPlR1ZSwgU2VwIDExLCAyMDEyIDE1OjMzOjAwIEdNVCswMDow MDxiPjxicj5TdWJqZWN0OiA8L2I+UmU6IFtTaW1wbGVdIENoYXQ6IHF1ZXN0aW9ucyBvbiAnYWNj ZXB0LXdyYXBwZWQtdHlwZXMnPGJyPjxicj48L2Rpdj5PbiA5LzExLzEyIDEwOjIzIEFNLCBCZW4g Q2FtcGJlbGwgd3JvdGU6PGJyPj48YnI+PiBPbiBTZXAgMTEsIDIwMTIsIGF0IDc6NDYgQU0sICJN aWd1ZWwgQS4gR2FyY2lhIiA8TWlndWVsLkEuR2FyY2lhQGVyaWNzc29uLmNvbT4gd3JvdGU6PGJy Pj48YnI+Pj4gSGksPGJyPj4+PGJyPj4+IHRoZSBjaGF0IGRyYWZ0IHVzZXMgdGhlICdhY2NlcHQt d3JhcHBlZC10eXBlcycgaW4gU0RQIGZvciBuZWdvdGlhdGluZyBhIG1pbmltdW0gc2V0IG9mIHN1 cHBvcnRlZCB0eXBlcyBpbnNpZGUgdGhlIE1lc3NhZ2UvQ1BJTSB3cmFwcGVycy48YnI+Pj48YnI+ Pj4gV2hpbGUgSSB3YXMgcmVwbHlpbmcgdG8gU3RlcGhlbiBGYXJyZWxsJ3MgSUVTRyByZXZpZXcs IGhlIGhhZCBhIHF1ZXN0aW9uLCBhbmQgdGhhdCBvbmUgYnJvdWdodCBtZSBhbm90aGVyIG9uZS4g SSBhbSBzZWVraW5nIGFkdmljZSBhcyBmb3IgaG93IHRvIHByb2NlZWQuPGJyPj4+PGJyPj4+IFNv LCBoZXJlIGFyZSB0aGUgcXVlc3Rpb25zOjxicj4+Pjxicj4+PiAxKSBWZXJzaW9uIC0xNiBvZiB0 aGUgZHJhZnQgaXMgYSBiaXQgc2lsZW50IHdpdGggcmVzcGVjdCAnYWNjZXB0LXdyYXBwZWQtdHlw ZXMuIEkgZmlyc3QgcHJvcG9zZWQgdGhlc2UgdHdvIHBhcmFncmFwaHMgdG8gYmUgYWRkZWQgdG8g dmVyc2lvbiAtMTcsIGhvd2V2ZXIsIEkgaGF2ZSBjb25jZXJucyB3aXRoIG9uZSBvZiB0aGVtIChz ZWUgYmVsb3cpLjxicj4+Pjxicj4+PiAgICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHBhcnRpY2lw YW50IGVuZHBvaW50czxicj4+PiAgICBhZGQgYW4gJ2FjY2VwdC13cmFwcGVkLXR5cGVzJyBhdHRy aWJ1dGUgdG8gdGhlIE1TUlAgJ21lc3NhZ2UnIG1lZGlhPGJyPj4+ICAgIGxpbmUgaW4gU0RQLCB3 aGVyZSB0aGUgc3VwcG9ydGVkIHdyYXBwZWQgdHlwZXMgYXJlIGRlY2xhcmVkLCBhcyBwZXI8YnI+ Pj4gICAgUkZDIDQ5NzUgcHJvY2VkdXJlcyBbUkZDNDk3NV0uPGJyPj4+PGJyPj4+ICAgIFRoZSBj b25mZXJlbmNlIGZvY3VzIFNIT1VMRCBhbHNvIGFkZCBhbiAnYWNjZXB0LXdyYXBwZWQtdHlwZXMn PGJyPj4+ICAgIGF0dHJpYnV0ZSB0byB0aGUgTVNSUCBtZXNzYWdlIG1lZGlhIGxpbmUgaW4gU0RQ IGNvbnRhaW5pbmcgdGhlPGJyPj4+ICAgIHN1cHBvcnRlZCB3cmFwcGVkIHR5cGVzLjxicj4+Pjxi cj4+PiBNeSBxdWVzdGlvbiBpcy4uLiBkb2VzIHRoZSBjb25mZXJlbmNlIGZvY3VzIG5lZWQgdG8g YWRkIGFuICdhY2NlcHQtd3JhcHBlZC10eXBlcyc/IFRoZSBNU1JQIHN3aXRjaCBuZXZlciBpbnRl cnByZXRzIHRoZSBhY3R1YWwgcGF5bG9hZCBjb250ZW50cywgc28sIGZvciB0aGUgTVNSUCBzd2l0 Y2gsIHRoZSBhY3R1YWwgcGF5bG9hZCBpbiBpbnN0YW50IG1lc3NhZ2VzIGlzIHRyYW5zcGFyZW50 LiBTbywgd2h5IHNob3VsZCB0aGUgTVNSUCBzd2l0Y2ggY2FyZT8gV2h5IHNob3VsZCB0aGUgZm9j dXMgYWRkIGFuICdhY2NlcHQtd3JhcHBlZC10eXBlcycgYXQgYWxsPzxicj4+Pjxicj4+PiBJIHBy b3Bvc2UgdG8gcmVwbGFjZSB0aGUgaW5pdGlhbGx5IHByb3Bvc2VkICJTSE9VTEQiIHdpdGggYSAi TUFZIiBpbiB0aGUgcHJldmlvdXMgcGFyYWdyYXBoLjxicj4+PGJyPj4gSSBjb25jdXIuIEl0IGNv dWxkIHVzZSB0aGlzIHRvIGV4cHJlc3MgcG9saWN5IGFib3V0IHdoYXQgdHlwZXMgaXQgYWxsb3dz LCBidXQgaXQgY291bGQganVzdCBzZXQgaXQgdG8gIioiIGlmIGl0IGRvZXNuJ3QgY2FyZS48YnI+ PGJyPisxPGJyPjxicj4+IERvIHdlIG5lZWQgdG8gdGFsayBhYm91dCB3aGF0IGhhcHBlbnMgaWYg YSBfcmVjaXBpZW50XyBkb2VzIG5vdCBzdXBwb3J0IGEgdHlwZT8gSSBzdXBwb3NlIHRoZSBmb2N1 cyBjb3VsZCBzZXQgYWNjZXB0LXdyYXBwZWQtdHlwZXMgYmFzZWQgb24gd2hhdCBhbGwgdGhlIHBh cnRpY2lwYW50cyBoYXZlIGV4cHJlc3NlZC0tYnV0IHRoYXQgc291bmRzIGxpa2UgYSByZWNpcGUg Zm9yIHJlLWludml0ZSBzdG9ybXMuIFRoZSBmb2N1cyBjb3VsZCBzZW5kIGEgNDE1IHJlc3BvbnNl IHRvIGFueSB0eXBlIHdoZXJlIGl0IGtub3dzIHRoYXQgdGhhdCBvbmUgb3IgbW9yZSByZWNpcGll bnRzIGNhbm5vdCBhY2NlcHQgaXQuPGJyPjxicj5Jc24ndCB0aGF0IHdoYXQgaXMgZGlzY3Vzc2Vk IGJlbG93Pzxicj48YnI+Pj4gMikgU3RlcGhlbiBGYXJyZWwgaXMgcXVlc3Rpb25pbmcgd2hhdCBz aG91bGQgdGhlIE1TUlAgc3dpdGNoIGRvIGlmIG9uZSBzZW5kZXIgc2VuZHMgYW4gaW5zdGFudCBt ZXNzYWdlIHRvIHRoZSBjaGF0IHJvb20sIHRoZSBtZXNzYWdlIGNvbnRhaW5pbmcgYSB0eXBlIChp bnNpZGUgTWVzc2FnZS9DUElNKSB0aGF0IG5vdCBhbGwgdGhlIHJlY2lwaWVudHMgY2FuIHVuZGVy c3RhbmQuIEluIG90aGVyIHdvcmRzLCB0aGUgTVNSUCBzd2l0Y2gvZm9jdXMgaGFzIHJlY2VpdmVk IFNEUCBpbmRpY2F0aW5nIHRoYXQgYW4gZW5kcG9pbnQgc3VwcG9ydHMgdHlwZXMgQSwgQiwgYW5k IEMuIElmIGFub3RoZXIgcGFydGljaXBhbnQgc2VuZHMgYSBtZXNzYWdlIHdpdGggdHlwZSBELCB3 aGF0IHNob3VsZCB0aGUgTVNSUCBzd2l0Y2ggZG8/PGJyPj4+PGJyPj4+IFBvc3NpYmlsaXRpZXMg aW5jbHVkZTo8YnI+Pj4gYSkgRG8gbm90aGluZzsgZm9yd2FyZCB0aGUgbWVzc2FnZSB0byBELCBo ZSBzaG91bGQgZGVhbCB3aXRoIHRoZSBpc3N1ZS4gSSBkb24ndCBsaWtlIHRoaXMsIGJlY2F1c2Ug aXQgaXMgYnlwYXNzaW5nIHRoZSBNU1JQIGFjY2VwdC0qIG5lZ290aWF0aW9uLjxicj4+Pjxicj4+ PiBiKSBEbyBub3QgZm9yd2FyZCB0aGUgbWVzc2FnZSB0byB0aGlzIHVzZXIsIGJ1dCBmb3J3YXJk IHRvIG90aGVycyB3aG8gYWNjZXB0IHRoaXMgdHlwZS4gSXQgaXMgcG9zc2libGUgdGhhdCB0aGUg TVNSUCBzd2l0Y2ggaW5qZWN0cyBhIHdhcm5pbmcgaW5zdGFudCBtZXNzYWdlIHRvIHRoZSBzZW5k ZXIsIGluZGljYXRpbmcgdGhpcyBjb25kaXRpb24uPGJyPj4+PGJyPj4+IGMpIFJlamVjdCB0aGUg bWVzc2FnZSB0byB0aGUgc2VuZGVyIChpLmUuLCBkbyBub3QgZm9yd2FyZCB0byBhbnkgdXNlciku IEkgZG9uJ3QgbGlrZSB0aGlzIG9wdGlvbiBlaXRoZXIsIGJlY2F1c2UgdGhlIHBvb3Igc2VuZGVy IGhhcyBkb25lIG5vdGhpbmcgd3JvbmcuIEFkZGl0aW9uYWxseSwgdGhpcyBpcyB0aGUgZGljdGF0 b3JzaGlwIG9mIHRoZSBtaW5vcml0eSAoYSBmZXcgcGVvcGxlIHdobyBkbyBub3Qgc3VwcG9ydCBh IHR5cGUgdGhhdCB3aWxsIGJlIHN1cHBvcnRlZCBieSB0aGUgbWFqb3JpdHkgd2lsbCBpbXBvc2Ug dGhlaXIgcnVsZXMpLiBBbmQgaXQgd2lsbCBiZSBzbyBlYXN5IHRvIGtpbGwgYSBjaGF0IHJvb20g YnkganVzdCBsb2dnaW5nIGluIHN1cHBvcnRpbmcgb25seSB3ZWlyZCB0eXBlIHRoYXQgbm9uZSBl bHNlIHN1cHBvcnRzLjxicj4+Pjxicj4+PiBTbywgcHJvYmFibHkgYikgaXMgdGhlIGxlc3Mgd29y c3Qgb2YgYWxsLiBDb21tZW50cz88YnI+Pj48YnI+Pjxicj4+IFNlZSBteSBwcmV2aW91cyBjb21t ZW50Ljxicj4+PGJyPj4gSSdtIG9uIHRoZSBmZW5jZSBiZXR3ZWVuIEIgYW5kIEMuIEl0IHNlZW1z IGxpa2UgdGhlIHVuZGV0ZXJtaW5lZCBzdGF0ZSBvZiAic29tZSByZWNpcGllbnRzIGdvdCBpdCBi dXQgb3RoZXJzIGRpZG4ndCIgaXMgb25lIG9mIHRoZSB3b3JzdCBvdXRjb21lcy4gSSdtIG5vdCBz dXJlIEkgYWdyZWUgYWJvdXQgdGhlIERvUyBpc3N1ZS0tSWYgYSBwYXJ0aWNpcGFudCB3YW50cyB0 byBzY3JldyB3aXRoIHRoZSBjb25mZXJlbmNlLCB0aGVyZSdzIGxvdHMgb2Ygb3RoZXIgd2F5cyBo ZSBjYW4gZG8gc28uPGJyPjxicj5JIHByZWZlciBCIHRvIEMuIE90aGVyd2lzZSB5b3UgaGF2ZSBn aXZlbiBlYWNoIGVuZHBvaW50IGEgdmV0byBvdmVyIHdoYXQgPGJyPmNhbiBiZSBleGNoYW5nZWQu IEluIHRoZSBleHRyZW1lLCBvbmUgZW5kcG9pbnQgY291bGQgaW5kaWNhdGUgaXQgZG9lc24ndCA8 YnI+c3VwcG9ydCBlaXRoZXIgcGxhaW4gdGV4dCBvciBodG1sIGFuZCBlZmZlY3RpdmVseSBzaHV0 IGRvd24gdGhlIGNoYXRyb29tLjxicj48YnI+SXQgaXMgaG93ZXZlciB1bnBsZWFzYW50IGZvciB0 aGUgc2VuZGVyIG5vdCB0byBrbm93IHRoYXQgc29tZSByZWNpcGllbnRzIDxicj5kaWRuJ3QgZ2V0 IGhpcyBtZXNzYWdlLjxicj48YnI+UGVyaGFwcyB0aGUgZm9jdXMgY291bGQgc2VuZCBhIG1lc3Nh Z2UgYmFjayB0byB0aGUgc2VuZGVyIGluZGljYXRpbmcgPGJyPnRoYXQgc29tZSByZWNpcGllbnRz IGNvdWxkbid0IHJlY2VpdmUgaGlzIG1lc3NhZ2UuIEJ1dCB0aGlzIGNvdWxkIGdldCA8YnI+dGly ZXNvbWUgaWYgeW91IGdldCB0aGlzIGZvciBldmVyeSBtZXNzYWdlIHlvdSBzZW5kLiBBbmQgaXQn cyBoYXJkIHRvIDxicj5kZWNpZGUgb24gd2hhdCB0aGUgbWVzc2FnZSB0eXBlIGFuZCBjb250ZW50 IHNob3VsZCBiZS4gSSB0aGluayBpdCBpcyA8YnI+YmV0dGVyIHRvIGxlYXZlIHRoaXMgYXMgYW4g aW1wbGVtZW50YXRpb24gaXNzdWUgcmF0aGVyIHRoYW4gYSBzdGFuZGFyZHMgPGJyPmlzc3VlLjxi cj48YnI+PiBBbm90aGVyIG9wdGlvbiB3b3VsZCBiZSB0byBwdXNoIGEgd2FybmluZyB0byB0aGUg cmVjaXBpZW50IHNheWluZyB0aGF0IHRoZSBzb21lb25lIGhhZCBzZW50IGEgdHlwZSB0aGF0IGhl IGhhZCBub3QgZXhwcmVzc2VkIHN1cHBvcnQgZm9yLjxicj48YnI+VGhpcyBoYXMgdGhlIHNhbWUg aXNzdWVzIGFzIHNlbmRpbmcgYSBtZXNzYWdlIGJhY2sgdG8gdGhlIHNlbmRlci4gQW5kIEkgPGJy PnRoaW5rIEkgcHJlZmVyIHRoZSBzYW1lIHNvbHV0aW9uIC0gbGVhdmUgaXQgYXMgYW4gaW1wbGVt ZW50YXRpb24gaXNzdWUuPGJyPjxicj5QZXJoYXBzIGZvciBib3RoLCB0aGUgZHJhZnQgY2FuIGNh cnJ5IGEgbm90ZSB0byBpbXBsZW1lbnRlcnMgdGhhdCB0aGV5IDxicj5taWdodCB3YW50IHRvIGNv bnNpZGVyIHRoaXMuPGJyPjxicj4+PiBJIGFsc28gd2FudCB0byBoaWdobGlnaHQgdGhhdCB0aGlz IGlzIGEgYml0IHRoZW9yZXRpY2FsIHByb2JsZW0uIEkgZXhwZWN0IG1vc3QgaW1wbGVtZW50YXRp b25zIHRvIHN1cHBvcnQgYWxsIGNvbW1vbmx5IGtub3duIHR5cGVzLjxicj4+PGJyPj4gSWYgbmVj ZXNzYXJ5LCB3ZSBjb3VsZCBtYW5kYXRlIGEgbXVzdC1zdXBwb3J0IGxlYWYgdHlwZSAoYnV0IEkn bSBub3Qgc3VyZSBpZiBJIHdhbnQgdG8gZ28gdGhlcmUuKTxicj48YnI+SSBndWVzcyBpZiBhbnl0 aGluZyBpdCB3b3VsZCBiZSB0ZXh0L3BsYWluLiBCdXQgdGhhdCBtaWdodCBleGNsdWRlIDxicj5j ZXJ0YWluIHNwZWNpYWxpemVkIGNvbmZlcmVuY2VzIHdoZXJlIHRoZSBtZXNzYWdlcyBhcmUgY29u c3VtZWQgYnkgPGJyPmF1dG9tYXRhIHJhdGhlciB0aGFuIGRpc3BsYXllZC4gKEUuZy4gZ2FtZSBz eXN0ZW1zLik8YnI+PGJyPkFnYWluIEkgdGhpbmsgaXQgaXMgc3VmZmljaWVudCBhcyBhbiBpbXBs ZW1lbnRhdGlvbiBpc3N1ZS48YnI+PGJyPglUaGFua3MsPGJyPglQYXVsPGJyPjxicj4+PiBBZGRp dGlvbmFsbHksIEkgZXhwZWN0IGltcGxlbWVudGF0aW9ucyB0byBhZGQgYSAiKiIgdG8gaW5kaWNh dGUgc3VwcG9ydCBmb3IgYWRkaXRpb25hbCB0eXBlcyB0aGF0IGhhdmUgbm90IGJlZW4gZXhwbGlj aXRseSBsaXN0ZWQsIGluIHdoaWNoIGNhc2UsIHRoZSBNU1JQIHN3aXRjaCB3aWxsIG5vdCBkbyBh bnkgZmlsdGVyLCBhbmQgaXQgaXMgYWJvdXQgdGhlIGVuZHBvaW50IHRvIHJlbmRlciB0aGUgY29u dGVudCBvciBub3QuPGJyPj48YnI+PiBXaGF0IGhhcHBlbnMgaWYgdGhlIHJlY2lwaWVudCBzZW5k cyBhIDQxNSByZXNwb25zZT8gSSBndWVzcyBpdCdzIGxpa2UgYW55IG90aGVyIGVycm9yLiBUaGF0 IG1lYW5zIHRoZSBzZW5kZXIgZG9lc24ndCBsZWFybiBhYm91dCBpdCB1bmxlc3MgdGhlIHN3aXRj aCBzeW50aGVzaXMgc29tZSBzb3J0IG9mIHdhcm5pbmcsIHJpZ2h0Pzxicj4+PGJyPj4gSSBhbHNv IHdvbmRlciBpZiBzd2l0Y2hlcyBhbmQvb3IgY2hhdCBwYXJ0aWNpcGFudHMgc2hvdWxkIGJlIGEg bGl0dGxlIGxlc3MgZ2VuZXJvdXMgYWJvdXQgd2hhdCB0eXBlcyB0aGV5IGFjY2VwdCBpbiBhIGNo YXQuIE90aGVyd2lzZSwgdGhpcyBzdGFydHMgdG8gbG9vayBsaWtlIGEgZmlsZSB0cmFuc2ZlciBl eHBsb2RlciA6LSk8YnI+Pjxicj4+PGJyPj4+PGJyPj4+IENvbW1lbnRzPzxicj4+Pjxicj4+PiBC Uiw8YnI+Pj48YnI+Pj4gICAgICAgICAgTWlndWVsPGJyPj4+PGJyPj4+IC0tPGJyPj4+IE1pZ3Vl bCBBLiBHYXJjaWE8YnI+Pj4gKzM0LTkxLTMzOS0zNjA4PGJyPj4+IEVyaWNzc29uIFNwYWluPGJy Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPj4+ IFNpbXBsZSBtYWlsaW5nIGxpc3Q8YnI+Pj4gU2ltcGxlQGlldGYub3JnPGJyPj4+IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpbXBsZTwvYT48YnI+Pjxicj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPj4gU2ltcGxlIG1haWxp bmcgbGlzdDxicj4+IFNpbXBsZUBpZXRmLm9yZzxicj4+IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpbXBsZTwvYT48YnI+Pjxicj48YnI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+U2ltcGxlIG1haWxpbmcgbGlzdDxicj5TaW1w bGVAaWV0Zi5vcmc8YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaW1wbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ltcGxl PC9hPjxicj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4NCg== --Motorola-A-Mail-teFbaT-dujDJDOmx-- From pkyzivat@alum.mit.edu Tue Sep 11 11:34:59 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3521F854E for ; Tue, 11 Sep 2012 11:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAvDAhRSHfTb for ; Tue, 11 Sep 2012 11:34:57 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 84F1021F84D7 for ; Tue, 11 Sep 2012 11:34:57 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id xntR1j0021GhbT854ub1Rz; Tue, 11 Sep 2012 18:35:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id xubK1j00R3ZTu2S3TubKBJ; Tue, 11 Sep 2012 18:35:19 +0000 Message-ID: <504F844F.5000907@alum.mit.edu> Date: Tue, 11 Sep 2012 14:34:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Eric Burger References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:34:59 -0000 On 9/11/12 2:17 PM, Eric Burger wrote: > We solved the three-out-of-four endpoints understand D problem years > ago. See RFC 3459. UAC's mark the message as critical (gets rejected if > unable to send to all recipients) or not critical (gets silently dropped > or destination gets a notice). Good point. So you are suggesting we assume the use of the Content-Disposition header in the CPIM wrapper? And the default is REQUIRED, so the focus should reject the message if it can't be delivered to all recipients and it *doesn't* contain a c-d of OPTIONAL? That WFM. Thanks, Paul > -- > Sent from my mobile device. Thanks be to lemonade! > http://www.standardstrack.com/ietf/lemonade/ > > > -----Original message----- > > *From: *Paul Kyzivat * > To: *simple@ietf.org* > Sent: *Tue, Sep 11, 2012 15:33:00 GMT+00:00* > Subject: *Re: [Simple] Chat: questions on 'accept-wrapped-types' > > On 9/11/12 10:23 AM, Ben Campbell wrote: > > > > On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" wrote: > > > >> Hi, > >> > >> the chat draft uses the 'accept-wrapped-types' in SDP for > negotiating a minimum set of supported types inside the Message/CPIM > wrappers. > >> > >> While I was replying to Stephen Farrell's IESG review, he had a > question, and that one brought me another one. I am seeking advice > as for how to proceed. > >> > >> So, here are the questions: > >> > >> 1) Version -16 of the draft is a bit silent with respect > 'accept-wrapped-types. I first proposed these two paragraphs to be > added to version -17, however, I have concerns with one of them (see > below). > >> > >> It is RECOMMENDED that participant endpoints > >> add an 'accept-wrapped-types' attribute to the MSRP 'message' media > >> line in SDP, where the supported wrapped types are declared, as per > >> RFC 4975 procedures [RFC4975]. > >> > >> The conference focus SHOULD also add an 'accept-wrapped-types' > >> attribute to the MSRP message media line in SDP containing the > >> supported wrapped types. > >> > >> My question is... does the conference focus need to add an > 'accept-wrapped-types'? The MSRP switch never interprets the actual > payload contents, so, for the MSRP switch, the actual payload in > instant messages is transparent. So, why should the MSRP switch > care? Why should the focus add an 'accept-wrapped-types' at all? > >> > >> I propose to replace the initially proposed "SHOULD" with a > "MAY" in the previous paragraph. > > > > I concur. It could use this to express policy about what types it > allows, but it could just set it to "*" if it doesn't care. > > +1 > > > Do we need to talk about what happens if a _recipient_ does not > support a type? I suppose the focus could set accept-wrapped-types > based on what all the participants have expressed--but that sounds > like a recipe for re-invite storms. The focus could send a 415 > response to any type where it knows that that one or more recipients > cannot accept it. > > Isn't that what is discussed below? > > >> 2) Stephen Farrel is questioning what should the MSRP switch do > if one sender sends an instant message to the chat room, the message > containing a type (inside Message/CPIM) that not all the recipients > can understand. In other words, the MSRP switch/focus has received > SDP indicating that an endpoint supports types A, B, and C. If > another participant sends a message with type D, what should the > MSRP switch do? > >> > >> Possibilities include: > >> a) Do nothing; forward the message to D, he should deal with the > issue. I don't like this, because it is bypassing the MSRP accept-* > negotiation. > >> > >> b) Do not forward the message to this user, but forward to > others who accept this type. It is possible that the MSRP switch > injects a warning instant message to the sender, indicating this > condition. > >> > >> c) Reject the message to the sender (i.e., do not forward to any > user). I don't like this option either, because the poor sender has > done nothing wrong. Additionally, this is the dictatorship of the > minority (a few people who do not support a type that will be > supported by the majority will impose their rules). And it will be > so easy to kill a chat room by just logging in supporting only weird > type that none else supports. > >> > >> So, probably b) is the less worst of all. Comments? > >> > > > > See my previous comment. > > > > I'm on the fence between B and C. It seems like the undetermined > state of "some recipients got it but others didn't" is one of the > worst outcomes. I'm not sure I agree about the DoS issue--If a > participant wants to screw with the conference, there's lots of > other ways he can do so. > > I prefer B to C. Otherwise you have given each endpoint a veto over > what > can be exchanged. In the extreme, one endpoint could indicate it > doesn't > support either plain text or html and effectively shut down the > chatroom. > > It is however unpleasant for the sender not to know that some > recipients > didn't get his message. > > Perhaps the focus could send a message back to the sender indicating > that some recipients couldn't receive his message. But this could get > tiresome if you get this for every message you send. And it's hard to > decide on what the message type and content should be. I think it is > better to leave this as an implementation issue rather than a standards > issue. > > > Another option would be to push a warning to the recipient saying > that the someone had sent a type that he had not expressed support for. > > This has the same issues as sending a message back to the sender. And I > think I prefer the same solution - leave it as an implementation issue. > > Perhaps for both, the draft can carry a note to implementers that they > might want to consider this. > > >> I also want to highlight that this is a bit theoretical problem. > I expect most implementations to support all commonly known types. > > > > If necessary, we could mandate a must-support leaf type (but I'm > not sure if I want to go there.) > > I guess if anything it would be text/plain. But that might exclude > certain specialized conferences where the messages are consumed by > automata rather than displayed. (E.g. game systems.) > > Again I think it is sufficient as an implementation issue. > > Thanks, > Paul > > >> Additionally, I expect implementations to add a "*" to indicate > support for additional types that have not been explicitly listed, > in which case, the MSRP switch will not do any filter, and it is > about the endpoint to render the content or not. > > > > What happens if the recipient sends a 415 response? I guess it's > like any other error. That means the sender doesn't learn about it > unless the switch synthesis some sort of warning, right? > > > > I also wonder if switches and/or chat participants should be a > little less generous about what types they accept in a chat. > Otherwise, this starts to look like a file transfer exploder :-) > > > > > >> > >> Comments? > >> > >> BR, > >> > >> Miguel > >> > >> -- > >> Miguel A. Garcia > >> +34-91-339-3608 > >> Ericsson Spain > >> _______________________________________________ > >> Simple mailing list > >> Simple@ietf.org > >> https://www.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From ben@nostrum.com Tue Sep 11 11:46:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411BF21F8552 for ; Tue, 11 Sep 2012 11:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWaMli+wawDb for ; Tue, 11 Sep 2012 11:46:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C09C221F84DC for ; Tue, 11 Sep 2012 11:46:49 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BIklK9061843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 13:46:47 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Ben Campbell X-Priority: 3 In-Reply-To: Date: Tue, 11 Sep 2012 13:46:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> To: "Eric Burger" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:46:50 -0000 On Sep 11, 2012, at 1:17 PM, "Eric Burger" = wrote: > We solved the three-out-of-four endpoints understand D problem years = ago. See RFC 3459. UAC's mark the message as critical (gets rejected if = unable to send to all recipients) or not critical (gets silently dropped = or destination gets a notice). That's an interesting and likely useful approach. I'm concerned that = it's a bit of feature creep for this draft, though. At least, it's a = non-trivial feature that the working group had not contemplated so far. = Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort = to when we did the delivery status notification work for MESSAGE. Can we live with some implementor guidance that they need to think about = this, and leave a formal solution as future work if anyone wants to do = it? Thanks! Ben. From ben@nostrum.com Tue Sep 11 11:51:15 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFC321F866B for ; Tue, 11 Sep 2012 11:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vGZfGjOJlmC for ; Tue, 11 Sep 2012 11:51:15 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id F34B521F866A for ; Tue, 11 Sep 2012 11:51:14 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BIpDBt062373 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 13:51:13 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=us-ascii From: Ben Campbell X-Priority: 3 In-Reply-To: Date: Tue, 11 Sep 2012 13:51:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> To: "Eric Burger" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org, pkyzivat@alum.mit.edu Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 18:51:15 -0000 On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >=20 > On Sep 11, 2012, at 1:17 PM, "Eric Burger" = wrote: >=20 >> We solved the three-out-of-four endpoints understand D problem years = ago. See RFC 3459. UAC's mark the message as critical (gets rejected if = unable to send to all recipients) or not critical (gets silently dropped = or destination gets a notice). >=20 > That's an interesting and likely useful approach. I'm concerned that = it's a bit of feature creep for this draft, though. At least, it's a = non-trivial feature that the working group had not contemplated so far. = Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort = to when we did the delivery status notification work for MESSAGE. Okay, before anyone jumps on that, on a more careful read of 3459, I = realize it would be less work than DSN. But it's still a substantial new = feature for this late in the draft's life cycle. That doesn't mean we = can't add it if we Really Need It (TM) for the rest of the draft to be = useful. Do we? >=20 > Can we live with some implementor guidance that they need to think = about this, and leave a formal solution as future work if anyone wants = to do it? >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From eburger@standardstrack.com Tue Sep 11 12:10:50 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB921F8697 for ; Tue, 11 Sep 2012 12:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnKwqe6qeBgZ for ; Tue, 11 Sep 2012 12:10:38 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6659621F8682 for ; Tue, 11 Sep 2012 12:10:38 -0700 (PDT) Received: from [65.42.208.133] (port=50755 helo=[10.1.3.159]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TBVqq-0002XF-HU; Tue, 11 Sep 2012 12:10:25 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-132--283751911; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <504F844F.5000907@alum.mit.edu> Date: Tue, 11 Sep 2012 14:10:35 -0500 Message-Id: References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <504F844F.5000907@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:10:50 -0000 --Apple-Mail-132--283751911 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Correct. That makes it backwards-compatible. On Sep 11, 2012, at 1:34 PM, Paul Kyzivat wrote: > On 9/11/12 2:17 PM, Eric Burger wrote: >> We solved the three-out-of-four endpoints understand D problem years >> ago. See RFC 3459. UAC's mark the message as critical (gets rejected = if >> unable to send to all recipients) or not critical (gets silently = dropped >> or destination gets a notice). >=20 > Good point. >=20 > So you are suggesting we assume the use of the Content-Disposition = header in the CPIM wrapper? And the default is REQUIRED, so the focus = should reject the message if it can't be delivered to all recipients and = it *doesn't* contain a c-d of OPTIONAL? >=20 > That WFM. >=20 > Thanks, > Paul >=20 >> -- >> Sent from my mobile device. Thanks be to lemonade! >> http://www.standardstrack.com/ietf/lemonade/ >>=20 >>=20 >> -----Original message----- >>=20 >> *From: *Paul Kyzivat * >> To: *simple@ietf.org* >> Sent: *Tue, Sep 11, 2012 15:33:00 GMT+00:00* >> Subject: *Re: [Simple] Chat: questions on 'accept-wrapped-types' >>=20 >> On 9/11/12 10:23 AM, Ben Campbell wrote: >> > >> > On Sep 11, 2012, at 7:46 AM, "Miguel A. Garcia" wrote: >> > >> >> Hi, >> >> >> >> the chat draft uses the 'accept-wrapped-types' in SDP for >> negotiating a minimum set of supported types inside the = Message/CPIM >> wrappers. >> >> >> >> While I was replying to Stephen Farrell's IESG review, he had = a >> question, and that one brought me another one. I am seeking advice >> as for how to proceed. >> >> >> >> So, here are the questions: >> >> >> >> 1) Version -16 of the draft is a bit silent with respect >> 'accept-wrapped-types. I first proposed these two paragraphs to be >> added to version -17, however, I have concerns with one of them = (see >> below). >> >> >> >> It is RECOMMENDED that participant endpoints >> >> add an 'accept-wrapped-types' attribute to the MSRP 'message' = media >> >> line in SDP, where the supported wrapped types are declared, = as per >> >> RFC 4975 procedures [RFC4975]. >> >> >> >> The conference focus SHOULD also add an 'accept-wrapped-types' >> >> attribute to the MSRP message media line in SDP containing the >> >> supported wrapped types. >> >> >> >> My question is... does the conference focus need to add an >> 'accept-wrapped-types'? The MSRP switch never interprets the = actual >> payload contents, so, for the MSRP switch, the actual payload in >> instant messages is transparent. So, why should the MSRP switch >> care? Why should the focus add an 'accept-wrapped-types' at all? >> >> >> >> I propose to replace the initially proposed "SHOULD" with a >> "MAY" in the previous paragraph. >> > >> > I concur. It could use this to express policy about what types = it >> allows, but it could just set it to "*" if it doesn't care. >>=20 >> +1 >>=20 >> > Do we need to talk about what happens if a _recipient_ does not >> support a type? I suppose the focus could set accept-wrapped-types >> based on what all the participants have expressed--but that sounds >> like a recipe for re-invite storms. The focus could send a 415 >> response to any type where it knows that that one or more = recipients >> cannot accept it. >>=20 >> Isn't that what is discussed below? >>=20 >> >> 2) Stephen Farrel is questioning what should the MSRP switch = do >> if one sender sends an instant message to the chat room, the = message >> containing a type (inside Message/CPIM) that not all the = recipients >> can understand. In other words, the MSRP switch/focus has received >> SDP indicating that an endpoint supports types A, B, and C. If >> another participant sends a message with type D, what should the >> MSRP switch do? >> >> >> >> Possibilities include: >> >> a) Do nothing; forward the message to D, he should deal with = the >> issue. I don't like this, because it is bypassing the MSRP = accept-* >> negotiation. >> >> >> >> b) Do not forward the message to this user, but forward to >> others who accept this type. It is possible that the MSRP switch >> injects a warning instant message to the sender, indicating this >> condition. >> >> >> >> c) Reject the message to the sender (i.e., do not forward to = any >> user). I don't like this option either, because the poor sender = has >> done nothing wrong. Additionally, this is the dictatorship of the >> minority (a few people who do not support a type that will be >> supported by the majority will impose their rules). And it will be >> so easy to kill a chat room by just logging in supporting only = weird >> type that none else supports. >> >> >> >> So, probably b) is the less worst of all. Comments? >> >> >> > >> > See my previous comment. >> > >> > I'm on the fence between B and C. It seems like the = undetermined >> state of "some recipients got it but others didn't" is one of the >> worst outcomes. I'm not sure I agree about the DoS issue--If a >> participant wants to screw with the conference, there's lots of >> other ways he can do so. >>=20 >> I prefer B to C. Otherwise you have given each endpoint a veto = over >> what >> can be exchanged. In the extreme, one endpoint could indicate it >> doesn't >> support either plain text or html and effectively shut down the >> chatroom. >>=20 >> It is however unpleasant for the sender not to know that some >> recipients >> didn't get his message. >>=20 >> Perhaps the focus could send a message back to the sender = indicating >> that some recipients couldn't receive his message. But this could = get >> tiresome if you get this for every message you send. And it's hard = to >> decide on what the message type and content should be. I think it = is >> better to leave this as an implementation issue rather than a = standards >> issue. >>=20 >> > Another option would be to push a warning to the recipient = saying >> that the someone had sent a type that he had not expressed support = for. >>=20 >> This has the same issues as sending a message back to the sender. = And I >> think I prefer the same solution - leave it as an implementation = issue. >>=20 >> Perhaps for both, the draft can carry a note to implementers that = they >> might want to consider this. >>=20 >> >> I also want to highlight that this is a bit theoretical = problem. >> I expect most implementations to support all commonly known types. >> > >> > If necessary, we could mandate a must-support leaf type (but = I'm >> not sure if I want to go there.) >>=20 >> I guess if anything it would be text/plain. But that might exclude >> certain specialized conferences where the messages are consumed by >> automata rather than displayed. (E.g. game systems.) >>=20 >> Again I think it is sufficient as an implementation issue. >>=20 >> Thanks, >> Paul >>=20 >> >> Additionally, I expect implementations to add a "*" to = indicate >> support for additional types that have not been explicitly listed, >> in which case, the MSRP switch will not do any filter, and it is >> about the endpoint to render the content or not. >> > >> > What happens if the recipient sends a 415 response? I guess = it's >> like any other error. That means the sender doesn't learn about it >> unless the switch synthesis some sort of warning, right? >> > >> > I also wonder if switches and/or chat participants should be a >> little less generous about what types they accept in a chat. >> Otherwise, this starts to look like a file transfer exploder :-) >> > >> > >> >> >> >> Comments? >> >> >> >> BR, >> >> >> >> Miguel >> >> >> >> -- >> >> Miguel A. Garcia >> >> +34-91-339-3608 >> >> Ericsson Spain >> >> _______________________________________________ >> >> Simple mailing list >> >> Simple@ietf.org >> >> https://www.ietf.org/mailman/listinfo/simple >> > >> > _______________________________________________ >> > Simple mailing list >> > Simple@ietf.org >> > https://www.ietf.org/mailman/listinfo/simple >> > >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 --Apple-Mail-132--283751911 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTExMTkxMDM1WjAjBgkqhkiG9w0BCQQxFgQU l9PNgRR4QzErz+vYbp0GEJnZyWcwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAFk9m9k1Nn3Ef1t7oI/1YUDPTdgtnomn/6oH0v6LjXxOGW7i60QcF /keZZHIUUKr7zEtFB4zWwaW9A/mNSHL1fC15rOq3o3dei4G5IQ90W+xqr57UyBev1bRFEGhQqt+b RrKIREyS3EcKXAnijt4RdkDZDL4jaF8GOZ3m/ZpW9JTB0DfraRDBfjEAmrdSLCcsl3Cn1qecF8wK MqzR6d6CghbE/LLl+1Gm3IIiCSoCHM83HOxQdyQWMB5eXTG/ig2VTn13YYIWMlCWUH5C4OzOTsBz li0XqkAm4DGAgGI0x3nU0wGsrZ/hmHBoy/YUjZuH5zZ8v9d5keiD2EsTJQrPGQAAAAAAAA== --Apple-Mail-132--283751911-- From eburger@standardstrack.com Tue Sep 11 12:10:52 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEA21F86EC for ; Tue, 11 Sep 2012 12:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcMKukZIbPmH for ; Tue, 11 Sep 2012 12:10:50 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 6D06221F869E for ; Tue, 11 Sep 2012 12:10:50 -0700 (PDT) Received: from [65.42.208.133] (port=50755 helo=[10.1.3.159]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1TBVqx-0002XF-3k; Tue, 11 Sep 2012 12:10:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-133--283744368; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger X-Priority: 3 In-Reply-To: <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> Date: Tue, 11 Sep 2012 14:10:42 -0500 Message-Id: <3C6A4FA4-60C2-4E73-9C0C-3A331842DB3D@standardstrack.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:10:52 -0000 --Apple-Mail-133--283744368 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Up to you guys :-) On Sep 11, 2012, at 1:51 PM, Ben Campbell wrote: >=20 > On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >=20 >>=20 >> On Sep 11, 2012, at 1:17 PM, "Eric = Burger" wrote: >>=20 >>> We solved the three-out-of-four endpoints understand D problem years = ago. See RFC 3459. UAC's mark the message as critical (gets rejected if = unable to send to all recipients) or not critical (gets silently dropped = or destination gets a notice). >>=20 >> That's an interesting and likely useful approach. I'm concerned that = it's a bit of feature creep for this draft, though. At least, it's a = non-trivial feature that the working group had not contemplated so far. = Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort = to when we did the delivery status notification work for MESSAGE. >=20 > Okay, before anyone jumps on that, on a more careful read of 3459, I = realize it would be less work than DSN. But it's still a substantial new = feature for this late in the draft's life cycle. That doesn't mean we = can't add it if we Really Need It (TM) for the rest of the draft to be = useful. Do we? >=20 >>=20 >> Can we live with some implementor guidance that they need to think = about this, and leave a formal solution as future work if anyone wants = to do it? >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-133--283744368 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPODCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggUaMIIEAqAD AgECAhBtGeqnGU9qMyLmIjJ6qnHeMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkG A1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNU IE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDQyODAwMDAw MFoXDTIwMDUzMDEwNDgzOFowgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYD VQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCShIRbS1eY1F4vi6ThQMijU1hfZmXxMk73nzJ9 VdB4TFW3QpTg+SdxB8XGaaS5MsTxQBqQzCdWYn8XtXFpruUgG+TLY15gyqJB9mrho/+43x9IbWVD jCouK2M4d9+xF6zC2oIC1tQyatRnbyATj1w1+uVUgK/YcQodNwoCUFNslR2pEBS0mZVZEjH/CaLS TNxS297iQAFbSGjdxUq04O0kHzqvcV8H46y/FDuwJXFoPfQP1hdYRhWBPGiLi4MPbXohV+Y0sNsy fuNK4aVScmQmkU6lkg//4LFg/RpvaFGZY40ai6XMQpubfSJj06mg/M6ekN9EGfRcWzW6FvOnm//B AgMBAAGjggFLMIIBRzAfBgNVHSMEGDAWgBSJgmd9xJ0mcABLtFBIfN49rgRufTAdBgNVHQ4EFgQU ehNOAHRbxnhjZCfBL+KgW7x5xXswDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw EQYDVR0gBAowCDAGBgRVHSAAMFgGA1UdHwRRME8wTaBLoEmGR2h0dHA6Ly9jcmwudXNlcnRydXN0 LmNvbS9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMHQGCCsG AQUFBwEBBGgwZjA9BggrBgEFBQcwAoYxaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VUTkFkZFRy dXN0Q2xpZW50X0NBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTAN BgkqhkiG9w0BAQUFAAOCAQEAhda+eFdVbTN/RFL+QtUGqAEDgIr7DbL9Sr/2r0FJ9RtaxdKtG3Nu PukmfOZMmMEwKN/L+0I8oSU+CnXW0D05hmbRoZu1TZtvryhsHa/l6nRaqNqxwPF1ei+eupN5yv7i kR5WdLL4jdPgQ3Ib7Y/9YDkgR/uLrzplSDyYPaUlv73vYOBJ5RbI6z9Dg/Dg7g3B080zX5vQvWBq szv++tTJOjwf7Zv/m0kzvkIpOYPuM2kugp1FTahp2oAbHj3SGl18R5mlmwhtEpmG1l1XBxunML5L SUS4kH7K0Xk467Qz+qA6XSZYnmFVGLQh1ZnV4ENAQjC+6qXnlNKw/vN1+X9u5zCCBTUwggQdoAMC AQICEC4QaCuZOyyOuQvrDyAdNqkwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTIwOTA5MDAwMDAwWhcNMTMwOTA5MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBALxS9AnBs87HgW3Q2Io8htINc6e4Lv7MkYAJ0h9KFHAvNAbW7ivyaont2K5g5OST 2uWwtVxrjDEG55yF04AvcoPdzvrq9mfaKPvC4sAPfFgG2soXNsqWG40Cz0DQZWZjzxt+ExjrClSV SZgafLDB2TTLH2VWC+p75W7LSJYZHwyCR4EmPYCA4uqobVlnSdGU/l3aECqMtK6ILnos+NJf7vup hK+MP7vF+TKSOEc+F1yXAhX9PH5NvIWi0zRzxsj8XjNZCNtjyFMv17clSJut7Wl1ZpWQGpFfkKj7 nggX7pbohyxp2SB4EPv+taKhqE6uk93DL0gWHQ9jj6gR8O3ZTZMCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBQJETe7AM8n/jUXTbMmfHnn8Iot 2TAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQAS82ejMSWOOIarMLSo u0nanSBhJWv9QT8YfXKPUB54uxYoFk06rNEMxIdL8uYG43pleqinkWV3faaTBnkApl7pja9448UG 61uGjQNWUsNzre3QytO880MeJCUwfAP+/E6hOlCSlWR1x594RJjMXxL0BXBl2IeDNzi3beg9YSRo ZeHYLmVNI0llFDcNvmodtNAXCSDd2Zbo3nw9xKs+ACV0hzdoUy2dxgJylIVqQbWcOPhiM+YshCcm Kgq096UABXMn2D2r5Hg5w5R6SB3PZT4CxVOwMFPeVEyr72YYFwFQYUd9XgsYTxxtrXq4vK7kJ8AT xxxGP6xWxvAGPGN0NxaCMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwOTExMTkxMDQzWjAjBgkqhkiG9w0BCQQxFgQU 6WbCFbovshKOgJJ5W5threg+GuYwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQLhBoK5k7LI65C+sPIB02qTCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEC4QaCuZOyyOuQvrDyAdNqkw DQYJKoZIhvcNAQEBBQAEggEAo5NwifX+aAYxhpxnermvBpH44MLoQOT6j0b1lyv6A5A8SHDTG9fs a6mof9kVY1A0f9ftKUa8bsBuCgLyVys3+8QDR8gDukxqUTQiT6ThnCj1xgDbTTT7yuyUZSGL6fTc NHLqyGhVuCFzLhSIYjIp7y+i+InrK96hiCQr0PEp4JOspAyul5zuSgdPdFcoo+i2z1k/00wbUrmu GXDdSZ+XjUi9UJzlH0deYI+RVT1zDoMfFMfP70untzgu3cIPgJwFVn6Ll2S7QZRmNdyA9Qu+CS8S TmlFWa5SP6NwOQvts6l3F0elOPgWNSH79C4ZhI36hDhgjbbkBblRo6nv5PurQQAAAAAAAA== --Apple-Mail-133--283744368-- From pkyzivat@alum.mit.edu Tue Sep 11 12:24:27 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA37C21F8669 for ; Tue, 11 Sep 2012 12:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NljOeD2WkUca for ; Tue, 11 Sep 2012 12:24:27 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A36E21F8668 for ; Tue, 11 Sep 2012 12:24:27 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id xmiM1j0050QuhwU55vQWYH; Tue, 11 Sep 2012 19:24:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id xvQ41j00N3ZTu2S3NvQ4Jp; Tue, 11 Sep 2012 19:24:04 +0000 Message-ID: <504F8FE9.40403@alum.mit.edu> Date: Tue, 11 Sep 2012 15:24:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ben Campbell References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> In-Reply-To: <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:24:27 -0000 On 9/11/12 2:51 PM, Ben Campbell wrote: > > On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: > >> >> On Sep 11, 2012, at 1:17 PM, "Eric Burger" wrote: >> >>> We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice). >> >> That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contemplated so far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort to when we did the delivery status notification work for MESSAGE. > > Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That doesn't mean we can't add it if we Really Need It (TM) for the rest of the draft to be useful. Do we? ISTM that now we are realizing we have had the feature all along and just never realized it. So there is nothing to do other than maybe point out to people that they should do it. Thanks, Paul >> >> Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it? >> >> Thanks! >> >> Ben. >> >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > > From ben@nostrum.com Tue Sep 11 12:33:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9421F8685 for ; Tue, 11 Sep 2012 12:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X08AzlkOudSQ for ; Tue, 11 Sep 2012 12:33:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED3521F8646 for ; Tue, 11 Sep 2012 12:33:07 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BJX5XJ066361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 14:33:05 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504F8FE9.40403@alum.mit.edu> Date: Tue, 11 Sep 2012 14:33:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7FC77AFE-1C02-4836-BD14-C46744C705F2@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 19:33:09 -0000 On Sep 11, 2012, at 2:24 PM, Paul Kyzivat wrote: > On 9/11/12 2:51 PM, Ben Campbell wrote: >>=20 >> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>=20 >>>=20 >>> On Sep 11, 2012, at 1:17 PM, "Eric = Burger" wrote: >>>=20 >>>> We solved the three-out-of-four endpoints understand D problem = years ago. See RFC 3459. UAC's mark the message as critical (gets = rejected if unable to send to all recipients) or not critical (gets = silently dropped or destination gets a notice). >>>=20 >>> That's an interesting and likely useful approach. I'm concerned that = it's a bit of feature creep for this draft, though. At least, it's a = non-trivial feature that the working group had not contemplated so far. = Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort = to when we did the delivery status notification work for MESSAGE. >>=20 >> Okay, before anyone jumps on that, on a more careful read of 3459, I = realize it would be less work than DSN. But it's still a substantial new = feature for this late in the draft's life cycle. That doesn't mean we = can't add it if we Really Need It (TM) for the rest of the draft to be = useful. Do we? >=20 > ISTM that now we are realizing we have had the feature all along and = just never realized it. So there is nothing to do other than maybe point = out to people that they should do it. There's still some things to specify. For example, it goes in the CPIM = wrapper, not in the MSRP header. You'll only see that once for a chunked = message, so it has to become part of the state kept for a chunked = message when fast forwarding. You default to "required" if you don't = understand 3459 (or the whole thing is "required-to-support", which = gives you basically the same thing.) Did I miss anything? >=20 > Thanks, > Paul >=20 >>>=20 >>> Can we live with some implementor guidance that they need to think = about this, and leave a formal solution as future work if anyone wants = to do it? >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >>=20 >=20 From pkyzivat@alum.mit.edu Tue Sep 11 14:20:40 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CECBD21F869C for ; Tue, 11 Sep 2012 14:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J7kVTrhC+S3 for ; Tue, 11 Sep 2012 14:20:38 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A65AA21F8692 for ; Tue, 11 Sep 2012 14:20:38 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta03.westchester.pa.mail.comcast.net with comcast id xmwm1j0020bG4ec53xLiyF; Tue, 11 Sep 2012 21:20:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id xxLX1j00F3ZTu2S3PxLXCd; Tue, 11 Sep 2012 21:20:31 +0000 Message-ID: <504FAB25.2070102@alum.mit.edu> Date: Tue, 11 Sep 2012 17:20:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ben Campbell References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <7FC77AFE-1C02-4836-BD14-C46744C705F2@nostrum.com> In-Reply-To: <7FC77AFE-1C02-4836-BD14-C46744C705F2@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:20:40 -0000 On 9/11/12 3:33 PM, Ben Campbell wrote: > > On Sep 11, 2012, at 2:24 PM, Paul Kyzivat wrote: > >> On 9/11/12 2:51 PM, Ben Campbell wrote: >>> >>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>> >>>> >>>> On Sep 11, 2012, at 1:17 PM, "Eric Burger" wrote: >>>> >>>>> We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice). >>>> >>>> That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contemplated so far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort to when we did the delivery status notification work for MESSAGE. >>> >>> Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That doesn't mean we can't add it if we Really Need It (TM) for the rest of the draft to be useful. Do we? >> >> ISTM that now we are realizing we have had the feature all along and just never realized it. So there is nothing to do other than maybe point out to people that they should do it. > > There's still some things to specify. For example, it goes in the CPIM wrapper, not in the MSRP header. You'll only see that once for a chunked message, so it has to become part of the state kept for a chunked message when fast forwarding. You default to "required" if you don't understand 3459 (or the whole thing is "required-to-support", which gives you basically the same thing.) > > Did I miss anything? Not sure. Regarding remembering this as part of the state of the message - maybe, and maybe not: If it remembers 'accept-wrapped-types' for every endpoint, then when preparing to forward a message it can identify any endpoints that don't support the type, and fail the message before forwarding anything. But if it wants to handle 415 responses from the forwarded chunks and then decide whether to forward the 415 to the sender or not based on content-disposition, then it will need to remember that as state. So maybe this isn't so obvious, which goes to your point of whether this is feature creep. But can we dodge it, or not??? And do we want to? >> Thanks, >> Paul >> >>>> >>>> Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>> >>> >> > > From ben@nostrum.com Tue Sep 11 14:30:47 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6E621F86FD for ; Tue, 11 Sep 2012 14:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WQ8r+Rnr-Ep for ; Tue, 11 Sep 2012 14:30:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E80821F86F0 for ; Tue, 11 Sep 2012 14:30:46 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8BLUh0w077335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Sep 2012 16:30:44 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <504FAB25.2070102@alum.mit.edu> Date: Tue, 11 Sep 2012 16:30:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <36D72549-0B26-456C-AEFA-8A71F05A9DD0@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <7FC77AFE-1C02-4836-BD14-C46744C705F2@nostrum.com> <504FAB25.2070102@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:30:47 -0000 On Sep 11, 2012, at 4:20 PM, Paul Kyzivat wrote: > On 9/11/12 3:33 PM, Ben Campbell wrote: >>=20 >> On Sep 11, 2012, at 2:24 PM, Paul Kyzivat = wrote: >>=20 >>> On 9/11/12 2:51 PM, Ben Campbell wrote: >>>>=20 >>>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>>>=20 >>>>>=20 >>>>> On Sep 11, 2012, at 1:17 PM, "Eric = Burger" wrote: >>>>>=20 >>>>>> We solved the three-out-of-four endpoints understand D problem = years ago. See RFC 3459. UAC's mark the message as critical (gets = rejected if unable to send to all recipients) or not critical (gets = silently dropped or destination gets a notice). >>>>>=20 >>>>> That's an interesting and likely useful approach. I'm concerned = that it's a bit of feature creep for this draft, though. At least, it's = a non-trivial feature that the working group had not contemplated so = far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent = effort to when we did the delivery status notification work for MESSAGE. >>>>=20 >>>> Okay, before anyone jumps on that, on a more careful read of 3459, = I realize it would be less work than DSN. But it's still a substantial = new feature for this late in the draft's life cycle. That doesn't mean = we can't add it if we Really Need It (TM) for the rest of the draft to = be useful. Do we? >>>=20 >>> ISTM that now we are realizing we have had the feature all along and = just never realized it. So there is nothing to do other than maybe point = out to people that they should do it. >>=20 >> There's still some things to specify. For example, it goes in the = CPIM wrapper, not in the MSRP header. You'll only see that once for a = chunked message, so it has to become part of the state kept for a = chunked message when fast forwarding. You default to "required" if you = don't understand 3459 (or the whole thing is "required-to-support", = which gives you basically the same thing.) >>=20 >> Did I miss anything? >=20 > Not sure. >=20 > Regarding remembering this as part of the state of the message - = maybe, and maybe not: >=20 > If it remembers 'accept-wrapped-types' for every endpoint, then when = preparing to forward a message it can identify any endpoints that don't = support the type, and fail the message before forwarding anything. >=20 > But if it wants to handle 415 responses from the forwarded chunks and = then decide whether to forward the 415 to the sender or not based on = content-disposition, then it will need to remember that as state. >=20 > So maybe this isn't so obvious, which goes to your point of whether = this is feature creep. But can we dodge it, or not??? And do we want to? I asked you first :-) Perhaps the authors will have an opinion. From miguel.a.garcia@ericsson.com Wed Sep 12 05:32:02 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6B21F8606 for ; Wed, 12 Sep 2012 05:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUuNyzRAXbuC for ; Wed, 12 Sep 2012 05:32:01 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id DAEC621F85F3 for ; Wed, 12 Sep 2012 05:32:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-50-505080bfd7f2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 36.C9.11467.FB080505; Wed, 12 Sep 2012 14:31:59 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 14:31:59 +0200 Message-ID: <505080BD.4040002@ericsson.com> Date: Wed, 12 Sep 2012 14:31:57 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> <504E0EB3.1010709@alum.mit.edu> In-Reply-To: <504E0EB3.1010709@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsUyM+Jvre7+hoAAg1OzzSxWbDjAarFw4j9W ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj/fIN5oK9XhULfl9nbmA8Z9nFyMkhIWAi sXPuHkYIW0ziwr31bF2MXBxCAqcYJToXT2IFSQgJrGGUONlYCWLzCmhL3Fr8gR3EZhFQldjd 2MkEYrMJmEu0btwIFhcVCJY4t3EbG0S9oMTJmU9Yuhg5OEQENCQmbVUDCTMLqEtcu3KOCWSX sEAHo0TfmtvsEIsPM0vMfz2VGaSKU0BH4lkLhM0sYCtxYc51FghbXmL72znMEMdpSky+uZR5 AqPgLCT7ZiFpmYWkZQEj8ypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMBgPbjlt+4OxlPnRA4x SnOwKInzciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOJXfSHP31GzJk2qCihFeG3ZO /frc/GShc0mMwEmOdLtrV5RPKs78dFD36HWN6YIL7jkfENxjzHC31z5HaKKRspSW2/XNbBX5 KfNKpzVM3ntL1ayucmHCWYfTPddqfzKf2adp/uHu0l9p4b7Pedf0XmeYcfPBjG2H+vkvaK1Q vqI95Zfn64DnGkosxRmJhlrMRcWJAAtOf10kAgAA Cc: "simple@ietf.org" Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:32:03 -0000 Hi Paul: Thanks for your comments. See inline. On 10/09/2012 18:00, Paul Kyzivat wrote: > On 9/10/12 9:20 AM, Miguel A. Garcia wrote: >> Ben, and the SIMPLE WG: >> >> To clarify the usage of accept-types, I propose two paragraphs to >> Section 5.2 (Joining a chat room). The first paragraph is new and >> discusses the participant's SDP. Here, I propose not to add normative >> text mandating the UA to add 'a=accept-types:Message/CPIM' in SDP. The >> reason is that such normative text would require a mechanism for the UA >> to know in advance that it is joining a chat room, perhaps by examining >> the chat room URI. But in general, such mechanism does not exist. The UA >> will create an INVITE request with SDP, not knowing if at the other end >> there is a chat room or a regular user. If this SDP contains >> 'm=message', the attributes included afterwards will be the same, no >> matter whether the participant is joining a chat room or just another >> endpoint. Please verify that the proposed words are acceptable: >> "...needs to include at least... >> >> This participant's INVITE request contains an SDP body. This SDP > > There are possibilities beyond the one mentioned here: > - the participant might send an INVITE without an offer. > - the focus might send the INVITE, with or without an offer. > >> body includes the description of MSRP 'message' media line as per RFC >> 4975 procedures [RFC4975]. This specification requires all instant >> messages to be wrapped in a Message/CPIM wrapper [RFC3862], >> therefore, the 'accept-types' attribute for the MSRP message media in >> the participant's SDP offer needs to include at least the value >> 'Message/CPIM', otherwise the conference focus will reject the >> request. The actual instant message payload type is negotiated in >> the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] >> for details). There is no default wrapped type. Typical wrapped >> type values can include: text/plain, text/html, image/jpeg, image/ >> png, audio/mp3, etc. It is RECOMMENDED that participant endpoints >> add an 'accept-wrapped-types' attribute to the MSRP 'message' media >> line in SDP, where the supported wrapped types are declared, as per >> RFC 4975 procedures [RFC4975]. > > So how about the following instead? > > This specification requires all instant > messages to be wrapped in a Message/CPIM wrapper [RFC3862]. > Therefore the 'accept-types' attribute for the MSRP message media in > both the SDP offer and answer need to include at least the value > 'Message/CPIM'. If not, the conference focus will reject the > request. The actual instant message payload type is negotiated in > the 'accept-wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] > for details). There is no default wrapped type. Typical wrapped > type values can include: text/plain, text/html, image/jpeg, image/ > png, audio/mp3, etc. It is RECOMMENDED that participant endpoints > add an 'accept-wrapped-types' attribute to the MSRP 'message' media > line in SDP, where the supported wrapped types are declared, as per > RFC 4975 procedures [RFC4975]. Your proposed text works for me. I will change it. > >> Now, the second paragraph was already present in the previous version, >> and is now divided into two paragraphs. It tackles the conference focus. >> I have added text to indicate that the focus must only accept >> Message/CPIM, and also that the focus should add an >> 'accept-wrapped-types'. The text reads: >> >> The conference focus of a chat room MUST only use a Message/CPIM >> [RFC3862] top-level wrapper as a payload of MSRP messages, and this >> needs to be declared in the SDP offer and answer as per regular RFC >> 4975 procedures [RFC4975]. This implies that if the conference focus >> receives from a participant's endpoint an SDP offer that does not >> include the value 'Message/CPIM' in the 'accept-types' attribute for >> the MSRP message media line, the conference focus SHOULD either >> reject the MSRP message media stream or the complete SDP offer by >> using regular SIP or SDP procedures (e.g., creating an SDP answer >> that sets to zero the port of the MSRP message media line, responding >> the INVITE with a 488 response, etc.). > >> If the conference focus accepts the participant's SDP offer, when the >> conference focus generates the SDP answer, it MUST set the 'accept- >> types' attribute for the MSRP message media line to a value of >> 'Message/CPIM'. This specification requires all instant messages to >> be wrapped in a Message/CPIM wrapper, therefore, the 'accept-types' >> attribute in this SDP body contains a single value of 'Message/CPIM'. >> The actual instant message payload type is negotiated in the 'accept- >> wrapped-types' attribute in SDP (see RFC 4975 [RFC4975] for details). >> The conference focus SHOULD also add an 'accept-wrapped-types' >> attribute to the MSRP message media line in SDP containing the >> supported wrapped types. > > I'm not sure this says quite what you mean either. Couple of issues: > > - I guess the intent is that every message sent to/from the focus is > wrapped in Messsage/CPIM. That is easy for messages *from* the focus. > But to ensure it for messages *to* the focus I think you are trying > to say that the SDP *from* the focus must include *only* > message/CPIM in 'accept-types'. I think the MUST is in the wrong place > above for that. Yes, you got the intention of the text. To clarify: SDP sent from the UA to the focus need to contain Message/CPIM, but most likely, it will contain something else, because the endpoint does not know it is connecting to a chat room. SDP sent from the focus to the UA will only contain an 'accept-types' of Message/CPIM, in order to force UAs to send only MSRP messages containing Message/CPIM. Therefore, I believe the following MUST is correct: If the conference focus accepts the participant's SDP offer, when the conference focus generates the SDP answer, it MUST set the 'accept- types' attribute for the MSRP message media line to a value of 'Message/CPIM'. > > - I am a little concerned that if you only allow message/CPIM, that you > will be cutting off a point of extensibility. Some future extension > may need to add something that requires a new mime type here - > presumably one that is a functional superset of message/CPIM. But > a mandatory requirement to include *only* message/CPIM will exclude > such a future focus from being backward compatible with this spec. I don't think so. Future extensions will update this draft/RFC. We have done it this way many times, when some normative text is updated by a subsequent document. So, I don't believe we are cutting off extensibility. > > ISTM that the desired behavior is: > > - if focus is the answerer, and the offer doesn't include message/CPIM, > then it can't support this spec on that m-line. It then MUST either > reject the m-line, fail the call, or use this m-line in accord with > some spec other than this one. (E.g. a future extension.) > If the offer *does* include message/CPIM, and the focus wants to > use this spec, then it MUST include *only* message/CPIM in > 'accept-types'. The above is correct. But I don't want to enter the future extensibility trap. We should publish normative statements for this document. Future documents will have to update this done in many places, I guess. > > - if the focus is the offerer, and wishes to support this spec, then > it MUST include message/CPIM in 'accept-types'. It should only > include other types in 'accept-types' if there are other alternative > specs is is prepared to support. Yes, modulo the future extensibility issue. > > I don't have alternative text for that. It may be hard to write, and I'm > not going to try unless the above is really the intent. So, the text is much easier if you don't consider the future extensibility now, but leave it as a future exercise. I believe that the text in the draft is correct (with the modifications you suggested at the beginning of this message). BR, Miguel > > Thanks, > Paul > > >> Please indicate if there are problems with the proposed text. >> >> /Miguel >> >> >> >> On 07/09/2012 10:41, Miguel A. Garcia wrote: >>> On 06/09/2012 22:12, Ben Campbell wrote: >>>> But the text talks about the what the conference focus sends, not UAs >>>> in_general_. If the focus includes anything_other_ than Message/CPIM >>>> in accept-types, it better be prepared to receive it. Is that the >>>> intent? >>> >>> Ben, I see your point. The conference focus MUST only send an >>> accept-types of Message/CPIM. There is no reason for using any other >>> value. >>> >>> I will revise this text to make clear the intention. >>> >>> BR, >>> >>> Miguel >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 12 05:38:38 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEE521F85A2 for ; Wed, 12 Sep 2012 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.225 X-Spam-Level: X-Spam-Status: No, score=-6.225 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VxInHQkCxVo for ; Wed, 12 Sep 2012 05:38:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB7521F84EB for ; Wed, 12 Sep 2012 05:38:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-73-5050824b7b52 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A4.26.25676.B4280505; Wed, 12 Sep 2012 14:38:36 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 14:38:34 +0200 Message-ID: <50508249.9050903@ericsson.com> Date: Wed, 12 Sep 2012 14:38:33 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> <504E0EB3.1010709@alum.mit.edu> <504E1A27.8000100@alum.mit.edu> In-Reply-To: <504E1A27.8000100@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvra5PU0CAwfqtXBbzO0+zW6zYcIDV YuHEf6wOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mrau5Cn4Ilqx7eMn1gbG 64JdjJwcEgImEsvvfGGHsMUkLtxbz9bFyMUhJHCKUWLV5ttQzhpGiTef/jKDVPEKaEt8mNPB AmKzCKhKbLp5lQnEZhMwl2jduBFskqhAsMS5jdvYIOoFJU7OfAJUz8EhIqAhMWmrGkiYWcBd 4sjlFYwg84UFOhgl+tbcZodYNo1Fouf9IrBBnAI6EmsfPWeE6LCVuDDnOguELS+x/e0csIOE BDQlJt9cyjyBUXAWkn2zkLTMQtKygJF5FaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYAAf3PJb dQfjnXMihxilOViUxHmtt+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDItfk7T8ua0iN1 qvZckud+15cmMa3X/pWzuCq7PlJg6QTdZ6fDtumbRMpquef/kYvy9QlKOM8adkzi5G1TX5G2 U+FZFjPW/14fJM2o/5fjg4HPu6aY/Ztud7t/Er+464XtzvLgo1sqN8zn3rDps+Lv7bzuTj8S Ap7wr7/byRR8o2v+yl9v2CqVWIozEg21mIuKEwGz0py9LgIAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:38:38 -0000 Ben, Paul: See inline comments On 10/09/2012 18:49, Paul Kyzivat wrote: > On 9/10/12 12:22 PM, Ben Campbell wrote: >> >> On Sep 10, 2012, at 11:00 AM, Paul Kyzivat >> wrote: >> >>> - I am a little concerned that if you only allow message/CPIM, >>> that you will be cutting off a point of extensibility. Some future >>> extension may need to add something that requires a new mime type >>> here - presumably one that is a functional superset of >>> message/CPIM. But a mandatory requirement to include *only* >>> message/CPIM will exclude such a future focus from being backward >>> compatible with this spec. >> >> I'm not sure that's a bad thing, since there's interop behavior that >> depends on it's use. If you use something _other_ than >> message/CPIM, some one will need to specify how you handle the >> behavior that is dependent on it. > > The issue is with some future implementation that supports > simple-chat and simple-chat-bis that uses message/CPIM++. The problem > then arises only in the case that the focus generates the offer. It > then wants to put "message/CPIM,message/CPIM++" in 'accept-types'. > > This should be fine for answerers that support only simple-chat as > long as they don't get over-picky and declare the focus non-compliant > for mentioning message/CPIM++. So it's just a matter of not forbidding > the focus from including something else. > >> A possible compromise might be something like "SHOULD include only >> message/CPIM. While other types might be useful in the future, their >> use is out of scope for this specification. Any chat mechanism that >> uses a wrapper other than message/CPIM will need to specify how to >> encode and interpret sender and recipient information to achieve >> similar behaviors as in this document." > > Yes, something like that could work. I would accept that compromise if there is a lot of pressure. Let's be pragmatical. The Internet is full of RFCs with normative statements that have been updated by other documents changing the initial normative behavior. This is a common practice in IETF documentation. So, I don't see a problem in leaving the text as is, and then, if need arises, create another hypothetical document that updates this in a number of normative statements for the addition of a few hypothetical features. And this will make the current text very clear: "if you implement THIS spec you need to do this". If you implement some other spec, that other spec will tell you what to do. /Miguel > > Thanks, Paul _______________________________________________ Simple > mailing list Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From miguel.a.garcia@ericsson.com Wed Sep 12 06:50:18 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804AE21F85A4 for ; Wed, 12 Sep 2012 06:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzQwXIiASHJh for ; Wed, 12 Sep 2012 06:50:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7179B21F85A3 for ; Wed, 12 Sep 2012 06:50:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-bc-50509318b1c3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B7.96.11467.81390505; Wed, 12 Sep 2012 15:50:16 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 15:50:15 +0200 Message-ID: <50509316.6020604@ericsson.com> Date: Wed, 12 Sep 2012 15:50:14 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> In-Reply-To: <504F8FE9.40403@alum.mit.edu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvra7E5IAAg/O/JCzmd55mt1ix4QCr xcKJ/1gdmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZTxp7WQumCRa8ePONeYG xm8CXYycHBICJhLrPx5lhLDFJC7cW8/WxcjFISRwilFi47Y2dghnDaPElAdLmUGqeAW0JW4t 38kEYrMIqEq8XbWeBcRmEzCXaN24kR3EFhUIlji3cRsbRL2gxMmZT4BqODhEBDQkJm1VAwkz C7hL9P1tBWsVFrCXODn/N9SudUwSi7ZPApvDKaAl8aH1OzNEg63EhTnXWSBseYntb+eAxYUE NCUm31zKPIFRcBaSdbOQtMxC0rKAkXkVo3BuYmZOermhXmpRZnJxcX6eXnHqJkZgAB/c8lt3 B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJzJXCm+5si639PL evz+3Nscfex8SpBa1J3HbUl7Fi+8cE3GfOnfmz3vHj64FvGkM+RV7LuwC6e+KWlUvPcMP7TL YlOwlyY334o9J3Xe3FtUfc3TLq9nhmPlBga9mY6uqv31JwTCFzI+KlukdW6q+P4pH7tlt7ne 2Ze0+L2YpN98571pDMmcevpKLMUZiYZazEXFiQCeTLjCLgIAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:50:18 -0000 On 11/09/2012 21:24, Paul Kyzivat wrote: > On 9/11/12 2:51 PM, Ben Campbell wrote: >> >> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >> >>> >>> On Sep 11, 2012, at 1:17 PM, "Eric Burger" wrote: >>> >>>> We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice). >>> >>> That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contemplated so far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort to when we did the delivery status notification work for MESSAGE. >> >> Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That doesn't mean we can't add it if we Really Need It (TM) for the rest of the draft to be useful. Do we? > > ISTM that now we are realizing we have had the feature all along and > just never realized it. So there is nothing to do other than maybe point > out to people that they should do it. > > Thanks, > Paul > >>> >>> Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it? >>> >>> Thanks! >>> >>> Ben. >>> At this point in time, I believe we don't really understand all the use cases and problems that we will get when we introduce the Content-Disposition handling parameter. Let me give you one example of added complexity: Alice sends a message to the chat room. The MSRP switch distribute to Bob and Charlie, because both indicated an accept-wrapped-types of "*". Bob accepts the content, but not Charlie. Charlie "MUST take the appropriate failure action " [RFC3459], but which one is it? And then, when the MSRP switch receives such 'failure action', what should it do towards the sender? And should it wait to aggregate 'failure actions' from several potential receivers? So, let's be pragmatical. We don't have time nor requirements to have this sophisticated feature at this late point in time. I will try to think of something simple (e.g., discard on error). If someone is interested, he or she should collect requirements and write an extension. Is this reasonable? If so, I will come up with text for review? /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Wed Sep 12 06:59:20 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B654321F8549 for ; Wed, 12 Sep 2012 06:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G9kLZWqi1yZ for ; Wed, 12 Sep 2012 06:59:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8AA21F8543 for ; Wed, 12 Sep 2012 06:59:20 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8CDxGOY072406 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2012 08:59:16 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50508249.9050903@ericsson.com> Date: Wed, 12 Sep 2012 08:59:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <47A2D2BE-DE8F-4DFF-B876-0EA45E62C01D@nostrum.com> References: <5046030A.5070902@ericsson.com> <504603AF.50006@ericsson.com> <5046FC24.8030604@ericsson.com> <5046FCF6.6060902@ericsson.com> <50476342.8040809@ericsson.com> <2B0B7BD2-D16A-4EAB-9970-BE69E81BFED4@estacado.net> <504896FD.1010407@ericsson.com> <3AE51D75-C9ED-45A5-A0F9-83304EDC38E8@nostrum.com> <5049B354.7060004@ericsson.com> <504DE925.4050303@ericsson.com> <504E0EB3.1010709@alum.mit.edu> <504E1A27.8000100@alum.mit.edu> <50508249.9050903@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] accept-types [was Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 13:59:20 -0000 On Sep 12, 2012, at 7:38 AM, "Miguel A. Garcia" = wrote: [...] >>=20 >>> A possible compromise might be something like "SHOULD include only >>> message/CPIM. While other types might be useful in the future, their >>> use is out of scope for this specification. Any chat mechanism that >>> uses a wrapper other than message/CPIM will need to specify how to >>> encode and interpret sender and recipient information to achieve >>> similar behaviors as in this document." >>=20 >> Yes, something like that could work. >=20 > I would accept that compromise if there is a lot of pressure. Let's be = pragmatical. The Internet is full of RFCs with normative statements that = have been updated by other documents changing the initial normative = behavior. This is a common practice in IETF documentation. >=20 > So, I don't see a problem in leaving the text as is, and then, if need = arises, create another hypothetical document that updates this in a = number of normative statements for the addition of a few hypothetical = features. >=20 > And this will make the current text very clear: "if you implement THIS = spec you need to do this". If you implement some other spec, that other = spec will tell you what to do. >=20 WFM= From miguel.a.garcia@ericsson.com Wed Sep 12 07:02:04 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2B21F8543 for ; Wed, 12 Sep 2012 07:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5ZhwnjnB-ri for ; Wed, 12 Sep 2012 07:02:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE92E21F854C for ; Wed, 12 Sep 2012 07:02:00 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-87-505095d7bab3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FB.48.11467.7D590505; Wed, 12 Sep 2012 16:01:59 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 16:01:58 +0200 Message-ID: <505095D4.7020803@ericsson.com> Date: Wed, 12 Sep 2012 16:01:56 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> In-Reply-To: <50509316.6020604@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3Vvf61IAAg9V9JhYrNhxgtVg48R+r A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXx9/wX5oJf0hVHP25lbGCcI9bFyMEhIWAi 8f8qSxcjJ5ApJnHh3nq2LkYuDiGBU4wSvUdmMUE4axglPk2eyg7SwCugLbHyAjNIA4uAqsSK /5eZQGw2AXOJ1o0b2UFsUYFgiXMbt7GB2LwCghInZz4BWyAiYCrRNmsLmM0s4Ctx8d8JsF5h AXuJk/N/s0PsOsckcfjtAkaQXZwCOhKTFhVD1NtKXJhzHapXXmL72zlgNwgJaEpMvrmUeQKj 4Cwk62YhaZmFpGUBI/MqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzAQD245bfuDsZT50QOMUpz sCiJ83Il7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGgWfEo5XmjdOd9lF9SD3EIeTuT4 r2CpYz1zkWRTpq7z/8AXnd9vT26+xGM3MZ9DR+hgaF7J9Ik95zTufVNU09lrFuMT1J2R0JzL nFP2iOWwWewLs5kXw2cLlT0O9t/n2GuWd/vVtikv32zZccTmWHFrqUMw2wkOnkPFdTMEOkTb /uRUuB17pcRSnJFoqMVcVJwIAFuJJsMiAgAA Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:02:04 -0000 On 12/09/2012 15:50, Miguel A. Garcia wrote: > On 11/09/2012 21:24, Paul Kyzivat wrote: >> On 9/11/12 2:51 PM, Ben Campbell wrote: >>> >>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>> >>>> >>>> On Sep 11, 2012, at 1:17 PM, "Eric Burger" wrote: >>>> >>>>> We solved the three-out-of-four endpoints understand D problem years ago. See RFC 3459. UAC's mark the message as critical (gets rejected if unable to send to all recipients) or not critical (gets silently dropped or destination gets a notice). >>>> >>>> That's an interesting and likely useful approach. I'm concerned that it's a bit of feature creep for this draft, though. At least, it's a non-trivial feature that the working group had not contemplated so far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent effort to when we did the delivery status notification work for MESSAGE. >>> >>> Okay, before anyone jumps on that, on a more careful read of 3459, I realize it would be less work than DSN. But it's still a substantial new feature for this late in the draft's life cycle. That doesn't mean we can't add it if we Really Need It (TM) for the rest of the draft to be useful. Do we? >> >> ISTM that now we are realizing we have had the feature all along and >> just never realized it. So there is nothing to do other than maybe point >> out to people that they should do it. >> >> Thanks, >> Paul >> >>>> >>>> Can we live with some implementor guidance that they need to think about this, and leave a formal solution as future work if anyone wants to do it? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> > > At this point in time, I believe we don't really understand all the use > cases and problems that we will get when we introduce the > Content-Disposition handling parameter. Let me give you one example of > added complexity: > > Alice sends a message to the chat room. The MSRP switch distribute to Bob > and Charlie, because both indicated an accept-wrapped-types of "*". Bob > accepts the content, but not Charlie. Charlie "MUST take the appropriate > failure action " [RFC3459], but which one is it? And then, when the MSRP > switch receives such 'failure action', what should it do towards the > sender? And should it wait to aggregate 'failure actions' from several > potential receivers? > > So, let's be pragmatical. We don't have time nor requirements to have > this sophisticated feature at this late point in time. I will try to > think of something simple (e.g., discard on error). If someone is > interested, he or she should collect requirements and write an extension. > > Is this reasonable? If so, I will come up with text for review? This is the text I propose to add. Please comment. When generating a copy of the SEND request to each participant in the chat room, the MSRP switch MUST evaluate the wrapped media types that the recipient is able to accept. This was learned through the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the current. If the MSRP switch is aware that the media type of the wrapped content is not acceptable to the recipient, the MSRP switch SHOULD NOT forward this message to that endpoint. Note that this version of the specification does not require the MSRP switch to notify the sender about this failure. Extensions to this specification may improve handling of unknown media types. > > /Miguel > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Wed Sep 12 07:02:15 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A4F21F8600 for ; Wed, 12 Sep 2012 07:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WCkt9JXzojn for ; Wed, 12 Sep 2012 07:02:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E521F8613 for ; Wed, 12 Sep 2012 07:02:14 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8CE2B4m072758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2012 09:02:11 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <50509316.6020604@ericsson.com> Date: Wed, 12 Sep 2012 09:02:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69C14169-3D86-4C51-85F8-24B85D9AB95B@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:02:15 -0000 On Sep 12, 2012, at 8:50 AM, "Miguel A. Garcia" = wrote: [...] >>=20 >>>>=20 >>>> Can we live with some implementor guidance that they need to think = about this, and leave a formal solution as future work if anyone wants = to do it? >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >=20 > At this point in time, I believe we don't really understand all the = use cases and problems that we will get when we introduce the = Content-Disposition handling parameter. Let me give you one example of = added complexity: >=20 > Alice sends a message to the chat room. The MSRP switch distribute to = Bob and Charlie, because both indicated an accept-wrapped-types of "*". = Bob accepts the content, but not Charlie. Charlie "MUST take the = appropriate failure action " [RFC3459], but which one is it? And then, = when the MSRP switch receives such 'failure action', what should it do = towards the sender? And should it wait to aggregate 'failure actions' = from several potential receivers? >=20 > So, let's be pragmatical. We don't have time nor requirements to have = this sophisticated feature at this late point in time. I will try to = think of something simple (e.g., discard on error). If someone is = interested, he or she should collect requirements and write an = extension. >=20 > Is this reasonable? If so, I will come up with text for review? +1 From ben@nostrum.com Wed Sep 12 07:05:36 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CED21F85A4 for ; Wed, 12 Sep 2012 07:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Onh66aixZKfF for ; Wed, 12 Sep 2012 07:05:35 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3F2F21F85A0 for ; Wed, 12 Sep 2012 07:05:35 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8CE5V7i073103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Sep 2012 09:05:32 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: <505095D4.7020803@ericsson.com> Date: Wed, 12 Sep 2012 09:05:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2E4FB18E-532E-419C-9FBF-5D0094362674@nostrum.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> <505095D4.7020803@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:05:36 -0000 On Sep 12, 2012, at 9:01 AM, "Miguel A. Garcia" = wrote: [...] >>=20 >> At this point in time, I believe we don't really understand all the = use >> cases and problems that we will get when we introduce the >> Content-Disposition handling parameter. Let me give you one example = of >> added complexity: >>=20 >> Alice sends a message to the chat room. The MSRP switch distribute to = Bob >> and Charlie, because both indicated an accept-wrapped-types of "*". = Bob >> accepts the content, but not Charlie. Charlie "MUST take the = appropriate >> failure action " [RFC3459], but which one is it? And then, when the = MSRP >> switch receives such 'failure action', what should it do towards the >> sender? And should it wait to aggregate 'failure actions' from = several >> potential receivers? >>=20 >> So, let's be pragmatical. We don't have time nor requirements to have >> this sophisticated feature at this late point in time. I will try to >> think of something simple (e.g., discard on error). If someone is >> interested, he or she should collect requirements and write an = extension. >>=20 >> Is this reasonable? If so, I will come up with text for review? >=20 > This is the text I propose to add. Please comment. >=20 > When generating a copy of the SEND request to each > participant in the chat room, the MSRP switch MUST evaluate > the wrapped media types that the recipient is able to > accept. This was learned through the 'accept-wrapped-types' > attribute of the MSRP message media line in SDP. If the > current. If the MSRP switch is aware that the media type of > the wrapped content is not acceptable to the recipient, the > MSRP switch SHOULD NOT forward this message to that > endpoint. Note that this version of the specification does > not require the MSRP switch to notify the sender about this > failure. Extensions to this specification may improve > handling of unknown media types. WFM. I thought about explicitly mentioning the "*" case, where the = switch may not learn a format is unacceptable until it tries to send it. = But on reflection, I think that's covered implicitly. For this purpose, = the "*" case means everything is acceptable. >=20 >=20 >>=20 >> /Miguel >>=20 >=20 > --=20 > Miguel A. Garcia > +34-91-339-3608 > Ericsson Spain > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Wed Sep 12 07:13:09 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F57021F8540 for ; Wed, 12 Sep 2012 07:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+lzD0T4cwvI for ; Wed, 12 Sep 2012 07:13:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49C3821F8569 for ; Wed, 12 Sep 2012 07:13:08 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-33-50509873a893 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 57.34.25676.37890505; Wed, 12 Sep 2012 16:13:07 +0200 (CEST) Received: from [159.107.24.222] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 16:13:06 +0200 Message-ID: <50509871.10609@ericsson.com> Date: Wed, 12 Sep 2012 16:13:05 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ben Campbell References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> <505095D4.7020803@ericsson.com> <2E4FB18E-532E-419C-9FBF-5D0094362674@nostrum.com> In-Reply-To: <2E4FB18E-532E-419C-9FBF-5D0094362674@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvrW7xjIAAg637xS3md55mt1ix4QCr xcKJ/1gdmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZdz9+5it4Lh0xeF/21ga GH+JdjFyckgImEh87m9hhbDFJC7cW8/WxcjFISRwilHi2Nc3jBDOGkaJj5d62UCqeAU0Jd4s eMgCYrMIqEoc2HGWHcRmEzCXaN24EcwWFQiWOLdxG1S9oMTJmU/A6kUElCSeN28Fs5kFAiQu fehgBrGFBewlTs7/zQ6xbCGzxKYDZ8CKOIESi7puQDXYSlyYcx3KlpfY/nYOWLMQ0EGTby5l nsAoOAvJvllIWmYhaVnAyLyKUTg3MTMnvdxIL7UoM7m4OD9Przh1EyMwhA9u+a26g/HOOZFD jNIcLErivNZb9/gLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYAzwZupbXaTQ4b9u+6dt3M8m vxUvv/Ru78HbSz536lZuzctq+6VQucDkpXlY5KP0ksPFbxuCObfcnpfFFH5KlFmA7f6Wkhsn uiLkDa59u8uiIvTRvdho/aXq/bNes7pfFDwslNvrtuEws19AiYTZMu3e5hWGu8unF97zr30h mqprGz95U7AjkxJLcUaioRZzUXEiAFmxzogvAgAA Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 14:13:09 -0000 On 12/09/2012 16:05, Ben Campbell wrote: > > On Sep 12, 2012, at 9:01 AM, "Miguel A. Garcia" > wrote: > > [...] > >>> >>> At this point in time, I believe we don't really understand all >>> the use cases and problems that we will get when we introduce the >>> Content-Disposition handling parameter. Let me give you one >>> example of added complexity: >>> >>> Alice sends a message to the chat room. The MSRP switch distribute >>> to Bob and Charlie, because both indicated an accept-wrapped-types >>> of "*". Bob accepts the content, but not Charlie. Charlie "MUST >>> take the appropriate failure action " [RFC3459], but which one is >>> it? And then, when the MSRP switch receives such 'failure action', >>> what should it do towards the sender? And should it wait to >>> aggregate 'failure actions' from several potential receivers? >>> >>> So, let's be pragmatical. We don't have time nor requirements to >>> have this sophisticated feature at this late point in time. I will >>> try to think of something simple (e.g., discard on error). If >>> someone is interested, he or she should collect requirements and >>> write an extension. >>> >>> Is this reasonable? If so, I will come up with text for review? >> >> This is the text I propose to add. Please comment. >> >> When generating a copy of the SEND request to each participant in >> the chat room, the MSRP switch MUST evaluate the wrapped media types >> that the recipient is able to accept. This was learned through the >> 'accept-wrapped-types' attribute of the MSRP message media line in >> SDP. If the current. If the MSRP switch is aware that the media type >> of the wrapped content is not acceptable to the recipient, the MSRP >> switch SHOULD NOT forward this message to that endpoint. Note that >> this version of the specification does not require the MSRP switch >> to notify the sender about this failure. Extensions to this >> specification may improve handling of unknown media types. > > WFM. I thought about explicitly mentioning the "*" case, where the > switch may not learn a format is unacceptable until it tries to send > it. But on reflection, I think that's covered implicitly. For this > purpose, the "*" case means everything is acceptable. Yeah, I thought about adding some text like that, but at the end of the day, it will be annotated version of RFC 4575 on accept-wrapped-types, meaning, there is no normative text to add. I think we should expect the reader to be QUITE familiar with RFC 4975. Also, I have now added the concept of a policy in the chat room to control the Supported Wrapped media type: The list of media types that the MSRP switch accepts in Message/CPIM wrappers sent from participants. This list is included in the 'accept-wrapped-types' attribute of the MSRP message media line in SDP. If the MSRP switch accepts additional media types than those explicitly listed, a "*" is added to the list. A single "*" indicates that the chat room accepts any wrapped media type. I guess this also hints for what you are saying. /Miguel > >> >> >>> >>> /Miguel >>> >> >> -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain >> _______________________________________________ Simple mailing list >> Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From pkyzivat@alum.mit.edu Wed Sep 12 09:04:32 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9FD21F856C for ; Wed, 12 Sep 2012 09:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df1mTzOl+JFI for ; Wed, 12 Sep 2012 09:04:31 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4321F8543 for ; Wed, 12 Sep 2012 09:04:31 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id yAqY1j00616LCl055G4aVE; Wed, 12 Sep 2012 16:04:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id yG4C1j00M3ZTu2S3SG4Cni; Wed, 12 Sep 2012 16:04:12 +0000 Message-ID: <5050B28D.4000206@alum.mit.edu> Date: Wed, 12 Sep 2012 12:04:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> In-Reply-To: <50509316.6020604@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:04:32 -0000 On 9/12/12 9:50 AM, Miguel A. Garcia wrote: > On 11/09/2012 21:24, Paul Kyzivat wrote: >> On 9/11/12 2:51 PM, Ben Campbell wrote: >>> >>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>> >>>> >>>> On Sep 11, 2012, at 1:17 PM, "Eric >>>> Burger" wrote: >>>> >>>>> We solved the three-out-of-four endpoints understand D problem >>>>> years ago. See RFC 3459. UAC's mark the message as critical (gets >>>>> rejected if unable to send to all recipients) or not critical (gets >>>>> silently dropped or destination gets a notice). >>>> >>>> That's an interesting and likely useful approach. I'm concerned that >>>> it's a bit of feature creep for this draft, though. At least, it's a >>>> non-trivial feature that the working group had not contemplated so >>>> far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent >>>> effort to when we did the delivery status notification work for >>>> MESSAGE. >>> >>> Okay, before anyone jumps on that, on a more careful read of 3459, I >>> realize it would be less work than DSN. But it's still a substantial >>> new feature for this late in the draft's life cycle. That doesn't >>> mean we can't add it if we Really Need It (TM) for the rest of the >>> draft to be useful. Do we? >> >> ISTM that now we are realizing we have had the feature all along and >> just never realized it. So there is nothing to do other than maybe point >> out to people that they should do it. >> >> Thanks, >> Paul >> >>>> >>>> Can we live with some implementor guidance that they need to think >>>> about this, and leave a formal solution as future work if anyone >>>> wants to do it? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> > > At this point in time, I believe we don't really understand all the use > cases and problems that we will get when we introduce the > Content-Disposition handling parameter. Let me give you one example of > added complexity: > > Alice sends a message to the chat room. The MSRP switch distribute to > Bob and Charlie, because both indicated an accept-wrapped-types of "*". > Bob accepts the content, but not Charlie. Charlie "MUST take the > appropriate failure action " [RFC3459], but which one is it? And then, > when the MSRP switch receives such 'failure action', what should it do > towards the sender? And should it wait to aggregate 'failure actions' > from several potential receivers? > > So, let's be pragmatical. We don't have time nor requirements to have > this sophisticated feature at this late point in time. I will try to > think of something simple (e.g., discard on error). If someone is > interested, he or she should collect requirements and write an extension. > > Is this reasonable? If so, I will come up with text for review? Yes, I am sympathetic that this is a rat hole that would be good to avoid for now. I just don't want to see something done that *requires* action in conflict with what the Content-Disposition would call for. (IOW it should be ok for an implementation to be guided by the C-D handling parameter if it wishes.) Thanks, Paul From pkyzivat@alum.mit.edu Wed Sep 12 09:07:18 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A373321F85AC for ; Wed, 12 Sep 2012 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.427 X-Spam-Level: X-Spam-Status: No, score=-0.427 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UttHBgBC5U7Q for ; Wed, 12 Sep 2012 09:07:18 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D9AB221F856C for ; Wed, 12 Sep 2012 09:07:17 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id y9xh1j0020cZkys53G7M67; Wed, 12 Sep 2012 16:07:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id yG7H1j0013ZTu2S3WG7HPl; Wed, 12 Sep 2012 16:07:17 +0000 Message-ID: <5050B335.6060502@alum.mit.edu> Date: Wed, 12 Sep 2012 12:07:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Miguel A. Garcia" References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> <505095D4.7020803@ericsson.com> In-Reply-To: <505095D4.7020803@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 16:07:18 -0000 On 9/12/12 10:01 AM, Miguel A. Garcia wrote: > On 12/09/2012 15:50, Miguel A. Garcia wrote: >> On 11/09/2012 21:24, Paul Kyzivat wrote: >>> On 9/11/12 2:51 PM, Ben Campbell wrote: >>>> >>>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>>> >>>>> >>>>> On Sep 11, 2012, at 1:17 PM, "Eric >>>>> Burger" wrote: >>>>> >>>>>> We solved the three-out-of-four endpoints understand D problem >>>>>> years ago. See RFC 3459. UAC's mark the message as critical (gets >>>>>> rejected if unable to send to all recipients) or not critical >>>>>> (gets silently dropped or destination gets a notice). >>>>> >>>>> That's an interesting and likely useful approach. I'm concerned >>>>> that it's a bit of feature creep for this draft, though. At least, >>>>> it's a non-trivial feature that the working group had not >>>>> contemplated so far. Mapping rfc3459 to MSRP seems like an effort >>>>> roughly equivalent effort to when we did the delivery status >>>>> notification work for MESSAGE. >>>> >>>> Okay, before anyone jumps on that, on a more careful read of 3459, I >>>> realize it would be less work than DSN. But it's still a substantial >>>> new feature for this late in the draft's life cycle. That doesn't >>>> mean we can't add it if we Really Need It (TM) for the rest of the >>>> draft to be useful. Do we? >>> >>> ISTM that now we are realizing we have had the feature all along and >>> just never realized it. So there is nothing to do other than maybe point >>> out to people that they should do it. >>> >>> Thanks, >>> Paul >>> >>>>> >>>>> Can we live with some implementor guidance that they need to think >>>>> about this, and leave a formal solution as future work if anyone >>>>> wants to do it? >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >> >> At this point in time, I believe we don't really understand all the use >> cases and problems that we will get when we introduce the >> Content-Disposition handling parameter. Let me give you one example of >> added complexity: >> >> Alice sends a message to the chat room. The MSRP switch distribute to Bob >> and Charlie, because both indicated an accept-wrapped-types of "*". Bob >> accepts the content, but not Charlie. Charlie "MUST take the appropriate >> failure action " [RFC3459], but which one is it? And then, when the MSRP >> switch receives such 'failure action', what should it do towards the >> sender? And should it wait to aggregate 'failure actions' from several >> potential receivers? >> >> So, let's be pragmatical. We don't have time nor requirements to have >> this sophisticated feature at this late point in time. I will try to >> think of something simple (e.g., discard on error). If someone is >> interested, he or she should collect requirements and write an extension. >> >> Is this reasonable? If so, I will come up with text for review? > > This is the text I propose to add. Please comment. > > When generating a copy of the SEND request to each > participant in the chat room, the MSRP switch MUST evaluate > the wrapped media types that the recipient is able to > accept. This was learned through the 'accept-wrapped-types' > attribute of the MSRP message media line in SDP. If the > current. If the MSRP switch is aware that the media type of > the wrapped content is not acceptable to the recipient, the > MSRP switch SHOULD NOT forward this message to that > endpoint. Note that this version of the specification does > not require the MSRP switch to notify the sender about this > failure. Extensions to this specification may improve > handling of unknown media types. Yes, this works for me. Thanks, Paul From saul@ag-projects.com Thu Sep 13 01:28:25 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762A21F8546 for ; Thu, 13 Sep 2012 01:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS7zpVe3mg8v for ; Thu, 13 Sep 2012 01:28:25 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CD2BE21F8540 for ; Thu, 13 Sep 2012 01:28:24 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id EEB17B014F; Thu, 13 Sep 2012 10:28:22 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E5CE5B007E; Thu, 13 Sep 2012 10:28:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <504F329F.6030703@ericsson.com> Date: Thu, 13 Sep 2012 10:28:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C2D3D38-CEEF-47AF-8A6C-21BB255197E6@ag-projects.com> References: <504F329F.6030703@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 08:28:26 -0000 Hi, On Sep 11, 2012, at 2:46 PM, Miguel A. Garcia wrote: > Hi, >=20 > the chat draft uses the 'accept-wrapped-types' in SDP for negotiating = a minimum set of supported types inside the Message/CPIM wrappers. >=20 > While I was replying to Stephen Farrell's IESG review, he had a = question, and that one brought me another one. I am seeking advice as = for how to proceed. >=20 > So, here are the questions: >=20 > 1) Version -16 of the draft is a bit silent with respect = 'accept-wrapped-types. I first proposed these two paragraphs to be added = to version -17, however, I have concerns with one of them (see below). >=20 > It is RECOMMENDED that participant endpoints > add an 'accept-wrapped-types' attribute to the MSRP 'message' media > line in SDP, where the supported wrapped types are declared, as per > RFC 4975 procedures [RFC4975]. >=20 > The conference focus SHOULD also add an 'accept-wrapped-types' > attribute to the MSRP message media line in SDP containing the > supported wrapped types. >=20 > My question is... does the conference focus need to add an = 'accept-wrapped-types'? The MSRP switch never interprets the actual = payload contents, so, for the MSRP switch, the actual payload in instant = messages is transparent. So, why should the MSRP switch care? Why should = the focus add an 'accept-wrapped-types' at all? >=20 > I propose to replace the initially proposed "SHOULD" with a "MAY" in = the previous paragraph. >=20 Well, that "never interprets" cannot be guaranteed. I'm toying with an = idea for using a specific content type to be used as a control protocol = for some specific functionality, for example, so the server would need = to interpret it. Also, in the implementation I've working on, we keep a short history of = the messages sent to a room, to give newcomers some context. I don't = want to store composing indication chunks and send a newcomer a storm of = them, so I'm selective in what I save to this "history". IIRC private messages sent through the room are actually identified as = private after checking the CPIM headers, so checking the =46rom and To = headers vs checking the Content-Type in order to validate the wrapped = types doesn't make much of a difference, does it? >=20 > 2) Stephen Farrel is questioning what should the MSRP switch do if one = sender sends an instant message to the chat room, the message containing = a type (inside Message/CPIM) that not all the recipients can understand. = In other words, the MSRP switch/focus has received SDP indicating that = an endpoint supports types A, B, and C. If another participant sends a = message with type D, what should the MSRP switch do? >=20 > Possibilities include: > a) Do nothing; forward the message to D, he should deal with the = issue. I don't like this, because it is bypassing the MSRP accept-* = negotiation. >=20 > b) Do not forward the message to this user, but forward to others who = accept this type. It is possible that the MSRP switch injects a warning = instant message to the sender, indicating this condition. >=20 > c) Reject the message to the sender (i.e., do not forward to any = user). I don't like this option either, because the poor sender has done = nothing wrong. Additionally, this is the dictatorship of the minority (a = few people who do not support a type that will be supported by the = majority will impose their rules). And it will be so easy to kill a chat = room by just logging in supporting only weird type that none else = supports. >=20 > So, probably b) is the less worst of all. Comments? >=20 +1 for b. > I also want to highlight that this is a bit theoretical problem. I = expect most implementations to support all commonly known types. = Additionally, I expect implementations to add a "*" to indicate support = for additional types that have not been explicitly listed, in which = case, the MSRP switch will not do any filter, and it is about the = endpoint to render the content or not. >=20 > Comments? >=20 I think someone brought this up further down the thread, but given that = this is a specification for "chat" shouldn't this specification mandate = a lowest common denominator type (for the focus) such as text/plain ? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Thu Sep 13 01:29:08 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E53A21F8551 for ; Thu, 13 Sep 2012 01:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCURZ1ODBu2Z for ; Thu, 13 Sep 2012 01:29:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5281221F854A for ; Thu, 13 Sep 2012 01:29:07 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 97B1BB0104; Thu, 13 Sep 2012 10:29:06 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 6453EB007E; Thu, 13 Sep 2012 10:29:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <505095D4.7020803@ericsson.com> Date: Thu, 13 Sep 2012 10:29:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1C294B97-8B84-411C-A1D3-68F68D76AF6D@ag-projects.com> References: <504F329F.6030703@ericsson.com> <21004EDC-F763-4C1D-AD81-17A19ECCF7A5@nostrum.com> <504F59A3.9060909@alum.mit.edu> <4FB22492-230C-4D1E-AD12-9BC38C649DFF@nostrum.com> <504F8FE9.40403@alum.mit.edu> <50509316.6020604@ericsson.com> <505095D4.7020803@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" , Paul Kyzivat Subject: Re: [Simple] Chat: questions on 'accept-wrapped-types' X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 08:29:08 -0000 On Sep 12, 2012, at 4:01 PM, Miguel A. Garcia wrote: > On 12/09/2012 15:50, Miguel A. Garcia wrote: >> On 11/09/2012 21:24, Paul Kyzivat wrote: >>> On 9/11/12 2:51 PM, Ben Campbell wrote: >>>>=20 >>>> On Sep 11, 2012, at 1:46 PM, Ben Campbell wrote: >>>>=20 >>>>>=20 >>>>> On Sep 11, 2012, at 1:17 PM, "Eric = Burger" wrote: >>>>>=20 >>>>>> We solved the three-out-of-four endpoints understand D problem = years ago. See RFC 3459. UAC's mark the message as critical (gets = rejected if unable to send to all recipients) or not critical (gets = silently dropped or destination gets a notice). >>>>>=20 >>>>> That's an interesting and likely useful approach. I'm concerned = that it's a bit of feature creep for this draft, though. At least, it's = a non-trivial feature that the working group had not contemplated so = far. Mapping rfc3459 to MSRP seems like an effort roughly equivalent = effort to when we did the delivery status notification work for MESSAGE. >>>>=20 >>>> Okay, before anyone jumps on that, on a more careful read of 3459, = I realize it would be less work than DSN. But it's still a substantial = new feature for this late in the draft's life cycle. That doesn't mean = we can't add it if we Really Need It (TM) for the rest of the draft to = be useful. Do we? >>>=20 >>> ISTM that now we are realizing we have had the feature all along and >>> just never realized it. So there is nothing to do other than maybe = point >>> out to people that they should do it. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>>>=20 >>>>> Can we live with some implementor guidance that they need to think = about this, and leave a formal solution as future work if anyone wants = to do it? >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>=20 >> At this point in time, I believe we don't really understand all the = use >> cases and problems that we will get when we introduce the >> Content-Disposition handling parameter. Let me give you one example = of >> added complexity: >>=20 >> Alice sends a message to the chat room. The MSRP switch distribute to = Bob >> and Charlie, because both indicated an accept-wrapped-types of "*". = Bob >> accepts the content, but not Charlie. Charlie "MUST take the = appropriate >> failure action " [RFC3459], but which one is it? And then, when the = MSRP >> switch receives such 'failure action', what should it do towards the >> sender? And should it wait to aggregate 'failure actions' from = several >> potential receivers? >>=20 >> So, let's be pragmatical. We don't have time nor requirements to have >> this sophisticated feature at this late point in time. I will try to >> think of something simple (e.g., discard on error). If someone is >> interested, he or she should collect requirements and write an = extension. >>=20 >> Is this reasonable? If so, I will come up with text for review? >=20 > This is the text I propose to add. Please comment. >=20 > When generating a copy of the SEND request to each > participant in the chat room, the MSRP switch MUST evaluate > the wrapped media types that the recipient is able to > accept. This was learned through the 'accept-wrapped-types' > attribute of the MSRP message media line in SDP. If the > current. If the MSRP switch is aware that the media type of > the wrapped content is not acceptable to the recipient, the > MSRP switch SHOULD NOT forward this message to that > endpoint. Note that this version of the specification does > not require the MSRP switch to notify the sender about this > failure. Extensions to this specification may improve > handling of unknown media types. >=20 +1. -- Sa=FAl Ibarra Corretg=E9 AG Projects From neil.cook@noware.co.uk Fri Sep 14 06:01:23 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3F621F84D2 for ; Fri, 14 Sep 2012 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uubEfn4QuYP for ; Fri, 14 Sep 2012 06:01:22 -0700 (PDT) Received: from ncookx.randomflow.net (ncookx.randomflow.net [78.129.143.222]) by ietfa.amsl.com (Postfix) with ESMTP id B412721F84EA for ; Fri, 14 Sep 2012 06:01:22 -0700 (PDT) Received: from [172.22.41.16] (pa2-nat.cloudmark.com [77.242.202.133]) by ncookx.randomflow.net (Postfix) with ESMTP id E30CE1FD33 for ; Fri, 14 Sep 2012 12:42:37 +0000 (UTC) From: Neil Cook Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Sep 2012 15:01:20 +0200 Message-Id: To: simple@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] Encapsulating MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:01:23 -0000 Hi all, I'm looking at encapsulating MRSP within another protocol (e.g. HTTP or = SMTP), however looking at the MSRP spec, there isn't a message/msrp = Content-Type defined, nor can I see one on the IANA website. Any thoughts? Is this an omission? thanks, Neil Cook From ben@nostrum.com Fri Sep 14 06:43:24 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECDB21F84F6 for ; Fri, 14 Sep 2012 06:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF6nvgxxSmro for ; Fri, 14 Sep 2012 06:43:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1F21F84F2 for ; Fri, 14 Sep 2012 06:43:23 -0700 (PDT) Received: from [10.0.1.30] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q8EDhIqK039858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 14 Sep 2012 08:43:18 -0500 (CDT) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Ben Campbell In-Reply-To: Date: Fri, 14 Sep 2012 08:43:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Neil Cook X-Mailer: Apple Mail (2.1486) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] Encapsulating MSRP X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 13:43:24 -0000 On Sep 14, 2012, at 8:01 AM, Neil Cook wrote: > Hi all, >=20 > I'm looking at encapsulating MRSP within another protocol (e.g. HTTP = or SMTP), however looking at the MSRP spec, there isn't a message/msrp = Content-Type defined, nor can I see one on the IANA website. >=20 > Any thoughts? Is this an omission? You are correct, there is not one. That's not something the IETF = typically defines until one finds a need for it in some other standard = (or standard to be). We haven't needed one to date. I'm curious what you have in mind for it? Thanks! Ben. From stpeter@stpeter.im Fri Sep 21 13:30:26 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3E421E8084 for ; Fri, 21 Sep 2012 13:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzQwNQgkRsxZ for ; Fri, 21 Sep 2012 13:30:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B1EC821E8064 for ; Fri, 21 Sep 2012 13:30:25 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BA01D40D52 for ; Fri, 21 Sep 2012 14:31:37 -0600 (MDT) Message-ID: <505CCE60.40905@stpeter.im> Date: Fri, 21 Sep 2012 14:30:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 20:30:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Are there any limits on the length of a nickname in draft-ietf-simple-chat? I don't see any, nor do I see any on quoted-string in RFC 4975. In draft-ietf-precis-nickname, I have a limit of 1023 bytes, which comes from RFC 6122 and is probably longer than most people will ever use. I received one comment that the nickname spec is the wrong place to be imposing such limits, and that makes sense (XMPP can impose one limit and MSRP can impose another limit, etc.). But I figured it would be good to check here before making a change to draft-ietf-precis-nickname on this point. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBczmAACgkQNL8k5A2w/vxMBACfVNkZu20suH6y8YpUiheqqRlA k3QAnjIh14L+v0blh6289vSTHkhb4GUl =BMNN -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Sep 21 20:18:29 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D606E21E80EF for ; Fri, 21 Sep 2012 20:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SflurvkoFJ7D for ; Fri, 21 Sep 2012 20:18:28 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C63F221E804D for ; Fri, 21 Sep 2012 20:18:28 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8640640D52 for ; Fri, 21 Sep 2012 21:19:41 -0600 (MDT) Message-ID: <505D2E03.2050101@stpeter.im> Date: Fri, 21 Sep 2012 21:18:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <505CCE60.40905@stpeter.im> In-Reply-To: <505CCE60.40905@stpeter.im> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Simple] nickname length X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 03:18:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The more I think about this, the more I realize that nickname length is best left up to protocol specifications for MSRP and XMPP, not the nickname spec itself. Unless there are objections, I plan to remove the relevant paragraph from draft-ietf-precis-nickname. On 9/21/12 2:30 PM, Peter Saint-Andre wrote: > Are there any limits on the length of a nickname in > draft-ietf-simple-chat? I don't see any, nor do I see any on > quoted-string in RFC 4975. In draft-ietf-precis-nickname, I have a > limit of 1023 bytes, which comes from RFC 6122 and is probably > longer than most people will ever use. I received one comment that > the nickname spec is the wrong place to be imposing such limits, > and that makes sense (XMPP can impose one limit and MSRP can impose > another limit, etc.). But I figured it would be good to check here > before making a change to draft-ietf-precis-nickname on this > point. > > Thanks! > > Peter > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBdLgMACgkQNL8k5A2w/vzpfQCdGeCGvS29+7CrMIKwzKeP4HVO vBUAnAgvo5gFc0Ksq7tpPL3UvybRFQh/ =ZMK/ -----END PGP SIGNATURE----- From stpeter@stpeter.im Sun Sep 23 11:48:33 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616B721F8470 for ; Sun, 23 Sep 2012 11:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJrLbItL1rGh for ; Sun, 23 Sep 2012 11:48:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AEBD421F8468 for ; Sun, 23 Sep 2012 11:48:32 -0700 (PDT) Received: from [192.168.1.197] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6B85A40DA5 for ; Sun, 23 Sep 2012 12:49:51 -0600 (MDT) Message-ID: <505F5983.4010102@stpeter.im> Date: Sun, 23 Sep 2012 12:48:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: simple@ietf.org References: <505F52C5.3020506@stpeter.im> In-Reply-To: <505F52C5.3020506@stpeter.im> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <505F52C5.3020506@stpeter.im> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Simple] Fwd: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Sep 2012 18:48:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. This also includes removal of the length restriction. I now consider this I-D stable and would very much welcome reviews from folks here. If no one volunteers to volunteer this little spec (only 7 pages!), I'll start poking people individually. ;-) - -------- Original Message -------- Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt Date: Sun, 23 Sep 2012 12:19:49 -0600 From: Peter Saint-Andre To: precis@ietf.org Minor changes to align with the IANA registration template in the framework... On 9/23/12 12:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Preparation and > Comparison of Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Nicknames > Author(s) : Peter Saint-Andre Filename : > draft-ietf-precis-nickname-02.txt Pages : 7 Date : > 2012-09-23 > > Abstract: This document describes how to prepare and compare > Unicode strings representing nicknames, primarily as used within > textual chatrooms. This profile is intended to be used by chatroom > technologies based on both the Message Session Relay Protocol > (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-nickname-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ precis mailing list > precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBfWYMACgkQNL8k5A2w/vxgnQCg5QmVajkV447tL8zh/+F4phWN xu0An33p0Fv7yK/uLOgtlfDtf/HfoewX =3YII -----END PGP SIGNATURE----- From mary.ietf.barnes@gmail.com Mon Sep 24 14:25:16 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05E121F88CE for ; Mon, 24 Sep 2012 14:25:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.323 X-Spam-Level: X-Spam-Status: No, score=-103.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l73TuTA4Q0X for ; Mon, 24 Sep 2012 14:25:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4321F88C4 for ; Mon, 24 Sep 2012 14:25:14 -0700 (PDT) Received: by lbok13 with SMTP id k13so1692380lbo.31 for ; Mon, 24 Sep 2012 14:25:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pM4KdetpvS+VdKkOJWZt3Ntap5jH1SErwE37MEzt9Tk=; b=bGpEQH0Wsh6FlQqqzgfwA4sdmrECTYNQr612Ivf2sgq7x5SaBSu8efmt1pGz311f6a cWSQpFMlYhAsnNuYI6BXq2/vLQSXfNLQAf2BJfOdEX2yqUy8Pp2EUqnMLCz4R583/u2Y M7YMX2kbfMKDxW0odqfJyqaJM+IWutt45lFnEYRPS1h2MBHaAvUs5yYSwIythMzWDRP7 EsK21dV4kSxs+9QozxHI7Kxbhay8av0lkngGn8DK5IWrBVsc55EowpRVNj+eMyWUrqth zZQoZVixQ9F4skK/q7jP4KbGyma/2lKn1yS1wOlnUu8u2RLZorb+idmFPbSBmeIwKGuP IQTA== MIME-Version: 1.0 Received: by 10.112.82.168 with SMTP id j8mr4880539lby.22.1348521912685; Mon, 24 Sep 2012 14:25:12 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 24 Sep 2012 14:25:12 -0700 (PDT) In-Reply-To: <505F5983.4010102@stpeter.im> References: <505F52C5.3020506@stpeter.im> <505F5983.4010102@stpeter.im> Date: Mon, 24 Sep 2012 16:25:12 -0500 Message-ID: From: Mary Barnes To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=f46d04016d8793d58b04ca79398b Cc: simple@ietf.org Subject: Re: [Simple] Fwd: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 21:25:16 -0000 --f46d04016d8793d58b04ca79398b Content-Type: text/plain; charset=ISO-8859-1 I think the document looks good. I do have one comment, however. I have updated draft-boulton-xcon-session-chat to use this document for nickname comparisons, as well. So, I would suggest changing the abstract from: This profile is intended to be used by chatroom technologies based on both the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). to: This profile is intended to be used by chatroom technologies such as the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). Or, you could include the XCON Chat feature in that list, as well. Thanks, Mary. On Sun, Sep 23, 2012 at 1:48 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI. This also includes removal of the length restriction. I now > consider this I-D stable and would very much welcome reviews from > folks here. If no one volunteers to volunteer this little spec (only 7 > pages!), I'll start poking people individually. ;-) > > > - -------- Original Message -------- > Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt > Date: Sun, 23 Sep 2012 12:19:49 -0600 > From: Peter Saint-Andre > To: precis@ietf.org > > Minor changes to align with the IANA registration template in the > framework... > > On 9/23/12 12:12 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Preparation and > > Comparison of Internationalized Strings Working Group of the IETF. > > > > Title : Preparation and Comparison of Nicknames > > Author(s) : Peter Saint-Andre Filename : > > draft-ietf-precis-nickname-02.txt Pages : 7 Date : > > 2012-09-23 > > > > Abstract: This document describes how to prepare and compare > > Unicode strings representing nicknames, primarily as used within > > textual chatrooms. This profile is intended to be used by chatroom > > technologies based on both the Message Session Relay Protocol > > (MSRP) and the Extensible Messaging and Presence Protocol (XMPP). > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-precis-nickname > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-precis-nickname-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-precis-nickname-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ precis mailing list > > precis@ietf.org https://www.ietf.org/mailman/listinfo/precis > > > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ > > iEYEARECAAYFAlBfWYMACgkQNL8k5A2w/vxgnQCg5QmVajkV447tL8zh/+F4phWN > xu0An33p0Fv7yK/uLOgtlfDtf/HfoewX > =3YII > -----END PGP SIGNATURE----- > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > --f46d04016d8793d58b04ca79398b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think the document looks good. =A0I do have one comment, however. =A0I ha= ve updated
draft-boulton-xcon-session-chat=A0to use this document for n= ickname comparisons, as well.

So, I would sug= gest changing the abstract from:
   This profile is intended to be used by chatroom technologies=A0
based on both the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP).
to:
= 
   This profile is intended to be used by chatroom technologies=A0
such as=20 the Message Session Relay Protocol (MSRP) and the Extensible Messaging and Presence Protocol (XMPP).

Or, you could include the XCON Chat feature in that list, as well.=A0=

Thanks,
Mary.=A0

On Sun, Sep 23, 2012 at 1:48 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI. This also includes removal of the length restriction. I now
consider this I-D stable and would very much welcome reviews from
folks here. If no one volunteers to volunteer this little spec (only 7
pages!), I'll start poking people individually. ;-)


- -------- Original Message --------
Subject: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt
Date: Sun, 23 Sep 2012 12:19:49 -0600
From: Peter Saint-Andre <stpeter@s= tpeter.im>
To: precis@ietf.org

Minor changes to align with the IANA registration template in the
framework...

On 9/23/12 12:12 PM, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Preparation and
> Comparison of Internationalized Strings Working Group of the IETF.
>
> Title =A0 =A0 =A0 =A0 =A0 : Preparation and Comparison of Nicknames > Author(s) : Peter Saint-Andre Filename =A0 =A0 =A0 =A0:
> draft-ietf-precis-nickname-02.txt Pages =A0 =A0 =A0 =A0 =A0 : 7 Date :=
> 2012-09-23
>
> Abstract: This document describes how to prepare and compare
> Unicode strings representing nicknames, primarily as used within
> textual chatrooms. This profile is intended to be used by chatroom
> technologies based on both the Message Session Relay Protocol
> (MSRP) and the Extensible Messaging and Presence Protocol (XMPP).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-precis-nick= name
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-precis-nickname-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-prec= is-nickname-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________ precis mailing list > precis@ietf.org https://www.iet= f.org/mailman/listinfo/precis
>


_______________________________________________
precis mailing list
precis@ietf.org
= https://www.ietf.org/mailman/listinfo/precis


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBfWYMACgkQNL8k5A2w/vxgnQCg5QmVajkV447tL8zh/+F4phWN
xu0An33p0Fv7yK/uLOgtlfDtf/HfoewX
=3D3YII
-----END PGP SIGNATURE-----
_______________________________________________
Simple mailing list
Simple@ietf.org
= https://www.ietf.org/mailman/listinfo/simple

--f46d04016d8793d58b04ca79398b-- From stpeter@stpeter.im Mon Sep 24 14:33:13 2012 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405DA21F8838 for ; Mon, 24 Sep 2012 14:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fy09IClb4OjZ for ; Mon, 24 Sep 2012 14:33:12 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B7A2F1F041D for ; Mon, 24 Sep 2012 14:33:12 -0700 (PDT) Received: from [64.101.72.41] (unknown [64.101.72.41]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B1EAA40062; Mon, 24 Sep 2012 15:34:34 -0600 (MDT) Message-ID: <5060D197.5020907@stpeter.im> Date: Mon, 24 Sep 2012 15:33:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Mary Barnes References: <505F52C5.3020506@stpeter.im> <505F5983.4010102@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] Fwd: Re: [precis] I-D Action: draft-ietf-precis-nickname-02.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 21:33:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Mary, thanks for the review! On 9/24/12 3:25 PM, Mary Barnes wrote: > I think the document looks good. I do have one comment, however. > I have updated draft-boulton-xcon-session-chat to use this document > for nickname comparisons, as well. > > So, I would suggest changing the abstract from: > > This profile is intended to be used by chatroom technologies > > based on both the Message Session Relay Protocol (MSRP) and the > Extensible Messaging and Presence Protocol (XMPP). > > to: > > This profile is intended to be used by chatroom technologies such > as the Message Session Relay Protocol (MSRP) and the Extensible > Messaging and Presence Protocol (XMPP). Yes, that makes sense. It could even be used by non-chatroom technologies, it's just that the chatroom uses are the driving force now. Will fix. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBg0ZcACgkQNL8k5A2w/vwR9ACdGWJFTXZ5ZkVZTn7Mmpi7OC52 L4oAoJaJ+VcjwDyVrBch8+EDeyS1D6Wv =pP5w -----END PGP SIGNATURE-----