From christer.holmberg@ericsson.com Sun Oct 2 13:20:21 2011 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 B8E6D21F84DB for ; Sun, 2 Oct 2011 13:20:21 -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.226, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lltjYRJFSy5Z for ; Sun, 2 Oct 2011 13:20:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2FC21F84DA for ; Sun, 2 Oct 2011 13:20:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-93-4e88c8370d35 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 37.B5.20773.738C88E4; Sun, 2 Oct 2011 22:23:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sun, 2 Oct 2011 22:23:19 +0200 From: Christer Holmberg To: Miguel Garcia A , Staffan Blau , Eric Burger , Simple WG Date: Sun, 2 Oct 2011 22:23:16 +0200 Thread-Topic: SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments Thread-Index: AcyBJCT4BkXcW5kaSbeAv2gd0TJ4ZQADjXTA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> References: <4E889797.9010204@ericsson.com> In-Reply-To: <4E889797.9010204@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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, 02 Oct 2011 20:20:21 -0000 Hi, I have removed the MMUSIC list from this reply, and added the SIMPLE list, = as there should be no issues with the SDP attribute related comments. > Here are some comments related to the new "msrp-cema"=20 > attribute defined in draft-ietf-simple-msrp-cema-02.txt >=20 > - I am missing a section that has the syntax of the new=20 > extension. While it's true that the syntax is fairly simple,=20 > any extension should clearly specify the syntax (in this=20 > case, ABNF). This formal syntax could be: >=20 > attribute /=3D msrp-cema-attr > ; attribute defined in RFC 4566 > msrp-cema-attr =3D "msrp-cema" >=20 > I also suggest to add a section titled "The SDP 'msrp-cema'=20 > attribute"=20 > where you first give an overview of what the attribute does=20 > at a very high level (in this case, it indicates support for=20 > the CEMA mechanism), and then you include the formal syntax. I suggest the following new section: "5. The SDP 'msrp-cema' attribute 5.1. General The SDP 'msrp-cema' attribute is used by MSRP entities to indicate support of the CEMA extension, according to the procedures in Sections 4.2 and 4.3. 5.2. Syntax This section describes the syntax extensions to the ABNF syntax defined in RFC 4566 required for the SDP 'msrp-cema' attribute. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. attribute /=3D msrp-cema-attr ;attribute defined in RFC 456= 6 msrp-cema-attr =3D "msrp-cema"" ---------------- > - General. When you mention an SDP attribute, the "a=3D" is nor=20 > part of the attribute itself. So, it is not correct to say: >=20 > the a=3Dpath attribute >=20 > The correct one is: >=20 > the 'path' attribute I will change as suggested. ---------------- =20 > - The title of sections 4.2 and 4.3 could be improved. There=20 > is not such things as "MSRP offer" or "MSRP answer". We have=20 > the notion of "SDP offer" and "SDP answer", as well as "SDP=20 > offerer" and "SDP answerer", in which case, the sections=20 > should be titled "SDP offerer procedures" and "SDP answerer=20 > procedures". I suggest chaning to "MSRP SDP offerer procedures" and "MSRP SDP answerer p= rocedures". ---------------- > Furthermore, it is quite confusing to follow these sections=20 > because they refer to the "MSRP endpoint" and the "remote=20 > MSRP endpoint". Obviously, what is the "MSRP endpoint" in=20 > Section 4.2, becomes the "remote MSRP endpoint" in Section=20 > 4.3, and vice versa. I suggest to re-write these sections in=20 > terms of "the SDP offerer" and "the SDP answerer". This will=20 > make the text much clearer, and the terms will not reverse=20 > when we change sections. Christian Schmidt had a similar comment. I will change as suggested. ---------------- > - Section 4.1. I think those three bullet points are the real=20 > "Applicability Statement" rather than something general to=20 > the mechanism.=20 > To me, they should be moved to Section 3. The bullets gives an overview when there will be a fallback, but the extens= ion as such is still applicable in those cases. ---------------- > - Sections 4.1 to 4.3, the text says that an "MSRP endpoint=20 > becomes 'active'" or 'passive'. I was confused with what the=20 > text was meaning. I guess it means from the point of view of=20 > the TCP connection used for MSRP. I think this should be clarified. I suggest adding a reference to RFC 6135 (Comedia for MSRP) to the first oc= curence. ---------------- =20 > - Section 4.2, 2nd bullet point. I am missing that this=20 > bullet point says how to populate the c/m lines in SDP.=20 > Perhaps it is covered by the first paragraph of this Section=20 > 4.2, which basically refers to RFC 4975 and 4976. But then,=20 > the third bullet point describes the m/c line, so, at this=20 > point in time, I had my doubts whether bullet point forgets=20 > to say something of the c/m line or it is populated as per=20 > RFC 4975/4976. The 2nd bullet is covered by RFC 4975. The 3rd bullet, however, is not according to RFC 4976, which is the reason = it is explicitly said how to populate the c/m line. ---------------- > - In order to add a bit of clarity and separate the=20 > generation of the SDP offer from receiving the SDP answer, I=20 > would suggest to add the following text at the beginning of=20 > the paragraph that introduces the SDP answer in Section 4.2: >=20 > "When receiving an SDP answer," and then continue with the=20 > current text "if the MSRP media description of the SDP answer ..." In order to allign with the current style, I suggest to say: "When the offerer receives an SDP answer, if the..." ---------------- > - Section 4.2, 1st bullet point of the SDP answer (and in=20 > other parts of > 4.2 and 4.3), the text says: "... does not match the=20 > information ...". I have a problem with the word "match".=20 > Most likely, "match" implies "equality". So we are talking of=20 > the equality of the c/m lines with a URI. These two can never=20 > be equal. In particular, a URI can eve be a domain name or=20 > host name, in which case, will never be equal to an IP=20 > address and a port number. Most likely you want to say=20 > "resolve", but I am not sure. The text talks about matching of "address information", so I don't think th= at is the same as matching the whole c/m line with the URI. But, I can add a note, saying that if the URI contains a domain name, it ne= eds to be resolved into an IP address before the matching is done. ---------------- > - I was trying to analyze if all the different cases are=20 > described in Section 4.2. Here is one that I believe is not=20 > covered: "if the SDP answer does not contain an 'msrp-cema'=20 > attribute and none of the 3 conditions are met". The last paragraph of the chapter talks about the case when none of the con= ditions are met. ---------------- =20 > - Section 4.3, first paragraph. The text says "MUST reject".=20 > I think it would be nice to have a motivation to have such a=20 > strong action. I will add text saying that the reason for this is that the SDP answerer as= sumes that a middlebox, that do NOT support CEMA, has modified the c/m line= of the SDP offer. ---------------- > - Section 5.4. The text says: "Middleboxes > cannot be deployed in environments that require end-to-end SDP > protection using SIP identity [RFC4916]." >=20 > I am trying to see the connection between "end-to-end SDP=20 > protection" and "SIP identity". I would have removed one of=20 > them from the text, depending on what you want to say.=20 > Perhaps you want to say that the CEMA extension does not work=20 > if "end-to-end integrity protection of SDP is used". Others have also commented on the text. I suggest to modify the text in the= following way: "This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media. Middleboxes cannot be deployed in environments that require end-to-end SDP protection using SIP identity [RFC4916]." ---------------- > - Section 7.1 does not mention the registry where IANA has to=20 > operate.=20 > Start the section saying: >=20 > "This document instructs IANA to add a attribute to the=20 > 'att-field (media level only)' registry of the SDP parameters=20 > registry, according to the following data" In order to better be alligned with the current text, I suggest to add the = following modified text: "This document instructs IANA to add a attribute to the 'att-field=20 (media level only)' registry of the SDP parameters registry, according=20 to the information provided in this section." ---------------- > - Section 7.1, "Purpose". I will not speak of the "sending=20 > UA" in an SDP registry, but of the "SDP creator". I suggest modifying to "creator of the SDP". "8.1. IANA Registration of the SDP 'msrp-cema' attribute This document instructs IANA to add a attribute to the 'att-field (media level only)' registry of the SDP parameters registry, according to the information provided in this section. This section registers a new SDP attribute, 'msrp-cema'. The required information for this registration, as specified in RFC 4566, is: Contact name: Christer Holmberg Contact e-mail: christer.holmberg@ericsson.com Attribute name: a=3Dmsrp-cema Type of attribute: media level Purpose: This attribute is used to indicate support of the MSRP Connection Establishment for Media Anchoring (CEMA) extension defined in RFC XXXX. When present in an MSRP media description of an SDP body, it indicates that the creator of the SDP supports the CEMA mechanism. Values: The attribute does not carry a value Charset dependency: none" ---------------- =20 =20 > Nits: >=20 > - First paragraph in Section 6.3: " ... manipulating message=20 > content is=20 > CEMA provides ..." > Most likely s/is/in Ok. ---------------- =20 > - I would add formal references whenever an RFC is mentioned,=20 > especially if they are part of a normative sentence. For example, "...=20 > according to the procedures of RFC 4975 [RFC4975]". I have previously been requested by IESG to include formal references only = on the first occurance, so I would suggest not to change that. But, of course, if there are first occurances, without formal references, t= hey shall of course be fixed. ---------------- > - I believe the text should say "a Message Session ..."=20 > rather than "an Message Session". >=20 > But "an MSRP message", rather than "a MSRP message" Correct. ---------------- > - Section 4.1, first paragraph. Replace "... and what SDP=20 > information" with "... and which SDP information" Ok. ---------------- > - Section 4.1, first paragraph, at the end. Replace "TLS=20 > connection for the MSRP messages" with "TLS connection for sending and=20 > receiving MSRP messages". Ok. ---------------- Regards, Christer From eburger@standardstrack.com Sun Oct 2 17:35:54 2011 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 9250B21F8515 for ; Sun, 2 Oct 2011 17:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woqpFDg1GjLF for ; Sun, 2 Oct 2011 17:35:53 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7A38421F84D5 for ; Sun, 2 Oct 2011 17:35:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=O9Q06Gq2uoFdj0Xj2IkBQdNbDKufv3Wf5njbRfXm2FTYxCS98DISJpeTK/F7s6HW09O/EjYOiBXu8o0yImUnoEfenMeesMNNlsItfNvJnWvJ9f3WdExXbcIDOIz1PH62; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:59251 helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RAWYV-0002iZ-Sc; Sun, 02 Oct 2011 17:38:52 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-189--13469464; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 2 Oct 2011 18:55:46 -0400 Message-Id: <97CF3E5D-218C-4E00-8E0C-5EB48D6CBA4C@standardstrack.com> References: <4E889797.9010204@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> To: Simple WG 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: Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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, 03 Oct 2011 00:35:54 -0000 --Apple-Mail-189--13469464 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Works for me. On Oct 2, 2011, at 4:23 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > I have removed the MMUSIC list from this reply, and added the SIMPLE = list, as there should be no issues with the SDP attribute related = comments. >=20 >=20 >> Here are some comments related to the new "msrp-cema"=20 >> attribute defined in draft-ietf-simple-msrp-cema-02.txt >>=20 >> - I am missing a section that has the syntax of the new=20 >> extension. While it's true that the syntax is fairly simple,=20 >> any extension should clearly specify the syntax (in this=20 >> case, ABNF). This formal syntax could be: >>=20 >> attribute /=3D msrp-cema-attr >> ; attribute defined in RFC 4566 >> msrp-cema-attr =3D "msrp-cema" >>=20 >> I also suggest to add a section titled "The SDP 'msrp-cema'=20 >> attribute"=20 >> where you first give an overview of what the attribute does=20 >> at a very high level (in this case, it indicates support for=20 >> the CEMA mechanism), and then you include the formal syntax. >=20 > I suggest the following new section: >=20 > "5. The SDP 'msrp-cema' attribute >=20 > 5.1. General >=20 > The SDP 'msrp-cema' attribute is used by MSRP entities = to indicate > support of the CEMA extension, according to the = procedures in > Sections 4.2 and 4.3. >=20 > 5.2. Syntax >=20 > This section describes the syntax extensions to the ABNF = syntax > defined in RFC 4566 required for the SDP 'msrp-cema' = attribute. The > ABNF defined in this specification is conformant to RFC = 5234 > [RFC5234]. >=20 > attribute /=3D msrp-cema-attr ;attribute defined in = RFC 4566 > msrp-cema-attr =3D "msrp-cema"" >=20 >=20 > ---------------- >=20 >=20 >> - General. When you mention an SDP attribute, the "a=3D" is nor=20 >> part of the attribute itself. So, it is not correct to say: >>=20 >> the a=3Dpath attribute >>=20 >> The correct one is: >>=20 >> the 'path' attribute >=20 > I will change as suggested. >=20 >=20 > ---------------- >=20 >=20 >> - The title of sections 4.2 and 4.3 could be improved. There=20 >> is not such things as "MSRP offer" or "MSRP answer". We have=20 >> the notion of "SDP offer" and "SDP answer", as well as "SDP=20 >> offerer" and "SDP answerer", in which case, the sections=20 >> should be titled "SDP offerer procedures" and "SDP answerer=20 >> procedures". >=20 > I suggest chaning to "MSRP SDP offerer procedures" and "MSRP SDP = answerer procedures". >=20 >=20 > ---------------- >=20 >=20 >> Furthermore, it is quite confusing to follow these sections=20 >> because they refer to the "MSRP endpoint" and the "remote=20 >> MSRP endpoint". Obviously, what is the "MSRP endpoint" in=20 >> Section 4.2, becomes the "remote MSRP endpoint" in Section=20 >> 4.3, and vice versa. I suggest to re-write these sections in=20 >> terms of "the SDP offerer" and "the SDP answerer". This will=20 >> make the text much clearer, and the terms will not reverse=20 >> when we change sections. >=20 > Christian Schmidt had a similar comment. I will change as suggested. >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.1. I think those three bullet points are the real=20 >> "Applicability Statement" rather than something general to=20 >> the mechanism.=20 >> To me, they should be moved to Section 3. >=20 > The bullets gives an overview when there will be a fallback, but the = extension as such is still applicable in those cases. >=20 >=20 > ---------------- >=20 >=20 >> - Sections 4.1 to 4.3, the text says that an "MSRP endpoint=20 >> becomes 'active'" or 'passive'. I was confused with what the=20 >> text was meaning. I guess it means from the point of view of=20 >> the TCP connection used for MSRP. I think this should be clarified. >=20 > I suggest adding a reference to RFC 6135 (Comedia for MSRP) to the = first occurence. >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.2, 2nd bullet point. I am missing that this=20 >> bullet point says how to populate the c/m lines in SDP.=20 >> Perhaps it is covered by the first paragraph of this Section=20 >> 4.2, which basically refers to RFC 4975 and 4976. But then,=20 >> the third bullet point describes the m/c line, so, at this=20 >> point in time, I had my doubts whether bullet point forgets=20 >> to say something of the c/m line or it is populated as per=20 >> RFC 4975/4976. >=20 > The 2nd bullet is covered by RFC 4975. >=20 > The 3rd bullet, however, is not according to RFC 4976, which is the = reason it is explicitly said how to populate the c/m line. >=20 >=20 > ---------------- >=20 >=20 >> - In order to add a bit of clarity and separate the=20 >> generation of the SDP offer from receiving the SDP answer, I=20 >> would suggest to add the following text at the beginning of=20 >> the paragraph that introduces the SDP answer in Section 4.2: >>=20 >> "When receiving an SDP answer," and then continue with the=20 >> current text "if the MSRP media description of the SDP answer ..." >=20 > In order to allign with the current style, I suggest to say: >=20 > "When the offerer receives an SDP answer, if the..." >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.2, 1st bullet point of the SDP answer (and in=20 >> other parts of >> 4.2 and 4.3), the text says: "... does not match the=20 >> information ...". I have a problem with the word "match".=20 >> Most likely, "match" implies "equality". So we are talking of=20 >> the equality of the c/m lines with a URI. These two can never=20 >> be equal. In particular, a URI can eve be a domain name or=20 >> host name, in which case, will never be equal to an IP=20 >> address and a port number. Most likely you want to say=20 >> "resolve", but I am not sure. >=20 > The text talks about matching of "address information", so I don't = think that is the same as matching the whole c/m line with the URI. >=20 > But, I can add a note, saying that if the URI contains a domain name, = it needs to be resolved into an IP address before the matching is done. >=20 >=20 > ---------------- >=20 >=20 >> - I was trying to analyze if all the different cases are=20 >> described in Section 4.2. Here is one that I believe is not=20 >> covered: "if the SDP answer does not contain an 'msrp-cema'=20 >> attribute and none of the 3 conditions are met". >=20 > The last paragraph of the chapter talks about the case when none of = the conditions are met. >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.3, first paragraph. The text says "MUST reject".=20 >> I think it would be nice to have a motivation to have such a=20 >> strong action. >=20 > I will add text saying that the reason for this is that the SDP = answerer assumes that a middlebox, that do NOT support CEMA, has = modified the c/m line of the SDP offer. >=20 >=20 > ---------------- >=20 >=20 >> - Section 5.4. The text says: "Middleboxes >> cannot be deployed in environments that require end-to-end SDP >> protection using SIP identity [RFC4916]." >>=20 >> I am trying to see the connection between "end-to-end SDP=20 >> protection" and "SIP identity". I would have removed one of=20 >> them from the text, depending on what you want to say.=20 >> Perhaps you want to say that the CEMA extension does not work=20 >> if "end-to-end integrity protection of SDP is used". >=20 >=20 > Others have also commented on the text. I suggest to modify the text = in the following way: >=20 > "This document assumes that Middleboxes are able to = modify the SDP > address information associated with the MSRP media. = Middleboxes > cannot be deployed in environments that require = end-to-end SDP > protection using SIP identity [RFC4916]." >=20 >=20 > ---------------- >=20 >=20 >> - Section 7.1 does not mention the registry where IANA has to=20 >> operate.=20 >> Start the section saying: >>=20 >> "This document instructs IANA to add a attribute to the=20 >> 'att-field (media level only)' registry of the SDP parameters=20 >> registry, according to the following data" >=20 > In order to better be alligned with the current text, I suggest to add = the following modified text: >=20 > "This document instructs IANA to add a attribute to the = 'att-field=20 > (media level only)' registry of the SDP parameters = registry, according=20 > to the information provided in this section." >=20 >=20 > ---------------- >=20 >=20 >> - Section 7.1, "Purpose". I will not speak of the "sending=20 >> UA" in an SDP registry, but of the "SDP creator". >=20 > I suggest modifying to "creator of the SDP". >=20 >=20 > "8.1. IANA Registration of the SDP 'msrp-cema' attribute >=20 > This document instructs IANA to add a attribute to the = 'att-field > (media level only)' registry of the SDP parameters = registry, > according to the information provided in this section. >=20 > This section registers a new SDP attribute, 'msrp-cema'. = The > required information for this registration, as specified = in RFC 4566, > is: >=20 > Contact name: Christer Holmberg >=20 > Contact e-mail: christer.holmberg@ericsson.com >=20 > Attribute name: a=3Dmsrp-cema >=20 > Type of attribute: media level >=20 > Purpose: This attribute is used to indicate support of > the MSRP Connection Establishment for Media > Anchoring (CEMA) extension defined in > RFC XXXX. When present in an MSRP media > description of an SDP body, it indicates > that the creator of the SDP supports the CEMA > mechanism. >=20 > Values: The attribute does not carry a value >=20 > Charset dependency: none" >=20 >=20 > ---------------- >=20 >=20 >> Nits: >>=20 >> - First paragraph in Section 6.3: " ... manipulating message=20 >> content is=20 >> CEMA provides ..." >> Most likely s/is/in >=20 > Ok. >=20 >=20 > ---------------- >=20 >=20 >> - I would add formal references whenever an RFC is mentioned,=20 >> especially if they are part of a normative sentence. For example, = "...=20 >> according to the procedures of RFC 4975 [RFC4975]". >=20 > I have previously been requested by IESG to include formal references = only on the first occurance, so I would suggest not to change that. >=20 > But, of course, if there are first occurances, without formal = references, they shall of course be fixed. >=20 >=20 > ---------------- >=20 >=20 >> - I believe the text should say "a Message Session ..."=20 >> rather than "an Message Session". >>=20 >> But "an MSRP message", rather than "a MSRP message" >=20 > Correct. >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.1, first paragraph. Replace "... and what SDP=20 >> information" with "... and which SDP information" >=20 > Ok. >=20 >=20 > ---------------- >=20 >=20 >> - Section 4.1, first paragraph, at the end. Replace "TLS=20 >> connection for the MSRP messages" with "TLS connection for sending = and=20 >> receiving MSRP messages". >=20 > Ok. >=20 >=20 > ---------------- >=20 >=20 > Regards, >=20 > Christer >=20 --Apple-Mail-189--13469464 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 AQICEDWub7CYfsGXUhthgY5vuwcwDQYJKoZIhvcNAQEFBQAwgZMxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBT ZWN1cmUgRW1haWwgQ0EwHhcNMTEwOTA5MDAwMDAwWhcNMTIwOTA4MjM1OTU5WjArMSkwJwYJKoZI hvcNAQkBFhplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAML1VN+kPTw2iXeq1Yag6nChmCSmvCGACE3X9APNsUP2GvbYNFj6qdkayJJdhy0T aIzCiMW01sD5mSV4mi0w8EfXKn/cwqi1Brw06fwaI4T2iGXA/0zb272GR57uoH1VjMd0/Qc1h2CJ 9ueUwsxP9ufXm7Kb9+DkLGDAU+6jQQv9rTiNz8sSyjOTSmtrsVpk5MTRn0np6fybkyxcjNy2cLTX 56+gfF4SxgukWt0XAWI49y+PAp2AyG9RxX/1kTZPCEPLzitGpDTGPN7HH9sdvXyyhNT73i20BtZ0 FHRfhLIo1bRqnl3W06JjVOkNbUxFbE4p01FrF7O/kRk+WZ+FMVcCAwEAAaOCAeowggHmMB8GA1Ud IwQYMBaAFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MB0GA1UdDgQWBBSMC0QogJ7C8csD5XuRaGotm7qC mDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCsw KQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFcGA1UdHwRQME4wTKBK oEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYgGCCsGAQUFBwEBBHwwejBSBggrBgEFBQcwAoZGaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENB LmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCUGA1UdEQQeMByBGmVi dXJnZXJAc3RhbmRhcmRzdHJhY2suY29tMA0GCSqGSIb3DQEBBQUAA4IBAQATedFpXp5JcVGrEipp KirfegdjPe823Noihn8K6Em01BbEuUsPgHVY/a/6v0UNICBEAuQCwF4aJxuxSBN2GZ6XasVvlg+R nMnJP6ZZLkd8QmRSmt/AyzxCXkDQdPEJ41+ioNUmVpnGHtHliaT8yEF9EwmMDsy+efbjWomPIx5P e6MWJX/W2qQ60WhPQxD1U+3VbqWYtn6j9M89JpgQyjYku8C+oOuFUnZskIjbnWMsB3ahHEUympe0 okQT0frCohstkscVkhk63zLmHaUmhKGrJvVwFK+RBBAzuVJcwmEvQqsrczwtlO5E/Qr729Kbch6A JfmJZ7fJIL1+RbB7ORZNMYIDqzCCA6cCAQEwgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBM aW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcwCQYFKw4DAhoFAKCCAdcwGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTExMDAyMjI1NTQ3WjAjBgkqhkiG9w0BCQQxFgQU NP7Ajc/Rni14I+0MsBMVkO5bVlgwgbkGCSsGAQQBgjcQBDGBqzCBqDCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24g YW5kIFNlY3VyZSBFbWFpbCBDQQIQNa5vsJh+wZdSG2GBjm+7BzCBuwYLKoZIhvcNAQkQAgsxgaug gagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcT B1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEDWub7CYfsGXUhthgY5vuwcw DQYJKoZIhvcNAQEBBQAEggEAnzKAQZLMbPOQlBKwCxME0efQ3xVnZNnVJLTs8erM2JiZaj6CmvoG MV5uHM5ve5yoNy3TzHA1X+W9neo1F1uTLIzU6J5YvfdT2VIqX3n6lFzinag6UOIwRKrwUsKxzQeX f8tqHQu1HRVXauHDccVW+yP3WFW+7H52BbiJlfsbkyttS2spOOd4EwfVk9G2Kn3+N/IueDe8gCEu jQ9uF4lTi2zmok92nt0Y3RT1rEqx6fymCccUUalQQ7w20966hWcIXlxlpdutTIdxL5BjvtSmnH3f 931mv8LxHLalP5qiaWj2oE2HPDGoVzUkUu6h/LL7BuMeYO9CyXtqSFsFJszUlQAAAAAAAA== --Apple-Mail-189--13469464-- From ben@estacado.net Mon Oct 3 11:33:00 2011 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 3FA6B21F8C5D for ; Mon, 3 Oct 2011 11:33:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xptspf1MmFXJ for ; Mon, 3 Oct 2011 11:32:59 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A09321F8B94 for ; Mon, 3 Oct 2011 11:32:55 -0700 (PDT) Received: from dn3-53.estacado.net (dn3-53.estacado.net [172.16.3.53]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p93IZq82020341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2011 13:35:55 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> Date: Mon, 3 Oct 2011 13:35:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-cema-02 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, 03 Oct 2011 18:33:00 -0000 Hi everyone, This WGLC is closed. Thanks to all that sent feedback. I see from a = separate email that Christer will submit a new version soon. Thanks! Ben. On Sep 14, 2011, at 4:22 PM, Ben Campbell wrote: > This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >=20 > The WGLC will conclude on 29 September 2011. Please send your = comments, including nits and "this is ready to go" type comments, to the = authors and the working group mail list. >=20 > Thanks! >=20 > Ben. >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Tue Oct 4 02:19:51 2011 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 9B74E21F8D08 for ; Tue, 4 Oct 2011 02:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oee-QYD4fOb for ; Tue, 4 Oct 2011 02:19:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 786F721F8C87 for ; Tue, 4 Oct 2011 02:19:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-86-4e8ad06e3ccb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.115.87]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 10.9B.20773.E60DA8E4; Tue, 4 Oct 2011 11:22:54 +0200 (CEST) Received: from [159.107.51.35] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Tue, 4 Oct 2011 11:22:29 +0200 Message-ID: <4E8AD054.4050407@ericsson.com> Date: Tue, 4 Oct 2011 11:22:28 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E889797.9010204@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Staffan Blau , Simple WG Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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 Oct 2011 09:19:51 -0000 Hi Christer: I am removing these comments for which there is agreement. On 02/10/2011 22:23, Christer Holmberg wrote: > > Hi, > > I have removed the MMUSIC list from this reply, and added the SIMPLE list, as there should be no issues with the SDP attribute related comments. > > >> Here are some comments related to the new "msrp-cema" >> attribute defined in draft-ietf-simple-msrp-cema-02.txt >> > > >> - Section 4.2, 1st bullet point of the SDP answer (and in >> other parts of >> 4.2 and 4.3), the text says: "... does not match the >> information ...". I have a problem with the word "match". >> Most likely, "match" implies "equality". So we are talking of >> the equality of the c/m lines with a URI. These two can never >> be equal. In particular, a URI can eve be a domain name or >> host name, in which case, will never be equal to an IP >> address and a port number. Most likely you want to say >> "resolve", but I am not sure. > > The text talks about matching of "address information", so I don't think that is the same as matching the whole c/m line with the URI. > > But, I can add a note, saying that if the URI contains a domain name, it needs to be resolved into an IP address before the matching is done. Just bear in mind that matching URIs is not a simple task. You have to consider things like the presence or absence of a default port number, several IP addresses that resolve to the same name, and be able to answer questions such as if two IP addresses are different, although the same name resolves to those IP addresses, are the URIs equivalent?. I think you should take a look at RFC 3986 and 3987. Both have sections on equivalence. But at a first glance, an IP address and a port number cannot be consider to a URI that contains a host name. I think you need to further investigate this issue and have very clear understand on what is required for CEMA. > >> - Section 5.4. The text says: "Middleboxes >> cannot be deployed in environments that require end-to-end SDP >> protection using SIP identity [RFC4916]." >> >> I am trying to see the connection between "end-to-end SDP >> protection" and "SIP identity". I would have removed one of >> them from the text, depending on what you want to say. >> Perhaps you want to say that the CEMA extension does not work >> if "end-to-end integrity protection of SDP is used". > > > Others have also commented on the text. I suggest to modify the text in the following way: > > "This document assumes that Middleboxes are able to modify the SDP > address information associated with the MSRP media. Middleboxes > cannot be deployed in environments that require end-to-end SDP > protection using SIP identity [RFC4916]." I don't understand how this solves my comment. I had a comment to the last line of the paragraph, and it is unmodified in your proposal. > > > ---------------- > > > >> - Section 7.1, "Purpose". I will not speak of the "sending >> UA" in an SDP registry, but of the "SDP creator". > > I suggest modifying to "creator of the SDP". > > > "8.1. IANA Registration of the SDP 'msrp-cema' attribute > > This document instructs IANA to add a attribute to the 'att-field > (media level only)' registry of the SDP parameters registry, > according to the information provided in this section. > > This section registers a new SDP attribute, 'msrp-cema'. The > required information for this registration, as specified in RFC 4566, > is: > > Contact name: Christer Holmberg > > Contact e-mail: christer.holmberg@ericsson.com > > Attribute name: a=msrp-cema Since you are copying the text, remember that I already commented generally to the draft that the name of the attribute does not include the "a=", therefore, you should write: Attribute name: msrp-cema > > Type of attribute: media level > > Purpose: This attribute is used to indicate support of > the MSRP Connection Establishment for Media > Anchoring (CEMA) extension defined in > RFC XXXX. When present in an MSRP media > description of an SDP body, it indicates > that the creator of the SDP supports the CEMA > mechanism. > > Values: The attribute does not carry a value > > Charset dependency: none" > > > > > ---------------- > > > Regards, > > Christer > BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Tue Oct 4 04:55:27 2011 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 58B5221F8C3C for ; Tue, 4 Oct 2011 04:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggF3L8MFtWP5 for ; Tue, 4 Oct 2011 04:55:26 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2C10521F8C37 for ; Tue, 4 Oct 2011 04:55:26 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3f-4e8af4d95121 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.11.20773.9D4FA8E4; Tue, 4 Oct 2011 13:58:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 4 Oct 2011 13:58:12 +0200 From: Christer Holmberg To: Miguel Garcia A Date: Tue, 4 Oct 2011 13:58:10 +0200 Thread-Topic: SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments Thread-Index: AcyCdyPGRP+vYVeZQ5G6SbylYblfuwACkDZQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234094EEF@ESESSCMS0356.eemea.ericsson.se> References: <4E889797.9010204@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> <4E8AD054.4050407@ericsson.com> In-Reply-To: <4E8AD054.4050407@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Staffan Blau , Simple WG Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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 Oct 2011 11:55:27 -0000 Hi,=20 >>> - Section 4.2, 1st bullet point of the SDP answer (and in=20 >>> other parts of 4.2 and 4.3), the text says: "... does not match the inf= ormation=20 >>> ...". I have a problem with the word "match". >>> Most likely, "match" implies "equality". So we are talking of the=20 >>> equality of the c/m lines with a URI. These two can never=20 >>> be equal. In particular, a URI can eve be a domain name or host=20 >>> name, in which case, will never be equal to an IP address and a port nu= mber. Most=20 >>> likely you want to say "resolve", but I am not sure. >> >> The text talks about matching of "address information", so=20 >> I don't think that is the same as matching the whole c/m line=20 >> with the URI. >> >> But, I can add a note, saying that if the URI contains a=20 >> domain name, it needs to be resolved into an IP address=20 >> before the matching is done. >=20 > Just bear in mind that matching URIs is not a simple task.=20 > You have to consider things like the presence or absence of a=20 > default port number, several IP addresses that resolve to the=20 > same name, and be able to answer questions such as if two IP=20 > addresses are different, although the same name resolves to=20 > those IP addresses, are the URIs equivalent?. >=20 > I think you should take a look at RFC 3986 and 3987. Both=20 > have sections on equivalence. But at a first glance, an IP=20 > address and a port number cannot be consider to a URI that=20 > contains a host name. I think you need to further investigate=20 > this issue and have very clear understand on what is required=20 > for CEMA. I suggest the following text: "X. Address Information Matching When comparing address information in the SDP c/m-line and an MSRP URI, f= or address and port=20 equivalence, the address and port values are retrieved in the following w= ays: - The IP address is retrieved from the SDP c- line, and the port from the= associated SDP=20 m- line for MSRP. - In case the authority part of the MSRP URI contains an IP address and a= port, they are=20 used for the comparison. NOTE: According to section 6 of RFC 4975, if the authority part of the MS= RP URI contains an IP address, it must also contain a port. - In case the authority part of the MSRP URI contains a Fully Qualified D= omain Name (FQDN)=20 and a port, the IP address is retrived using DNS, according to the proced= ures in section 6.2=20 of RFC 4975. The port is retrieved from the authority part of the MSRP UR= I. - In case the authority part of the MSRP URI contains a Fully Qualified D= omain Name (FQDN),=20 but does not contain a port, the IP address and port are retrived using D= NS. NOTE: In case the DNS returns multiple records, each needs to be compared= against the SDP c/m-=20 line address information. If the authority part of the MSRP URI contains special characters, they a= re handled according=20 to the procedures in RFC 4975." MSRP does not define a default port number value - the IANA registered port= value only indicates which port should be used. So, one can assume that th= ere will always be an explicit port (that port may be received from the DNS= server, though). ---------------- >>> - Section 5.4. The text says: "Middleboxes >>> cannot be deployed in environments that require end-to-end SDP >>> protection using SIP identity [RFC4916]." >>> >>> I am trying to see the connection between "end-to-end SDP=20 >>> protection" and "SIP identity". I would have removed one of them from=20 >>> the text, depending on what you want to say. >>> Perhaps you want to say that the CEMA extension does not work if=20 >>> "end-to-end integrity protection of SDP is used". >> >> >> Others have also commented on the text. I suggest to modify=20 >> the text in the following way: >> >> "This document assumes that Middleboxes are able to modify the SDP >> address information associated with the MSRP media. Middleboxes >> cannot be deployed in environments that require end-to-end SDP >> protection using SIP identity [RFC4916]." >=20 >I don't understand how this solves my comment. I had a=20 >comment to the last line of the paragraph, and it is=20 >unmodified in your proposal. Ok, now I see. You CAN use the CEMA extension as such even when end-to-end integrity prote= ction of SDP is used. I could add the following note: "NOTE: Eventhough the CEMA extension as such works with end-to-end SDP pro= tection, the main advantage of the extension is in networks where Middlebox= es are deployed." ---------------- >>> - Section 7.1, "Purpose". I will not speak of the "sending >>> UA" in an SDP registry, but of the "SDP creator". >> >> I suggest modifying to "creator of the SDP". >> >> >> "8.1. IANA Registration of the SDP 'msrp-cema' attribute >> >> This document instructs IANA to add a attribute to the 'att-field >> (media level only)' registry of the SDP parameters registry, >> according to the information provided in this section. >> >> This section registers a new SDP attribute, 'msrp-cema'. The >> required information for this registration, as specified in RFC 4566= , >> is: >> >> Contact name: Christer Holmberg >> >> Contact e-mail: christer.holmberg@ericsson.com >> >> Attribute name: a=3Dmsrp-cema >=20 >=20 > Since you are copying the text, remember that I already commented=20 > generally to the draft that the name of the attribute does=20 > not include=20 > the "a=3D", therefore, you should write: >=20 > Attribute name: msrp-cema Correct. ---------------- In addition, based on an off-line comment you gave me, I suggest to add the= following text to the Conventions section: "This document reuses the terms answer, answerer, offer and offerer as def= ined in RFC 3264 [RFC3264]." Related to that, in the text I will replace "MSRP offerer/answerer" with "o= fferer/answerer". ---------------- Regards, Christer From prasun.bheri@gmail.com Tue Oct 4 23:37:48 2011 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 232B621F87C5 for ; Tue, 4 Oct 2011 23:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.238 X-Spam-Level: X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8v8VQQgGWbb for ; Tue, 4 Oct 2011 23:37:47 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1021F8726 for ; Tue, 4 Oct 2011 23:37:47 -0700 (PDT) Received: by yxt33 with SMTP id 33so1538027yxt.31 for ; Tue, 04 Oct 2011 23:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=sIW8Q6IZdzTNA9vaFN0nIR34vc9vf7RqoLWgmqw76Cs=; b=dSqp74RFPpBsOhLNaOWaAzrZ28sgsUvlIa+jWyewvAlId/gPRbGNOBwvxjSq9kKjnm V2jycdvBU3vtAnu9GfH7CZqmCHaPCAbwQex6YW65TykFoZyH4uiYfKswqIao6rxtG3v7 FXfxZMkmvc9C5DARHio9tLfoAwYwOHSOTVrI8= Received: by 10.236.173.131 with SMTP id v3mr11446823yhl.112.1317796852092; Tue, 04 Oct 2011 23:40:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.184.2 with HTTP; Tue, 4 Oct 2011 23:40:12 -0700 (PDT) From: prasun bheri Date: Wed, 5 Oct 2011 12:10:12 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=20cf305639eb414e4004ae877de7 Subject: [Simple] question regarding IP and port negotiation with sdp 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 Oct 2011 06:37:48 -0000 --20cf305639eb414e4004ae877de7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello group, I have a question regarding IP and port negotiation with sdp Lets say A and B are two MSRP nodes (End points) with a file transfer going on between them. If A wants to initiate one more file transfer to B=85 Which port should A has to use in the following scenarios? Case 1: A keeps the same port that its using for First file transfer in the SDP, an= d B returns the same IP and port number in response to SDP. Hence both will use the same connection for second file transfer too. Case 2: A keeps the same port that its using for First file transfer in the SDP, an= d B returns a different IP and/port number in response to SDP. then i. A has to use the same port and a different connectio= n (create a TCP socket, bind to the same port and then connect) What are the implications in this case ? ii. A has to different port and a different connection Then the port in a=3Dpath attribute has no meaning? Will remote end accepts the connection as ports are different in initial SD= P and actual connection request. --20cf305639eb414e4004ae877de7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello group,


I have a question regarding IP and port negotiation with= sdp

=A0

Lets say A and B are two MSRP nodes (End points) with a = file transfer going on between them.

=A0

If A wants to initiate one more file transfer to B=85

=A0

Which port should A has to use in the following scenario= s?

=A0

Case 1:

=A0

A keeps the same port that its using for First file tran= sfer in the SDP, and B returns the same IP and port number in response to SDP.

Hence both will use the same connection for second file transfer too.

=A0

Case 2:

=A0

A keeps the same port that its using for First file tran= sfer in the SDP, and B returns a different IP and/port number in response to SDP= .

=A0

then

=A0

i.=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A has to use the same port and a different connection (create a TCP socket, bind to the same port and then connect)

What are the imp= lications in this case ?

=A0

ii.=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A has to different port and a different connection

Then the port in= a=3Dpath attribute has no meaning?

Will remote end = accepts the connection as ports are different in initial SDP and actual connection request.=

--20cf305639eb414e4004ae877de7-- From miguel.a.garcia@ericsson.com Wed Oct 5 01:00:25 2011 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 D5A1A21F8B42 for ; Wed, 5 Oct 2011 01:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOiuYUW-Et24 for ; Wed, 5 Oct 2011 01:00:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 76B2A21F8B3E for ; Wed, 5 Oct 2011 01:00:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e8c0f537cc5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.115.87]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 34.27.20773.35F0C8E4; Wed, 5 Oct 2011 10:03:31 +0200 (CEST) Received: from [159.107.24.252] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Wed, 5 Oct 2011 10:03:04 +0200 Message-ID: <4E8C0F36.9000600@ericsson.com> Date: Wed, 5 Oct 2011 10:03:02 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E889797.9010204@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> <4E8AD054.4050407@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094EEF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234094EEF@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Staffan Blau , Simple WG Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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 Oct 2011 08:00:25 -0000 Hi Christer, This is looking better, but there are some missing cases. See below. On 04/10/2011 13:58, Christer Holmberg wrote: > > Hi, > >>>> - Section 4.2, 1st bullet point of the SDP answer (and in >>>> other parts of 4.2 and 4.3), the text says: "... does not match the information >>>> ...". I have a problem with the word "match". >>>> Most likely, "match" implies "equality". So we are talking of the >>>> equality of the c/m lines with a URI. These two can never >>>> be equal. In particular, a URI can eve be a domain name or host >>>> name, in which case, will never be equal to an IP address and a port number. Most >>>> likely you want to say "resolve", but I am not sure. >>> >>> The text talks about matching of "address information", so >>> I don't think that is the same as matching the whole c/m line >>> with the URI. >>> >>> But, I can add a note, saying that if the URI contains a >>> domain name, it needs to be resolved into an IP address >>> before the matching is done. >> >> Just bear in mind that matching URIs is not a simple task. >> You have to consider things like the presence or absence of a >> default port number, several IP addresses that resolve to the >> same name, and be able to answer questions such as if two IP >> addresses are different, although the same name resolves to >> those IP addresses, are the URIs equivalent?. >> >> I think you should take a look at RFC 3986 and 3987. Both >> have sections on equivalence. But at a first glance, an IP >> address and a port number cannot be consider to a URI that >> contains a host name. I think you need to further investigate >> this issue and have very clear understand on what is required >> for CEMA. > > I suggest the following text: > > > "X. Address Information Matching > > When comparing address information in the SDP c/m-line and an MSRP URI, for address and port > equivalence, the address and port values are retrieved in the following ways: > > - The IP address is retrieved from the SDP c- line, and the port from the associated SDP > m- line for MSRP. It appears that the text is assuming an IP address in the c= line, but you could also have an FQDN in there. Also, if you have an IPv6 address, you should normalize it as well. > > - In case the authority part of the MSRP URI contains an IP address and a port, they are > used for the comparison. > > NOTE: According to section 6 of RFC 4975, if the authority part of the MSRP URI contains > an IP address, it must also contain a port. > > - In case the authority part of the MSRP URI contains a Fully Qualified Domain Name (FQDN) > and a port, the IP address is retrived using DNS, according to the procedures in section 6.2 > of RFC 4975. The port is retrieved from the authority part of the MSRP URI. > s/retrived/retrieved > - In case the authority part of the MSRP URI contains a Fully Qualified Domain Name (FQDN), > but does not contain a port, the IP address and port are retrived using DNS. > I think this case does not exist. According to RFC 4975 a port number is always explicitly expected in an MSRP URI. Perhaps you can modify the note above to say that an explicit port number is always used in MSRP URIs. > NOTE: In case the DNS returns multiple records, each needs to be compared against the SDP c/m- > line address information. > > If the authority part of the MSRP URI contains special characters, they are handled according > to the procedures in RFC 4975." > > > MSRP does not define a default port number value - the IANA registered port value only indicates which port should be used. So, one can assume that there will always be an explicit port (that port may be received from the DNS server, though). > > ---------------- > > >>>> - Section 5.4. The text says: "Middleboxes >>>> cannot be deployed in environments that require end-to-end SDP >>>> protection using SIP identity [RFC4916]." >>>> >>>> I am trying to see the connection between "end-to-end SDP >>>> protection" and "SIP identity". I would have removed one of them from >>>> the text, depending on what you want to say. >>>> Perhaps you want to say that the CEMA extension does not work if >>>> "end-to-end integrity protection of SDP is used". >>> >>> >>> Others have also commented on the text. I suggest to modify >>> the text in the following way: >>> >>> "This document assumes that Middleboxes are able to modify the SDP >>> address information associated with the MSRP media. Middleboxes >>> cannot be deployed in environments that require end-to-end SDP >>> protection using SIP identity [RFC4916]." >> >> I don't understand how this solves my comment. I had a >> comment to the last line of the paragraph, and it is >> unmodified in your proposal. > > Ok, now I see. > > You CAN use the CEMA extension as such even when end-to-end integrity protection of SDP is used. > > I could add the following note: > > "NOTE: Eventhough the CEMA extension as such works with end-to-end SDP protection, the main advantage of the extension is in networks where Middleboxes are deployed." I am not sure if I am missing something... but isn't it so that CEMA will not work with middle boxes if SDP integrity protection or encryption is activated? So, the draft should just simply say it so. I think we don't have to bring SIP identity to the equation. I proposed the following paragraph: "This document assumes that Middleboxes are able to modify the SDP address information associated with the MSRP media. Middleboxes cannot be deployed in environments that require end-to-end SDP integrity protection or SDP encryption." > > > > Regards, > > Christer BR, Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christer.holmberg@ericsson.com Wed Oct 5 04:04:21 2011 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 61F7321F8C4A for ; Wed, 5 Oct 2011 04:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7+Xg6qmY7jr for ; Wed, 5 Oct 2011 04:04:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 431EF21F8C4C for ; Wed, 5 Oct 2011 04:04:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-31-4e8c3a6f310f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D5.46.20773.F6A3C8E4; Wed, 5 Oct 2011 13:07:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 5 Oct 2011 13:06:59 +0200 From: Christer Holmberg To: Miguel Garcia A Date: Wed, 5 Oct 2011 13:06:57 +0200 Thread-Topic: SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments Thread-Index: AcyDNTV+x/3+DH0lTUO4cN7JLbMoFgAASLgA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522340DBD14@ESESSCMS0356.eemea.ericsson.se> References: <4E889797.9010204@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094420@ESESSCMS0356.eemea.ericsson.se> <4E8AD054.4050407@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A05852234094EEF@ESESSCMS0356.eemea.ericsson.se> <4E8C0F36.9000600@ericsson.com> In-Reply-To: <4E8C0F36.9000600@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Staffan Blau , Simple WG Subject: Re: [Simple] SDP comments to draft-ietf-simple-msrp-cema-02.txt - Miguel's comments 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 Oct 2011 11:04:21 -0000 Hi,=20 >> I suggest the following text: >> >> >> "X. Address Information Matching >> >> When comparing address information in the SDP=20 >> c/m-line and an MSRP URI, for address and port >> equivalence, the address and port values are=20 >> retrieved in the following ways: >> >> - The IP address is retrieved from the SDP c- line, and the port from = the associated SDP >> m- line for MSRP. >=20 >=20 >It appears that the text is assuming an IP address in the c=3D=20 >line, but you could also have an FQDN in there. Correct. So, I will add a similar bullet as for the case when an MSRP URI c= ontains a FQDN. "- In case the SDP c- line contains a Fully Qualified Domain Name (FQDN),= the IP address is retrieved using DNS." ---------------- >Also, if you have an IPv6 address, you should normalize it as well. I suggest the following note. =20 "NOTE: Before IPv6 addresses are compared for equality, they need to be c= onverted into the same representation, e.g.=20 using the mechanism defined in RFC 5952 [RFC5952]." ---------------- >> - In case the authority part of the MSRP URI=20 >> contains an IP address and a port, they are >> used for the comparison. >> >> NOTE: According to section 6 of RFC 4975, if=20 >> the authority part of the MSRP URI contains >> an IP address, it must also contain a port. >> >> - In case the authority part of the MSRP URI=20 >> contains a Fully Qualified Domain Name (FQDN) >> and a port, the IP address is retrived using=20 >> DNS, according to the procedures in section 6.2 >> of RFC 4975. The port is retrieved from the=20 >> authority part of the MSRP URI. >> >=20 > s/retrived/retrieved Fixed. ---------------- =20 >> - In case the authority part of the MSRP URI=20 >> contains a Fully Qualified Domain Name (FQDN), >> but does not contain a port, the IP address and=20 >> port are retrived using DNS. >> >=20 > I think this case does not exist. According to RFC 4975 a=20 > port number is always explicitly expected in an MSRP URI. Correct. I'll remove the bullet. > Perhaps you can modify the note above to say that an explicit=20 > port number is always used in MSRP URIs. Yes. "NOTE: According to RFC 4975, the authority part of the=20 MSRP URI must always contain a port." So, based on your comments, and with some re-structuring, the new section w= ould look like: "4.4. Address Information Matching When comparing address information in the SDP c/m-line and an MSRP URI, for address and port equivalence, the address and port values are retrieved in the following ways: - SDP c/m-line address information: The IP address is retrieved from the SDP c- line, and the port from the associated SDP m- line for MSRP. - In case the SDP c- line contains a Fully Qualified Domain Name (FQDN), the IP address is retrieved using DNS. - MSRP URI address information: The IP address and port are retrieved from the authority part of the MSRP URI. - In case the authority part of the MSRP URI contains a Fully Qualified Domain Name (FQDN), the IP address is retrieved using DNS, according to the procedures in section 6.2 of RFC 4975. NOTE: According to RFC 4975, the authority part of the MSRP URI must always contain a port. NOTE: Before IPv6 addresses are compared for equivalence, they need to be converted into the same representation, e.g. using the mechanism defined in RFC 5952 [RFC5952]. NOTE: In case the DNS returns multiple records, each needs to be compared against the SDP c/m- line address information. NOTE: If the authority part of the MSRP URI contains special characters, they are handled according to the procedures in section 6.1 of RFC 4975." ---------------- > I am not sure if I am missing something... but isn't it so=20 > that CEMA will not work with middle boxes if SDP integrity=20 > protection or encryption is activated? So, the draft should=20 > just simply say it so. I think we don't have to bring SIP=20 > identity to the equation. I proposed the following > paragraph: >=20 > "This document assumes that Middleboxes are able to modify=20 > the SDP address information associated with the MSRP media. =20 > Middleboxes cannot be deployed in environments that require=20 > end-to-end SDP integrity protection or SDP encryption." I am ok with that text (it basically removes the SIP identity part). ---------------- Regards, Christer From internet-drafts@ietf.org Wed Oct 5 04:08:09 2011 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 5223521F8AEE; Wed, 5 Oct 2011 04:08:09 -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.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACom32Iz5MBD; Wed, 5 Oct 2011 04:08:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3921F899F; Wed, 5 Oct 2011 04:08:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111005110808.9075.38565.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 04:08:08 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-03.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: Wed, 05 Oct 2011 11:08:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-03.txt Pages : 19 Date : 2011-10-05 This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-03.txt From christer.holmberg@ericsson.com Wed Oct 5 04:11:31 2011 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 A967F21F8C89 for ; Wed, 5 Oct 2011 04:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GgX93mkH+oyS for ; Wed, 5 Oct 2011 04:11:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D0EA321F8C87 for ; Wed, 5 Oct 2011 04:11:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1b-4e8c3c1d47ed Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 89.C8.20773.D1C3C8E4; Wed, 5 Oct 2011 13:14:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 5 Oct 2011 13:14:17 +0200 From: Christer Holmberg To: Simple WG Date: Wed, 5 Oct 2011 13:14:15 +0200 Thread-Topic: Draft new version: draft-ietf-simple-msrp-cema-03 Thread-Index: AcyDT+spyvwMGFbVRFi3qsRWkK1K6w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522340DBD27@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058522340DBD27ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new version: draft-ietf-simple-msrp-cema-03 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 Oct 2011 11:11:31 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058522340DBD27ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the WGLC comments, I have submitted a new version (-03) of CEMA. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058522340DBD27ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the WGLC comments, I have submitted a new ve= rsion (-03) of CEMA.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058522340DBD27ESESSCMS0356e_-- From ben@estacado.net Wed Oct 5 14:10:23 2011 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 C44B921F8C36 for ; Wed, 5 Oct 2011 14:10: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKtAL2DSEldN for ; Wed, 5 Oct 2011 14:10:23 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2C21F8C33 for ; Wed, 5 Oct 2011 14:10:22 -0700 (PDT) Received: from dn3-53.estacado.net (dn3-53.estacado.net [172.16.3.53]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p95LDTpG032213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Oct 2011 16:13:30 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> Date: Wed, 5 Oct 2011 16:13:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> To: Ben Campbell X-Mailer: Apple Mail (2.1244.3) Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: [Simple] Update of CEMA draft 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 Oct 2011 21:10:23 -0000 Hi Everyone, Christer submitted an update of the CEMA draft, based on the last call = feedback. If you offered substantive comments during the WGLC, please = take a quick look at the new version and confirm whether your comments = have been addressed. The draft is available at = http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-03 A diff from the previous version is available at = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-simple= -msrp-cema-03.txt Thanks! Ben. On Oct 3, 2011, at 1:35 PM, Ben Campbell wrote: > Hi everyone, >=20 > This WGLC is closed. Thanks to all that sent feedback. I see from a = separate email that Christer will submit a new version soon. >=20 > Thanks! >=20 > Ben. >=20 > On Sep 14, 2011, at 4:22 PM, Ben Campbell wrote: >=20 >> This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >>=20 >> http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >>=20 >> The WGLC will conclude on 29 September 2011. Please send your = comments, including nits and "this is ready to go" type comments, to the = authors and the working group mail list. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >> _______________________________________________ >> 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 From miguel.a.garcia@ericsson.com Thu Oct 6 00:45:20 2011 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 BBEAA21F8C56 for ; Thu, 6 Oct 2011 00:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhYIXpgk27GS for ; Thu, 6 Oct 2011 00:45:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EC45021F8CCC for ; Thu, 6 Oct 2011 00:45:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b1-4e8d5d4ce26f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F2.F7.20773.C4D5D8E4; Thu, 6 Oct 2011 09:48:28 +0200 (CEST) Received: from [159.107.24.234] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 09:48:16 +0200 Message-ID: <4E8D5D3F.6090202@ericsson.com> Date: Thu, 6 Oct 2011 09:48:15 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ben Campbell References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> In-Reply-To: <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Update of CEMA draft 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 Oct 2011 07:45:20 -0000 My comments are addressed, I am satisfied with this version of the draft. /Miguel On 05/10/2011 23:13, Ben Campbell wrote: > Hi Everyone, > > Christer submitted an update of the CEMA draft, based on the last call feedback. If you offered substantive comments during the WGLC, please take a quick look at the new version and confirm whether your comments have been addressed. > > The draft is available at http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-03 > > A diff from the previous version is available at http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-simple-msrp-cema-03.txt > > Thanks! > > Ben. > > > > On Oct 3, 2011, at 1:35 PM, Ben Campbell wrote: > >> Hi everyone, >> >> This WGLC is closed. Thanks to all that sent feedback. I see from a separate email that Christer will submit a new version soon. >> >> Thanks! >> >> Ben. >> >> On Sep 14, 2011, at 4:22 PM, Ben Campbell wrote: >> >>> This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >>> >>> http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >>> >>> The WGLC will conclude on 29 September 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group mail list. >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> _______________________________________________ >>> 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 > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From nancy.greene@ericsson.com Thu Oct 6 10:18:14 2011 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 43BBD21F8BCB for ; Thu, 6 Oct 2011 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSb48pqKBeIr for ; Thu, 6 Oct 2011 10:18:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B521F8BAE for ; Thu, 6 Oct 2011 10:18:13 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p96HKZBw003743; Thu, 6 Oct 2011 12:20:37 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 6 Oct 2011 13:20:34 -0400 From: Nancy Greene To: Ben Campbell Date: Thu, 6 Oct 2011 13:20:33 -0400 Thread-Topic: [Simple] Update of CEMA draft Thread-Index: AcyDo67r1HbO1A84RlWhma5RysIg2wAqH9jg Message-ID: References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> In-Reply-To: <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-simple-msrp-cema.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] Update of CEMA draft 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 Oct 2011 17:18:14 -0000 Hi, My comments have been addressed. This version is fine. Nancy=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: October-05-11 5:13 PM To: Ben Campbell Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org; Simple WG Subject: [Simple] Update of CEMA draft Hi Everyone, Christer submitted an update of the CEMA draft, based on the last call feed= back. If you offered substantive comments during the WGLC, please take a qu= ick look at the new version and confirm whether your comments have been add= ressed. The draft is available at http://tools.ietf.org/html/draft-ietf-simple-msrp= -cema-03 A diff from the previous version is available at http://tools.ietf.org/rfcd= iff?difftype=3D--hwdiff&url2=3Ddraft-ietf-simple-msrp-cema-03.txt Thanks! Ben. On Oct 3, 2011, at 1:35 PM, Ben Campbell wrote: > Hi everyone, >=20 > This WGLC is closed. Thanks to all that sent feedback. I see from a separ= ate email that Christer will submit a new version soon. >=20 > Thanks! >=20 > Ben. >=20 > On Sep 14, 2011, at 4:22 PM, Ben Campbell wrote: >=20 >> This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >>=20 >> http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >>=20 >> The WGLC will conclude on 29 September 2011. Please send your comments, = including nits and "this is ready to go" type comments, to the authors and = the working group mail list. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >> _______________________________________________ >> 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From miguel.a.garcia@ericsson.com Thu Oct 6 12:57:00 2011 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 2788E21F87C9 for ; Thu, 6 Oct 2011 12:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mi1fGLo30b0p for ; Thu, 6 Oct 2011 12:56:59 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 98DF421F8C4A for ; Thu, 6 Oct 2011 12:56:57 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-81-4e8e08c54f68 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 52.84.20773.5C80E8E4; Thu, 6 Oct 2011 22:00:05 +0200 (CEST) Received: from [159.107.48.251] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 6 Oct 2011 21:59:17 +0200 Message-ID: <4E8E0894.9030203@ericsson.com> Date: Thu, 6 Oct 2011 21:59:16 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.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: AAAAAA== Cc: Geir Arne Sandbakken , "aki.niemi@nokia.com" Subject: [Simple] SDP comments to MSRP chat 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 Oct 2011 19:57:00 -0000 Hi, the MSRP chat was reviewed in MMUSIC, and we got two main comments: 1) extensibility of the 'chatroom' attribute in SDP. Do we need an IANA registry 2) Privacy concerns of this attribute. The review is here: http://www.ietf.org/mail-archive/web/mmusic/current/msg08940.html For issue 1, I think that we don't need an IANA registry at this point, in particular because we are not expecting extensions to this attribute. My proposal is to simply indicate that organizations that want to extend this attribute and create new tokens should use their reversed names to avoid clashes among then. For issue 2, I will think a bit what we need to say and I will post it in a separate mail once I have the text. I am willing to receive suggestions. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From ben@nostrum.com Thu Oct 6 15:54:22 2011 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 A798021F8D31 for ; Thu, 6 Oct 2011 15:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykz6n-Zbjv7I for ; Thu, 6 Oct 2011 15:54:22 -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 0C35221F8D30 for ; Thu, 6 Oct 2011 15:54:21 -0700 (PDT) Received: from [10.0.1.19] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p96MvTwl044653 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Oct 2011 17:57:29 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4E8E0894.9030203@ericsson.com> Date: Thu, 6 Oct 2011 17:57:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> References: <4E8E0894.9030203@ericsson.com> To: "Miguel A. Garcia" , Simple WG , Geir Arne Sandbakken X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "aki.niemi@nokia.com Niemi" Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 22:54:22 -0000 On Oct 6, 2011, at 2:59 PM, Miguel A. Garcia wrote: > Hi, >=20 > the MSRP chat was reviewed in MMUSIC, and we got two main comments: >=20 > 1) extensibility of the 'chatroom' attribute in SDP. Do we need an = IANA registry >=20 > 2) Privacy concerns of this attribute. >=20 > The review is here: > http://www.ietf.org/mail-archive/web/mmusic/current/msg08940.html >=20 >=20 > For issue 1, I think that we don't need an IANA registry at this = point, in particular because we are not expecting extensions to this = attribute. My proposal is to simply indicate that organizations that = want to extend this attribute and create new tokens should use their = reversed names to avoid clashes among then. Out of curiosity, if we don't expect extensions, do we need the = extension point int he ABNF? If an organization creates more than one extension token, is it up to = that organization to coordinate them? >=20 > For issue 2, I will think a bit what we need to say and I will post it = in a separate mail once I have the text. I am willing to receive = suggestions. >=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 Thu Oct 6 15:55:28 2011 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 7C5A421F8D4B for ; Thu, 6 Oct 2011 15:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXdWprw+QJCP for ; Thu, 6 Oct 2011 15:55:27 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 25A6321F8D4C for ; Thu, 6 Oct 2011 15:55:23 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta09.westchester.pa.mail.comcast.net with comcast id hawP1h0040EZKEL59ayc65; Thu, 06 Oct 2011 22:58:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta01.westchester.pa.mail.comcast.net with comcast id hayb1h00E0tdiYw3MaybM0; Thu, 06 Oct 2011 22:58:36 +0000 Message-ID: <4E8E3299.6030407@alum.mit.edu> Date: Thu, 06 Oct 2011 18:58:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Simple WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] draft-ietf-simple-chat-10 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 Oct 2011 22:55:28 -0000 Somehow I missed the WGLC of draft-ietf-simple-chat-10 until I came across the post-WGLC review request sent to MMUSIC. As I was looking through it I came across a possible issue that isn't related to SDP usage. Maybe its too late to do anything about it, and maybe nothing needs to be done about it, but I'll mention it anyway: Section 7, in multiple places, requires that nicknames be unambiguous. The most specific is: The reservation of a nickname can fail, e.g. if the NICKNAME request contains a malformed or non-existent Use-Nickname header field, or if the same nickname has already been reserved by another participant in the conference. Elsewhere in the document the possibility is raised that the same user may connect to the chat from multiple devices, and that private messages addressed to the user would then be delivered to all those devices. So, in such a case, can each of the devices request the same nickname? Or must they each request a distinct nickname? It seems like it would be desirable to permit them all to use the same nickname. Its unclear to me whether the draft intends to permit this. Sorry to be so tardy, Paul From pkyzivat@alum.mit.edu Thu Oct 6 16:22:28 2011 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 BCE5B1F0C45 for ; Thu, 6 Oct 2011 16:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmrTarXc0WmI for ; Thu, 6 Oct 2011 16:22:28 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 28CF61F0C51 for ; Thu, 6 Oct 2011 16:22:27 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta09.westchester.pa.mail.comcast.net with comcast id hTtG1h0071uE5Es59bRdbi; Thu, 06 Oct 2011 23:25:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id hbRc1h00F0tdiYw3cbRcdQ; Thu, 06 Oct 2011 23:25:36 +0000 Message-ID: <4E8E38EE.50203@alum.mit.edu> Date: Thu, 06 Oct 2011 19:25:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: simple@ietf.org References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> In-Reply-To: <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 23:22:28 -0000 On 10/6/11 6:57 PM, Ben Campbell wrote: > On Oct 6, 2011, at 2:59 PM, Miguel A. Garcia wrote: > >> Hi, >> >> the MSRP chat was reviewed in MMUSIC, and we got two main comments: >> >> 1) extensibility of the 'chatroom' attribute in SDP. Do we need an IANA registry >> >> 2) Privacy concerns of this attribute. >> >> The review is here: >> http://www.ietf.org/mail-archive/web/mmusic/current/msg08940.html >> >> >> For issue 1, I think that we don't need an IANA registry at this point, in particular because we are not expecting extensions to this attribute. My proposal is to simply indicate that organizations that want to extend this attribute and create new tokens should use their reversed names to avoid clashes among then. > > Out of curiosity, if we don't expect extensions, do we need the extension point int he ABNF? We aren't always as good at predicting the future as we might wish, so I think it is still good to include an extension point. But we don't need to include a registry in that case - we can simply state that a revision to the draft is required to make an extension. > If an organization creates more than one extension token, is it up to that organization to coordinate them? If the intent is to allow private extensions without registration, then the ABNF needs to be modified to specify the syntax for the private names (distinct from any future standardized values), and the usage rules (e.g. reverse FQDN syntax) need to be spelled out. Thanks, Paul From miguel.a.garcia@ericsson.com Thu Oct 6 23:06:20 2011 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 053D221F8B77 for ; Thu, 6 Oct 2011 23:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVsBKZ0NOPg0 for ; Thu, 6 Oct 2011 23:06:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 423AA21F8B76 for ; Thu, 6 Oct 2011 23:06:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4e8e979a6844 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.115.87]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 54.CA.20773.A979E8E4; Fri, 7 Oct 2011 08:09:31 +0200 (CEST) Received: from [159.107.48.251] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 08:09:27 +0200 Message-ID: <4E8E9796.1070704@ericsson.com> Date: Fri, 7 Oct 2011 08:09:26 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ben Campbell References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> In-Reply-To: <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: Geir Arne Sandbakken , Simple WG , "aki.niemi@nokia.com Niemi" Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 06:06:20 -0000 On 07/10/2011 0:57, Ben Campbell wrote: >> For issue 1, I think that we don't need an IANA registry at this point, in particular because we are not expecting extensions to this attribute. My proposal is to simply indicate that organizations that want to extend this attribute and create new tokens should use their reversed names to avoid clashes among then. > > Out of curiosity, if we don't expect extensions, do we need the extension point int he ABNF? > It is hard to determine what the future will bring. If we remove the extensibility now, and in the future we want to create an extension, then we will be forced to create a new SDP attribute. If we have the extensibility in place, but not the IANA registry, we can always create the IANA registry at a later point. So, I am leaning towards being conservative, and allow the extensibility of the SDP 'chatroom' attribute, without having an IANA registry at this point. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From christian.1.schmidt@nsn.com Fri Oct 7 00:14:25 2011 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 3794B21F8B47 for ; Fri, 7 Oct 2011 00:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.369 X-Spam-Level: X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=1.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZunD2cneMSlN for ; Fri, 7 Oct 2011 00:14:21 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2C66821F8B48 for ; Fri, 7 Oct 2011 00:14:20 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p977GbSP005712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 09:16:37 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p977GWgm026063; Fri, 7 Oct 2011 09:16:32 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Oct 2011 09:16:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 09:16:31 +0200 Message-ID: In-Reply-To: <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] Update of CEMA draft Thread-Index: AcyDo6fAYHC08Wa4SnqxlOLTFWJ4sABHOiLQ References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com><5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Ben Campbell" X-OriginalArrivalTime: 07 Oct 2011 07:16:32.0838 (UTC) FILETIME=[0A9AE660:01CC84C1] Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: Re: [Simple] Update of CEMA draft 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 Oct 2011 07:14:25 -0000 All my comments have been addressed. This version of the draft looks very good. Christian -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Wednesday, October 05, 2011 11:13 PM To: Ben Campbell Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org; Simple WG Subject: [Simple] Update of CEMA draft Hi Everyone, Christer submitted an update of the CEMA draft, based on the last call feedback. If you offered substantive comments during the WGLC, please take a quick look at the new version and confirm whether your comments have been addressed. The draft is available at http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-03 A diff from the previous version is available at http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-simpl= e-m srp-cema-03.txt Thanks! Ben. On Oct 3, 2011, at 1:35 PM, Ben Campbell wrote: > Hi everyone, >=20 > This WGLC is closed. Thanks to all that sent feedback. I see from a separate email that Christer will submit a new version soon. >=20 > Thanks! >=20 > Ben. >=20 > On Sep 14, 2011, at 4:22 PM, Ben Campbell wrote: >=20 >> This is a Working Group Last Call on draft-ietf-simple-msrp-cema-02: >>=20 >> http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-02 >>=20 >> The WGLC will conclude on 29 September 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group mail list. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >> _______________________________________________ >> 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From saul@ag-projects.com Fri Oct 7 01:39:37 2011 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 D25D221F8B2D for ; Fri, 7 Oct 2011 01:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pHzTMxZ7cGm for ; Fri, 7 Oct 2011 01:39:37 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53CAC21F8B2B for ; Fri, 7 Oct 2011 01:39:36 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 73A8AB01BB; Fri, 7 Oct 2011 10:42:45 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id 8E742B019A; Fri, 7 Oct 2011 10:42:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> Date: Fri, 7 Oct 2011 10:42:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37C3B25F-68AB-47D4-BF12-53A6A45E65F9@ag-projects.com> References: <6B4AD900-C99E-42CD-803E-7289743F8DA0@nostrum.com> <5A1385B3-D869-42F4-A72E-2589528EE22C@estacado.net> <0C62B48B-06D6-47CA-BBC6-0B849038931B@estacado.net> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-simple-msrp-cema.all@tools.ietf.org, Simple WG Subject: Re: [Simple] Update of CEMA draft 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 Oct 2011 08:39:37 -0000 Hi, On Oct 5, 2011, at 11:13 PM, Ben Campbell wrote: > Hi Everyone, >=20 > Christer submitted an update of the CEMA draft, based on the last call = feedback. If you offered substantive comments during the WGLC, please = take a quick look at the new version and confirm whether your comments = have been addressed. >=20 > The draft is available at = http://tools.ietf.org/html/draft-ietf-simple-msrp-cema-03 >=20 > A diff from the previous version is available at = http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-simple= -msrp-cema-03.txt >=20 > Thanks! >=20 It looks very nice, al comments have been addressed. +1 from me. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Fri Oct 7 03:14:47 2011 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 CFCC021F8B9E for ; Fri, 7 Oct 2011 03:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8MAA1vWzGUg for ; Fri, 7 Oct 2011 03:14:47 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4DA21F8B9D for ; Fri, 7 Oct 2011 03:14:42 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4066DB01B7; Fri, 7 Oct 2011 12:17:55 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id CE032B0057; Fri, 7 Oct 2011 12:17:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4E8E9796.1070704@ericsson.com> Date: Fri, 7 Oct 2011 12:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <392588C8-6301-4116-B7CC-9BDEF5FFC482@ag-projects.com> References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> <4E8E9796.1070704@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: "aki.niemi@nokia.com Niemi" , Simple WG , Geir Arne Sandbakken Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 10:14:47 -0000 Hi, On Oct 7, 2011, at 8:09 AM, Miguel A. Garcia wrote: >=20 >=20 > On 07/10/2011 0:57, Ben Campbell wrote: >=20 >>> For issue 1, I think that we don't need an IANA registry at this = point, in particular because we are not expecting extensions to this = attribute. My proposal is to simply indicate that organizations that = want to extend this attribute and create new tokens should use their = reversed names to avoid clashes among then. >>=20 >> Out of curiosity, if we don't expect extensions, do we need the = extension point int he ABNF? >>=20 >=20 > It is hard to determine what the future will bring. If we remove the = extensibility now, and in the future we want to create an extension, = then we will be forced to create a new SDP attribute. If we have the = extensibility in place, but not the IANA registry, we can always create = the IANA registry at a later point. >=20 > So, I am leaning towards being conservative, and allow the = extensibility of the SDP 'chatroom' attribute, without having an IANA = registry at this point. >=20 At some point we did consider extending this attribute to specify that = you may send some custom arbitrary data within a chat stream, for = example, so if a server would add 'x-something' to the 'chatroom' = attribute the client would know that it may send this kind of data. I'd = like to see extensibility for 'chatroom' allowed. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From miguel.a.garcia@ericsson.com Fri Oct 7 03:25:29 2011 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 3FF8521F8ABB for ; Fri, 7 Oct 2011 03:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4anS+Ne2TTYO for ; Fri, 7 Oct 2011 03:25:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D321F8AAA for ; Fri, 7 Oct 2011 03:25:28 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b4-4e8ed458918b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CC.94.20773.854DE8E4; Fri, 7 Oct 2011 12:28:40 +0200 (CEST) Received: from [159.107.48.251] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 7 Oct 2011 12:28:40 +0200 Message-ID: <4E8ED457.7070803@ericsson.com> Date: Fri, 7 Oct 2011 12:28:39 +0200 From: "Miguel A. Garcia" User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Saul Ibarra Corretge References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> <4E8E9796.1070704@ericsson.com> <392588C8-6301-4116-B7CC-9BDEF5FFC482@ag-projects.com> In-Reply-To: <392588C8-6301-4116-B7CC-9BDEF5FFC482@ag-projects.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "aki.niemi@nokia.com Niemi" , Simple WG , Geir Arne Sandbakken Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 10:25:29 -0000 On 07/10/2011 12:17, Saul Ibarra Corretge wrote: > Hi, > > On Oct 7, 2011, at 8:09 AM, Miguel A. Garcia wrote: > >> >> >> On 07/10/2011 0:57, Ben Campbell wrote: >> >>>> For issue 1, I think that we don't need an IANA registry at this point, in particular because we are not expecting extensions to this attribute. My proposal is to simply indicate that organizations that want to extend this attribute and create new tokens should use their reversed names to avoid clashes among then. >>> >>> Out of curiosity, if we don't expect extensions, do we need the extension point int he ABNF? >>> >> >> It is hard to determine what the future will bring. If we remove the extensibility now, and in the future we want to create an extension, then we will be forced to create a new SDP attribute. If we have the extensibility in place, but not the IANA registry, we can always create the IANA registry at a later point. >> >> So, I am leaning towards being conservative, and allow the extensibility of the SDP 'chatroom' attribute, without having an IANA registry at this point. >> > > At some point we did consider extending this attribute to specify that you may send some custom arbitrary data within a chat stream, for example, so if a server would add 'x-something' to the 'chatroom' attribute the client would know that it may send this kind of data. I'd like to see extensibility for 'chatroom' allowed. I agree with the extensibility of the attribute. I believe we can have a policy indicating that if someone wants to extend this attribute for their own purpose, they should prepend the value with the reversed DNS name of the organization, for example: com.example.foo-chat. For the time being, this seems to be enough. /Miguel > > > Regards, > -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain From saul@ag-projects.com Fri Oct 7 03:35:17 2011 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 7C4B521F88B7 for ; Fri, 7 Oct 2011 03:35:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUd7QgD8aycC for ; Fri, 7 Oct 2011 03:35:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D221F8678 for ; Fri, 7 Oct 2011 03:35:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 706A6B01B9; Fri, 7 Oct 2011 12:38:29 +0200 (CEST) Received: from [192.168.1.134] (235.4.222.87.dynamic.jazztel.es [87.222.4.235]) by mail.sipthor.net (Postfix) with ESMTPSA id 648F0B0057; Fri, 7 Oct 2011 12:38:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <4E8ED457.7070803@ericsson.com> Date: Fri, 7 Oct 2011 12:38:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> <4E8E9796.1070704@ericsson.com> <392588C8-6301-4116-B7CC-9BDEF5FFC482@ag-projects.com> <4E8ED457.7070803@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: "aki.niemi@nokia.com Niemi" , Simple WG , Geir Arne Sandbakken Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 10:35:17 -0000 On Oct 7, 2011, at 12:28 PM, Miguel A. Garcia wrote: >=20 >=20 > On 07/10/2011 12:17, Saul Ibarra Corretge wrote: >> Hi, >>=20 >> On Oct 7, 2011, at 8:09 AM, Miguel A. Garcia wrote: >>=20 >>>=20 >>>=20 >>> On 07/10/2011 0:57, Ben Campbell wrote: >>>=20 >>>>> For issue 1, I think that we don't need an IANA registry at this = point, in particular because we are not expecting extensions to this = attribute. My proposal is to simply indicate that organizations that = want to extend this attribute and create new tokens should use their = reversed names to avoid clashes among then. >>>>=20 >>>> Out of curiosity, if we don't expect extensions, do we need the = extension point int he ABNF? >>>>=20 >>>=20 >>> It is hard to determine what the future will bring. If we remove the = extensibility now, and in the future we want to create an extension, = then we will be forced to create a new SDP attribute. If we have the = extensibility in place, but not the IANA registry, we can always create = the IANA registry at a later point. >>>=20 >>> So, I am leaning towards being conservative, and allow the = extensibility of the SDP 'chatroom' attribute, without having an IANA = registry at this point. >>>=20 >>=20 >> At some point we did consider extending this attribute to specify = that you may send some custom arbitrary data within a chat stream, for = example, so if a server would add 'x-something' to the 'chatroom' = attribute the client would know that it may send this kind of data. I'd = like to see extensibility for 'chatroom' allowed. >=20 > I agree with the extensibility of the attribute. I believe we can have = a policy indicating that if someone wants to extend this attribute for = their own purpose, they should prepend the value with the reversed DNS = name of the organization, for example: com.example.foo-chat. For the = time being, this seems to be enough. >=20 +1 The reversed DNS name of the organization seems good to me. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ben@nostrum.com Mon Oct 10 11:27:17 2011 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 18A0521F8C3D for ; Mon, 10 Oct 2011 11:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.52 X-Spam-Level: X-Spam-Status: No, score=-100.52 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_20=-0.74, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAcK036hTur4 for ; Mon, 10 Oct 2011 11:27:16 -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 9F9FB21F8C32 for ; Mon, 10 Oct 2011 11:27:16 -0700 (PDT) Received: from dn3-53.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9AIRD7f094029 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 Oct 2011 13:27:13 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4E8E9796.1070704@ericsson.com> Date: Mon, 10 Oct 2011 13:27:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7A98CE56-2B76-4CA6-8698-570F974F6A37@nostrum.com> References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> <4E8E9796.1070704@ericsson.com> To: "Miguel A. Garcia" X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Geir Arne Sandbakken , Simple WG , "aki.niemi@nokia.com Niemi" Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 18:27:17 -0000 On Oct 7, 2011, at 1:09 AM, Miguel A. Garcia wrote: >=20 >=20 > On 07/10/2011 0:57, Ben Campbell wrote: >=20 >>> For issue 1, I think that we don't need an IANA registry at this = point, in particular because we are not expecting extensions to this = attribute. My proposal is to simply indicate that organizations that = want to extend this attribute and create new tokens should use their = reversed names to avoid clashes among then. >>=20 >> Out of curiosity, if we don't expect extensions, do we need the = extension point int he ABNF? >>=20 >=20 > It is hard to determine what the future will bring. If we remove the = extensibility now, and in the future we want to create an extension, = then we will be forced to create a new SDP attribute. If we have the = extensibility in place, but not the IANA registry, we can always create = the IANA registry at a later point. >=20 > So, I am leaning towards being conservative, and allow the = extensibility of the SDP 'chatroom' attribute, without having an IANA = registry at this point. Okay--I do not object to that approach. From ag@ag-projects.com Mon Oct 10 11:44:58 2011 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 65C1F21F8C19 for ; Mon, 10 Oct 2011 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9WuNo0v4gvt for ; Mon, 10 Oct 2011 11:44:58 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id DE62621F8C0D for ; Mon, 10 Oct 2011 11:44:57 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id F3FCFB01B5; Mon, 10 Oct 2011 20:44:55 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id CF082B019E; Mon, 10 Oct 2011 20:44:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7A98CE56-2B76-4CA6-8698-570F974F6A37@nostrum.com> Date: Mon, 10 Oct 2011 20:44:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E8E0894.9030203@ericsson.com> <0E7B9EAD-27C4-407B-A5C6-19AEAED3778F@nostrum.com> <4E8E9796.1070704@ericsson.com> <7A98CE56-2B76-4CA6-8698-570F974F6A37@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Geir Arne Sandbakken , Simple WG , "aki.niemi@nokia.com Niemi" Subject: Re: [Simple] SDP comments to MSRP chat 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 Oct 2011 18:44:58 -0000 Yes, we have already extended the chatroom to advertise more features, = it is useful and necessary. Adrian =20 On Oct 10, 2011, at 8:27 PM, Ben Campbell wrote: >=20 > On Oct 7, 2011, at 1:09 AM, Miguel A. Garcia wrote: >=20 >>=20 >>=20 >> On 07/10/2011 0:57, Ben Campbell wrote: >>=20 >>>> For issue 1, I think that we don't need an IANA registry at this = point, in particular because we are not expecting extensions to this = attribute. My proposal is to simply indicate that organizations that = want to extend this attribute and create new tokens should use their = reversed names to avoid clashes among then. >>>=20 >>> Out of curiosity, if we don't expect extensions, do we need the = extension point int he ABNF? >>>=20 >>=20 >> It is hard to determine what the future will bring. If we remove the = extensibility now, and in the future we want to create an extension, = then we will be forced to create a new SDP attribute. If we have the = extensibility in place, but not the IANA registry, we can always create = the IANA registry at a later point. >>=20 >> So, I am leaning towards being conservative, and allow the = extensibility of the SDP 'chatroom' attribute, without having an IANA = registry at this point. >=20 > Okay--I do not object to that approach. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From hans.rohnert@nsn.com Wed Oct 12 06:13:58 2011 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 1622E21F8BA9 for ; Wed, 12 Oct 2011 06:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOOp6s7x2xvS for ; Wed, 12 Oct 2011 06:13:55 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDEE21F8B82 for ; Wed, 12 Oct 2011 06:13:51 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9CDDlGm012662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 15:13:47 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9CDDjna028224; Wed, 12 Oct 2011 15:13:47 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Oct 2011 15:13:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC88E0.C5CBCC29" Date: Wed, 12 Oct 2011 15:13:44 +0200 Message-ID: <9AF73DDF1D71944E8B2A94C48743BDF403010635@DEMUEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] are you aware of any documentation to implement MMSusing MSRP? Thread-Index: Acx/V9CcyQDfVHJYQcClgfo1FhAhWQJh/uGA References: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> <58DB2CE4-76BE-46BE-B38B-633A0C5AA7A2@nostrum.com> <9AF73DDF1D71944E8B2A94C48743BDF402CD999B@DEMUEXC035.nsn-intra.net> From: "Rohnert, Hans (NSN - DE/Munich)" To: "ext prasun bheri" X-OriginalArrivalTime: 12 Oct 2011 13:13:45.0996 (UTC) FILETIME=[C5D404C0:01CC88E0] Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing 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: Wed, 12 Oct 2011 13:13:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC88E0.C5CBCC29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Prasun, =20 you may find the CPM specifications at http://www.openmobilealliance.org/Technical/release_program/cpm_v1_0.asp x=20 =20 Your below scenario may be solved in different ways. It is so special that standards will not help you much here. The closest to this CPM is offering is CPM-to-MMS interworking, see the interworking spec at below link. However, CPM-to-MMS interworking is targeted to scenarios where A user sends a CPM message to a CPM server (and this can be based on MSRP for large messages), CPM server forwards to interworking entity, interworking entity translates CPM message to MMS message, interworking entity forwards to MMS server, MMS server forwards to B user being on MMS service. =20 =20 Regards, Hans =20 From: ext prasun bheri [mailto:prasun.bheri@gmail.com]=20 Sent: Friday, September 30, 2011 12:00 PM To: Rohnert, Hans (NSN - DE/Munich) Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing MSRP? =20 Hello Hans and group, =20 i have tried searching CPM specs but haven't found anything close enough,=20 may be i am looking in the wrong direction altogether. so ill explain the exact scenario and=20 perhaps you guys can guide me towards the right direction.=20 =20 my task at hand is to deliver mms payload to mmsc (gateway) using msrp protocol.=20 mms architecture defines mm1 interface protocol to transfer mms from user agent to=20 mmsc gateway so i am guessing that some where with in or in parallel to mm1 protocol=20 i have to use msrp to transfer mms payload to gateway.=20 =20 i am not finding any supporting document that speaks about transferring mms to mmsc gateway using msrp. what is it that i am missing?=20 =20 any help is greatly appreciated.=20 =20 thanks & regards -prasun=20 =20 =20 =20 =20 =20 On Tue, Aug 30, 2011 at 5:13 AM, Rohnert, Hans (NSN - DE/Munich) wrote: OMA CPM and GSMA RCS do not do exactly "implement MMS using MSRP". Rather the following: =20 GSMA RCS uses MMS as is for messaging needs (however, there are multiple GSMA RCS versions differing in their respective messaging capabilities and means, and you would need to take a closer look here before making generic statements about GSMA RCS).=20 =20 OMA CPM is its own messaging enabler, leveraging on different IETF facilities (e.g. SIP MESSAGE and MSRP) for constructing and sending "CPM messages". Also, CPM defines an interworking between CPM messages and MMS messages. There, it is described how one kind of message can be translated into the other. =20 Hope this helps, Hans Rohnert =20 From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Monday, August 29, 2011 5:54 AM To: gonther rik Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing MSRP? =20 I am not aware of any such document from the IETF. You might take a look at the OMA CPM or GSMA RCS specs to see if they have anything that meets your needs. =20 On Aug 29, 2011, at 12:40 AM, gonther rik wrote: =20 Hello Group, could you please guide me to an rfc or some documentation mentioning how to implement MMS using MSRP =20 Thanks & Regards -Rik _______________________________________________ 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 ------_=_NextPart_001_01CC88E0.C5CBCC29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Prasun,

 

you may find the CPM specifications at

http://www.openmobilealliance.org/Technical/release_program/cpm= _v1_0.aspx

 

Your below scenario may be solved in different ways. It is so special = that standards will not help you much here. The closest to this CPM is = offering is CPM-to-MMS interworking, see the interworking spec at below = link. However, CPM-to-MMS interworking is targeted to scenarios where A = user sends a CPM message to a CPM server (and this can be based on MSRP = for large messages), CPM server forwards to interworking entity, = interworking entity translates CPM message to MMS message, interworking = entity forwards to MMS server, MMS server forwards to B user being on = MMS service.  

 

Regards,

Hans

 

From:= ext prasun = bheri [mailto:prasun.bheri@gmail.com]
Sent: Friday, September = 30, 2011 12:00 PM
To: Rohnert, Hans (NSN - = DE/Munich)
Cc: Simple@ietf.org
Subject: Re: [Simple] = are you aware of any documentation to implement MMSusing = MSRP?

 

Hello Hans = and group,

 

i = have tried searching CPM specs but haven't found anything close = enough, 

may be i am = looking in the wrong direction altogether. so ill explain the exact = scenario and 

perhaps = you guys can guide me towards the right = direction. 

 

my task at hand is to deliver mms payload to mmsc = (gateway) using msrp protocol. 

mms architecture defines mm1 interface protocol to = transfer mms from user agent to 

mmsc gateway so i am guessing that some where = with in or in parallel to mm1 protocol 

i have to use msrp to transfer mms payload to = gateway. 

 

i = am not finding any supporting document that speaks about transferring = mms to mmsc

gateway using = msrp. what is it that i am missing? 

 

any help is = greatly appreciated. 

 

thanks & regards

-prasun 

 

 

 

 

 

On Tue, Aug 30, 2011 at 5:13 AM, Rohnert, Hans (NSN - = DE/Munich) <hans.rohnert@nsn.com> = wrote:

OMA CPM and GSMA = RCS do not do exactly “implement MMS using MSRP”. Rather the = following:

 

GSMA RCS uses MMS = as is for messaging needs (however, there are multiple GSMA RCS versions = differing in their respective messaging capabilities and means, and you = would need to take a closer look here before making generic statements = about GSMA RCS).

 

OMA CPM is its own = messaging enabler, leveraging on different IETF facilities (e.g. SIP = MESSAGE and MSRP) for constructing and sending “CPM = messages”. Also, CPM defines an interworking between CPM messages = and MMS messages. There, it is described how one kind of message can be = translated into the other.

 

Hope this = helps,

Hans = Rohnert

 

From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext = Ben Campbell
Sent: Monday, August 29, 2011 5:54 = AM
To: gonther rik
Cc: Simple@ietf.org


Subject: Re: [Simple] are you aware of any = documentation to implement MMSusing = MSRP?

 <= /o:p>

I am not = aware of any such document from the IETF. You might take a look at the = OMA CPM or GSMA RCS specs to see if they have anything that meets your = needs.

 <= /o:p>

On Aug 29, = 2011, at 12:40 AM, gonther rik wrote:

 <= /p>

Hello = Group,

could you please guide me to an rfc or = some documentation mentioning how to implement MMS using = MSRP

 

Thanks & = Regards

-Rik

____________= ___________________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

 <= /o:p>


______________________________________= _________
Simple mailing list
Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simple

 

------_=_NextPart_001_01CC88E0.C5CBCC29-- From wwwrun@rfc-editor.org Wed Oct 12 10:01:53 2011 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 3E4C121F8C9F for ; Wed, 12 Oct 2011 10:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umKTOiCCOY26 for ; Wed, 12 Oct 2011 10:01:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BDFE121F8C67 for ; Wed, 12 Oct 2011 10:01:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9E7A698C275; Wed, 12 Oct 2011 10:01:51 -0700 (PDT) To: fluffy@cisco.com, rohan@ekabal.com, adam@estacado.net, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20111012170151.9E7A698C275@rfc-editor.org> Date: Wed, 12 Oct 2011 10:01:51 -0700 (PDT) X-Mailman-Approved-At: Thu, 13 Oct 2011 08:01:49 -0700 Cc: simple@ietf.org, rfc-editor@rfc-editor.org Subject: [Simple] [Editorial Errata Reported] RFC4976 (2993) 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 Oct 2011 17:01:53 -0000 The following errata report has been submitted for RFC4976, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4976&eid=2993 -------------------------------------- Type: Editorial Reported by: Iņaki Baz Castillo Section: 3 Original Text ------------- Alice a.example.org b.example.net Bob | | | | |--- SEND 1-3 ------->| | | |<-- 200 OK ----------| | (slow link) | |--- SEND 4-7 ------->|--- SEND 1-5 ------>| | |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->| |--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>| |<-- 200 OK ----------|<-- 200 OK ---------| ..>| | | |<-- 200 OK ----------| | | |<-- REPORT 1-3 ------| | |<-- REPORT 1-3 -----|--- SEND 4-7 ------->| |<-- REPORT 1-3 ------| | ...>| | | |<-- REPORT 4-7 ----->| | |<-- REPORT 4-7 -----|--- SEND 8-10 ------>| |<-- REPORT 4-7 ------| | ..>| | | |<-- 200 OK ----------| | |<-- REPORT done-----|<-- REPORT done -----| |<-- REPORT done -----| | | | | | | Corrected Text -------------- Alice a.example.org b.example.net Bob | | | | |--- SEND 1-3 ------->| | | |<-- 200 OK ----------| | (slow link) | |--- SEND 4-7 ------->|--- SEND 1-5 ------>| | |<-- 200 OK ----------|<-- 200 OK ---------|--- SEND 1-3 ------->| |--- SEND 8-10 ------>|--- SEND 6-10 ----->| ....>| |<-- 200 OK ----------|<-- 200 OK ---------| ..>| | | |<-- 200 OK ----------| | | |<-- REPORT 1-3 ------| | |<-- REPORT 1-3 -----|--- SEND 4-7 ------->| |<-- REPORT 1-3 ------| | ...>| | | |<-- 200 OK ----------| | | |<-- REPORT 4-7 ----->| | |<-- REPORT 4-7 -----|--- SEND 8-10 ------>| |<-- REPORT 4-7 ------| | ..>| | | |<-- 200 OK ----------| | |<-- REPORT done-----|<-- REPORT done -----| |<-- REPORT done -----| | | | | | | Notes ----- The flow in page 10 lacks the mandatory 200 OK for the SEND 4-7 received by Bob. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4976 (draft-ietf-simple-msrp-relays-10) -------------------------------------- Title : Relay Extensions for the Message Sessions Relay Protocol (MSRP) Publication Date : September 2007 Author(s) : C. Jennings, R. Mahy, A. B. Roach Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG