From nobody Fri Oct 24 22:35:55 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5AA1A6EE0 for ; Fri, 24 Oct 2014 22:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZ3FDnji5O94 for ; Fri, 24 Oct 2014 22:35:52 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1911A6EED for ; Fri, 24 Oct 2014 22:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3788; q=dns/txt; s=iport; t=1414215351; x=1415424951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OwaQAOW8inNcBMVw2CaseRVu86y27sjo28KqhSl62h8=; b=jQxZXh9HUYfIzFvZrXLJ5l8im2NINElTJXkd/OcoLTyR2W+JAGiB980F 9t5Gejd9s7Btp1/HFXCIR0r3pOSpEK4LAUxN1Hkwhf0Quh0veIptIaXj3 KhLYi6SK7THs57rx092GE2nruD3JBm7hehaWoW+17cElSpHCYqt+IqoGV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAGg1S1StJV2Y/2dsb2JhbABcgw5UWATNLgqGeVQCgQgWAX2EAwEBAwEBAQE3NAsFCwIBCDYQJwslAgQOBYg4CQ3JYgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEjRQBgxAzB4MtgR4Fhi2JOoIei1iBMY1cgx+EAIIOgWpsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,784,1406592000"; d="scan'208";a="90218014" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 25 Oct 2014 05:35:50 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9P5Zos3015237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 05:35:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 00:35:50 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 Thread-Index: AQHP8BWJCwSDfPg300+IpT5cmC6Lsw== Date: Sat, 25 Oct 2014 05:35:49 +0000 Message-ID: <2E59C3F1-E5DF-4CF2-A8F9-18B119BCF7CF@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B1D433CBF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D433CBF@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.220.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <0B451A9EE2C2334AB4E301ECEC091157@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/I-yNLtXuPdNfc-MEQetgt410a8s Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 05:35:54 -0000 Thanks, for the thorough review, Christer. Responses inline... On Aug 30, 2014, at 4:57 AM, Christer Holmberg wrote: > Hi, >=20 > Below are my comments. I appologise for not providing them earlier, as pr= omissed. They are mostly editorial, but would still require some work if ac= cepted. >=20 > --------------- >=20 > Section 1 (Introduction): > ------------------------------ >=20 > Q1_1: I don't understand the need for the last paragraph, talking about t= he draft not preventing the usage of other transport mechanisms. Why does t= he draft need to say that?. IF that needs to be said, it should be said in = the base BFCP spec. Fixed. > Section 3: > ------------ >=20 > Q3_1: Why is this section needed? The draft is not a teach-yourself-webso= cket document, is it? :) >=20 > In my opinion the draft should reference the WebSocket RFC for = general information about WebSocket, and the draft then describes the BFCP = specifics - ie what is described in section 4. >=20 > Otherwise, if some details of WebSocket change in the future, y= ou may have to update this RFC also - even if the change does not affect th= e BFCP usage of WebSocket. A bit of explanatory text was requested in early reviews. I myself find it= useful to provide modest baseline information self-contained in the docume= nt. This is also common practice in all the foo over WebSockets documents,= including RFC 7118. That said, if you feel strongly it should be removed,= we can do so.=20 > Section 4: > ------------ >=20 > Q4_1: I'd suggest to change "through" to "over", "using", or something si= milar. Fixed. > Section 5: > ------------ >=20 > Q5_1: I'd suggest to change the section name to "Transport reliability" Fixed. > Section 6: > ------------ >=20 > Q6_1: I'd suggest to change the section name to "SDP Considerations", wit= h separate subsections for the new transport value, the new SDP attribute e= tc. Fixed. > Q6_2: Is the new SDP ws-uri attribute BFCP specific? If not, should it be= in a separate draft? No, it isn't BFCP-specific and your point makes sense. Having a general SD= P attribute for SDP negotiated protocols over Websocket is meaningful and w= ould facilitate future protocols over Websocket. Once I create a new draft = I'll remove this bit of text and replace it with a reference to the new doc= ument. Expect this for the -03 version. > Q6_3: I think it would be good to have a reference to a document which ta= lks more about the URI matching requirement. >=20 > Something like: "As defined in section YYYY of RFC XXXX, when u= sing Secure Websockets the CNAME of the SSL certificate must match the WebS= ocket connection URI host..." I agree with the comment, but not sure what the reference should be. Not su= re what will be the correct reference. Do you think something like RFC 2818= Section 3 would work? > Q6_4: As you define a new SDP attribute, you should have a "SDP Offer/Ans= wer Proceudures" section. Do you mean an Offer/Answer sections in line with RFC 3264 that has the fol= lowing sub-sections with relevant procedures called out? 1) Generating the Initial Offer 2) Generating the Answer 3) Offerer Processing of the Answer 4) Modify the Session Something like what we did in Section 4 of RFC 7345? If so, that will take= me a bit of time and will need to wait until -03 as I have much to do befo= re the submission deadline. Thanks, Gonzalo >=20 >=20 > Thanks! >=20 > Regards, >=20 > Christer > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Sat Oct 25 04:40:35 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0441A87BF for ; Sat, 25 Oct 2014 04:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2vCqFvesAFX for ; Sat, 25 Oct 2014 04:40:30 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063C21A87BB for ; Sat, 25 Oct 2014 04:40:29 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-d2-544b8c2bba67 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CB.7F.24955.B2C8B445; Sat, 25 Oct 2014 13:40:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Sat, 25 Oct 2014 13:40:27 +0200 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 Thread-Index: Ac/wRznBR+04TbApTaGrE+CWTzL75A== Date: Sat, 25 Oct 2014 11:40:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja52j3eIwfkjNhb/1h1lstg06wub xdwpfg7MHlN+b2T1WLLkJ1MAUxSXTUpqTmZZapG+XQJXxsI/NgX7JCoazmxgaWB8L9TFyMkh IWAi8XniK2YIW0ziwr31bF2MXBxCAkcZJbZvXMkE4SxhlHj57ztQFQcHm4CFRPc/bZAGEQFz iT2/W9hAwswCURIfdjCCmMICARLPXlZCVARK3OmezwJh60n0H3/CBmKzCKhK7NnXyQpi8wr4 ShyaOwPsBEagE76fWsMEYjMLiEvcejKfCeI0AYkle85DnSkq8fLxP1YIW0li0e3PUPU6Egt2 f2KDsLUlli18zQwxX1Di5MwnLBMYRWYhGTsLScssJC2zkLQsYGRZxShanFqclJtuZKyXWpSZ XFycn6eXl1qyiREYEQe3/FbdwXj5jeMhRgEORiUeXgUW7xAh1sSy4srcQ4zSHCxK4rwLz80L FhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYLtaVZOAnlGzDs7d83lkNvkZxrWkZ637mc27Y sptPbVVcXbODjdrW+GOLJY6s/cm/ctM0Wak5TWFutyJrnv2I4FojGWYWyF3lVdVb/4CRUzGl 6FlvcvgcwW1VrOsMBR9Hcl+4sHdP376cym65gwVvd7zSz7J5pX88ZfLlKeFtenkhl3f/OKnE UpyRaKjFXFScCADQN+waaQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/DKTz2-q_aMRZ-Sqb8wAZQZqgBVo Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 11:40:33 -0000 Hi, >> Section 3: >> ------------ >>=20 >> Q3_1: Why is this section needed? The draft is not a teach-yourself-webs= ocket document, is it? :) >>=20 >> In my opinion the draft should reference the WebSocket RFC for= general information about WebSocket, and=20 >> the draft then describes the BFCP specifics - ie what is describ= ed in section 4. >>=20 >> Otherwise, if some details of WebSocket change in the future, = you may have to update this RFC=20 >> also - even if the change does not affect the BFCP usage of We= bSocket. > > A bit of explanatory text was requested in early reviews. I myself find = it useful to provide modest=20 > baseline information self-contained in the document. This is also common= practice in all the foo=20 > over WebSockets documents, including RFC 7118. That said, if you feel st= rongly it should be removed, we can do so.=20 If you want to keep it, I will withdraw my comment. It's just an editorial = thing :) ... >> Q6_2: Is the new SDP ws-uri attribute BFCP specific? If not, should it b= e in a separate draft? > > No, it isn't BFCP-specific and your point makes sense. Having a general = SDP attribute for SDP negotiated=20 > protocols over Websocket is meaningful and would facilitate future protoc= ols over Websocket. Once I create=20 > a new draft I'll remove this bit of text and replace it with a reference = to the new document. Expect this for the -03 version. >> Q6_3: I think it would be good to have a reference to a document which t= alks more about the URI matching requirement. >>=20 >> Something like: "As defined in section YYYY of RFC XXXX, when = using Secure Websockets the CNAME=20 >> of the SSL certificate must match the WebSocket connection URI= host..." > > I agree with the comment, but not sure what the reference should be. Not = sure what will be the correct reference.=20 > Do you think something like RFC 2818 Section 3 would work? I don't know where the requirement comes from, but I assume it must be defi= ned somewhere :) Anyway, if you move the SDP ws-uri attribute definition into a separate dra= ft I assume this text would also be in that draft. >> Q6_4: As you define a new SDP attribute, you should have a "SDP Offer/An= swer Proceudures" section. > > Do you mean an Offer/Answer sections in line with RFC 3264 that has the f= ollowing sub-sections with relevant procedures called out? > > 1) Generating the Initial Offer > 2) Generating the Answer > 3) Offerer Processing of the Answer > 4) Modify the Session > > Something like what we did in Section 4 of RFC 7345? Correct. Again, if you move the attribute definition to a separate draft, you only n= eed to define the O/A procedures for the new m- line transport field values= in this draft. > If so, that will take me a bit of time and will need to wait until -03 as= I have much to do before the submission deadline. That is ok. I guess you could put the section names into -02, and add the c= ontent later. Regards, Christer From nobody Sat Oct 25 13:48:20 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93F0D1A1BF9 for ; Sat, 25 Oct 2014 13:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxWmiz77yRKF for ; Sat, 25 Oct 2014 13:48:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF17C1A19E2 for ; Sat, 25 Oct 2014 13:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3870; q=dns/txt; s=iport; t=1414270097; x=1415479697; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rGaZTIdMFhb7zCFgCxbXHOFmmpWEDzEp1H8tF4xYreg=; b=jX4AF2NU6nEdQYXQbaFxAJZzAF0dGFIdto4WEmeg4xcZg0FWbFpfHVJg OF81jRyOeNCb0ZGZNV3kg/WKgccKi9dytQcBeG5XgqNjLryiaudrxnAEI TuXXLgNM0Odh4lkG0i5LL4WyMThd28s7hDzugSeEq12nBjIV5Utn8k9Tl M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAFMMTFStJA2N/2dsb2JhbABcgw6BLATVHwKBBhYBfYQCAQEBAwE6PwULAgEIGB4QMiUBAQQOBYg4Ccg4AQEBAQEBAQEBAQEBAQEBAQEBAQEBF406AYMaMweDLYEeAQSGLYtai1qBMY1egx+EAIIOgWpsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,787,1406592000"; d="scan'208";a="90325036" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 25 Oct 2014 20:48:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9PKmF36030986 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Oct 2014 20:48:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.20]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sat, 25 Oct 2014 15:48:14 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 Thread-Index: Ac/wRznBR+04TbApTaGrE+CWTzL75AAd61uA Date: Sat, 25 Oct 2014 20:48:13 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C7E90@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.231.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BA55DC771768C429494BD8D39740143@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/I6NRaEJEa5WJuDWuI3WsPO61azE Cc: "bfcpbis@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [bfcpbis] reminder to review draft-ietf-bfcpbis-bfcp-websocket-01 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 20:48:19 -0000 Thanks, Christer. This gives us a good way forward. In summary: I'll produce an -02 with the agreed upon changes here. Once I p= roduce a new draft for the ws-uri BFCP-independent SDP attribute I will pub= lish an -03 that has that text removed and referencing the new draft. The = new draft will contain a "SDP Offer/Answer Proceudures" section, whereas th= e -03 will also have such a section but defining the O/A procedures for the= new m- line transport field values. Cheers, Gonzalo > On Oct 25, 2014, at 7:40 AM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> Section 3: >>> ------------ >>>=20 >>> Q3_1: Why is this section needed? The draft is not a teach-yourself-web= socket document, is it? :) >>>=20 >>> In my opinion the draft should reference the WebSocket RFC for= general information about WebSocket, and=20 >>> the draft then describes the BFCP specifics - ie what is describ= ed in section 4. >>>=20 >>> Otherwise, if some details of WebSocket change in the future, = you may have to update this RFC=20 >>> also - even if the change does not affect the BFCP usage of We= bSocket. >>=20 >> A bit of explanatory text was requested in early reviews. I myself find= it useful to provide modest=20 >> baseline information self-contained in the document. This is also commo= n practice in all the foo=20 >> over WebSockets documents, including RFC 7118. That said, if you feel s= trongly it should be removed, we can do so.=20 >=20 > If you want to keep it, I will withdraw my comment. It's just an editoria= l thing :) >=20 > ... >=20 >>> Q6_2: Is the new SDP ws-uri attribute BFCP specific? If not, should it = be in a separate draft? >>=20 >> No, it isn't BFCP-specific and your point makes sense. Having a general= SDP attribute for SDP negotiated=20 >> protocols over Websocket is meaningful and would facilitate future proto= cols over Websocket. Once I create=20 >> a new draft I'll remove this bit of text and replace it with a reference= to the new document. Expect this for the -03 version. >=20 >>> Q6_3: I think it would be good to have a reference to a document which = talks more about the URI matching requirement. >>>=20 >>> Something like: "As defined in section YYYY of RFC XXXX, when = using Secure Websockets the CNAME=20 >>> of the SSL certificate must match the WebSocket connection URI= host..." >>=20 >> I agree with the comment, but not sure what the reference should be. Not= sure what will be the correct reference.=20 >> Do you think something like RFC 2818 Section 3 would work? >=20 > I don't know where the requirement comes from, but I assume it must be de= fined somewhere :) >=20 > Anyway, if you move the SDP ws-uri attribute definition into a separate d= raft I assume this text would also be in that draft. >=20 >>> Q6_4: As you define a new SDP attribute, you should have a "SDP Offer/A= nswer Proceudures" section. >>=20 >> Do you mean an Offer/Answer sections in line with RFC 3264 that has the = following sub-sections with relevant procedures called out? >>=20 >> 1) Generating the Initial Offer >> 2) Generating the Answer >> 3) Offerer Processing of the Answer >> 4) Modify the Session >>=20 >> Something like what we did in Section 4 of RFC 7345? >=20 > Correct. >=20 > Again, if you move the attribute definition to a separate draft, you only= need to define the O/A procedures for the new m- line transport field valu= es in this draft. >=20 >> If so, that will take me a bit of time and will need to wait until -03 a= s I have much to do before the submission deadline. >=20 > That is ok. I guess you could put the section names into -02, and add the= content later. >=20 > Regards, >=20 > Christer From nobody Sat Oct 25 14:59:48 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE861A6EE4; Sat, 25 Oct 2014 14:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-LMeHEKizvq; Sat, 25 Oct 2014 14:59:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7571A0264; Sat, 25 Oct 2014 14:59:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141025215944.8575.81458.idtracker@ietfa.amsl.com> Date: Sat, 25 Oct 2014 14:59:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/vRLloikgovnP0LQMaRx9Ct0j4ZQ Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-02.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Oct 2014 21:59:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) Authors : Victor Pascual Anton Roman Stephane Cazeaux Gonzalo Salgueiro Sergio Garcia Murillo Filename : draft-ietf-bfcpbis-bfcp-websocket-02.txt Pages : 13 Date : 2014-10-25 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. This document normatively updates [I-D.draft-ietf- bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-bfcp-websocket-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:39:38 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35601A9152; Mon, 27 Oct 2014 13:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogeGGJV9HM34; Mon, 27 Oct 2014 13:39:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0023D1A011E; Mon, 27 Oct 2014 13:39:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027203920.31927.60508.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:39:20 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/-a9KlIEXcTtyasl3qxzmAdijboM Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4582bis-12.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:39:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The Binary Floor Control Protocol (BFCP) Authors : Gonzalo Camarillo Keith Drage Tom Kristensen Joerg Ott Charles Eckel Filename : draft-ietf-bfcpbis-rfc4582bis-12.txt Pages : 89 Date : 2014-10-27 Abstract: Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4582bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 27 13:41:00 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FCE1AD3C0; Mon, 27 Oct 2014 13:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9XE3Sf5fEyt; Mon, 27 Oct 2014 13:40:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A12251A1A56; Mon, 27 Oct 2014 13:40:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027204041.31976.26786.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 13:40:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/iOP-bzu-LE1UGuz0-S-jjOqnRzM Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-rfc4583bis-10.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:40:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams Authors : Gonzalo Camarillo Tom Kristensen Filename : draft-ietf-bfcpbis-rfc4583bis-10.txt Pages : 17 Date : 2014-10-27 Abstract: This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 13. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 28 15:46:04 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49EC1A01C6 for ; Tue, 28 Oct 2014 15:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAK8QjEResVW for ; Tue, 28 Oct 2014 15:46:00 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1497A1A0030 for ; Tue, 28 Oct 2014 15:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=409; q=dns/txt; s=iport; t=1414536361; x=1415745961; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WvQ1ZGVE+fNSI3Fr5MmwTaXl4pFiBBhRMdFeKNBrnBE=; b=mGtaPDtWuG6vC4dPv0H8Y14fnPm4Db+88ZwCk70CE9QB1aX/p3TOPhmN pLdjDywuxdmDnExk0RKRZwEVr1+DEnBekZgQbxIHWIljEAFVrml7aFeSu oicmWlS7lfzooMvpwG6FlYna62ygwWBnbXi1ea0Uj5eEsd8LYayaZxmj+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAPwbUFStJV2U/2dsb2JhbABcgw5UXM4/iHMWAQEBAQFyC4QJOlEBPkInBIhUDaEfpEYslVsFkguESocTgTE8gw2NO4QBg3iCNIEDAQEB X-IronPort-AV: E=Sophos;i="5.04,805,1406592000"; d="scan'208";a="91187941" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 28 Oct 2014 22:46:00 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s9SMjxFU028205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Oct 2014 22:45:59 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.231]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 17:45:59 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: IETF 91 prep reminder - REVIEW DRAFTS Thread-Index: AQHP8wDwgrRXywEOWUqAUTlrzGEL1g== Date: Tue, 28 Oct 2014 22:45:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/nGMMgdTMsM5z3ORU1Og8pB7IXEg Subject: [bfcpbis] IETF 91 prep reminder - REVIEW DRAFTS X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:46:02 -0000 Updated versions of all 3 working group drafts posted recently: http://tools.ietf.org/wg/bfcpbis/ Thanks to all the draft authors/editors. We will not be meeting officially at IETF 91, but that does not mean there is no work to do. Please review the drafts and post your comments (preferably prior to the meeting), including confirming that previous comments have been addressed. Cheers, Charles