From beepwg-admin@lists.beepcore.org Thu Oct 25 14:45:36 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27202 for ; Thu, 25 Oct 2001 14:45:34 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9PIc8g01069; Thu, 25 Oct 2001 11:38:08 -0700 (PDT) Received: from plexus.cst.ca (plexus.CST.CA [207.139.176.42]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9PIb8g01057 for ; Thu, 25 Oct 2001 11:37:09 -0700 (PDT) Received: from earth.in.steltor.com (earth.in.steltor.com [101.1.1.100]) by plexus.cst.ca (8.9.3/1.0.1) with ESMTP id OAA16615 for ; Thu, 25 Oct 2001 14:42:52 -0400 Received: from steltor.com (IDENT:patricel@c-1241.in.steltor.com [101.1.42.10]) by earth.in.steltor.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f9PIgpH06559 for ; Thu, 25 Oct 2001 14:42:51 -0400 (EDT) Message-ID: <3BD85EAE.F086D8DA@steltor.com> From: Patrice Lapierre X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.10 i686) X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [BEEPwg] CAP will use BEEP. Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Thu, 25 Oct 2001 14:49:18 -0400 Content-Transfer-Encoding: 7bit Hello all, This is to let the members of the mailing list know that CAP (Calendar Access Protocol) is going to be transformed into a BEEP profile. At this stage the conversion is only beginning, but thanks to BEEP's flexible design, the process should be relatively straight forward. I am however new to BEEP, and therefore I'll probably have some questions for this list in the near future. Of course any suggestions or concerns you may have are more than welcome. For more information on CAP and the IETF Calendaring and Scheduling (calsch) Working Group, you can refer to the following pages: http://www.imc.org/draft-ietf-calsch-cap http://www.imc.org/ietf-calendar/index.html Thanks, Patrice. > Subject: CAP: CAP and BEEP [Was: Re: BEEP Protocol and Internationalization: Interim meeting?] > Date: Tue, 16 Oct 2001 11:32:54 -0400 > From: George Babics > To: ietf-calendar@imc.org > References: > >George Babics wrote: > > Hi All, > > We are going to rewrite the transport layer of CAP > to use BEEP (RFC 3080). It will help us resolve many > issues and help us avoid reinventing the wheel. If > anyone has any concerns please let us know now. > > George > > > Bob Mahoney wrote: > > > > Folks- > > > > We've been asked to look at two issues by our Area Directors. > > > > 1) Internationalization is becoming increasingly high-profile, and it > > is *not* an optional concern for us. In depth conversations between > > Patrik and the Kerberos WG indicates there are issues we have yet to > > deal with. > > > > The guess is that we have some work to do for this. > > > > 2) Ned attended our meeting in London, and after a detailed reading > > of the CAP draft, suggested (with reluctance given the late date) > > that we look closer at the BEEP work. He suggested we consider using > > BEEP, or perhaps just move some of our overhead down into the > > "payload", to simplify a future conversion to BEEP. > > > > Casual conversations in London indicate that we may be able to deal > > with this quickly, given the right folks focusing on it for a short > > time. > > > > We asked Patrik and Ned if they would object to an interim meeting to > > focus on these two points, and they were fine with that. > > > > So, would people be open to an interim meeting on the east coast > > someplace, in an early October November time frame? I can probably > > get space at MIT without difficulty, if that is acceptable. > > > > Please let us know. > > > > -Bob > > > > Some drafts to read: > > > > BEEP > > > > Mapping the BEEP Core onto TCP (RFC 3081) http://www.ietf.org/rfc/rfc3081.txt > > The Blocks Extensible Exchange Protocol Core (RFC 3080) > > http://www.ietf.org/rfc/rfc3080.txt > > > > IDN > > > > Internationalizing Host Names In Applications (IDNA) > > http://search.ietf.org/internet-drafts/draft-ietf-idn-idna-03.txt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 00:21:05 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06150 for ; Tue, 30 Oct 2001 00:21:01 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9U5DE022611; Mon, 29 Oct 2001 21:13:15 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9U537012402 for ; Mon, 29 Oct 2001 21:03:07 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 6300D13A3F; Tue, 30 Oct 2001 00:09:15 -0500 (EST) To: "Marshall Rose" Cc: Cc: protocol@permabit.com From: Jered Floyd In-Reply-To: <1f2f01c13b9c$92f91960$8d53cf3f@FATORA> Message-ID: <87snc1k938.fsf@questionably-configured.permabit.com> Lines: 112 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Oct 2001 00:09:15 -0500 I've come across three items in RFCs 3080/3081 that are causing me some confusion. I'm hoping that you can clear these up for me. RFC 3080, Section 2.3.1.2 The Start Message, [p. 17]: [...] o each "profile" element contained with the "start" element has a "uri" attribute, an optional "encoding" attribute, and arbitrary character data as content: * the "uri" attribute authoritatively identifies the profile; * the "encoding" attribute, if present, specifies whether the content of the "profile" element is represented as a base64- encoded string; and, * the content of the "profile" element, if present, must be no longer than 4K octets in length and specifies an initialization message given to the channel as soon as it is created. [...] Consider the situation where content is provided, and the "encoding" attribute has the value "base64". It is unclear to me, from the above passage, in which character set the decoded data should be taken. The intuitive answer is to claim that the decoded base64 data should be taken to be in the same character set as the enclosing MIME body. While tempting, I believe this is incorrect. The MIME body may have undergone translation in transit, either internal to the BEEP library, or within a BEEP protocol proxy. Unfortunately, the only solution I can come up with is to say that the "profile" element contained within a "start" message may also optionally have a "text-encoding" attribute, defaulting to "UTF-8", specifying the text encoding of base64-encoded data. Does anyone have a better solution? This next one is really a nitpick: RFC 3080, Section 7.1 BEEP Channel Management DTD, [p. 49]: [...] [...] My concern here is that the comment here is just that, a comment. It is a semantic check that cannot be performed by a validating XML processor, only by the channel management implementation itself. As such, the DTD claims that element "profile" contains PCDATA. In RFC 3080, Section 2.3.1, all uses of "profile" in "greeting" elements, and many uses of "profile" in "start" elements, make use of the XML empty element notation, "". This is poor XML. The "Extensible Markup Language (XML) 1.0 (Second Edition)" W3C recommendation, section 3.1 Start-Tags, End-Tags, and Empty-Element Tags, states: Empty-element tags may be used for any element which has no content, whether or not it is declared using the keyword EMPTY. For interoperability, the empty-element tag should be used, and should only be used, for elements which are declared EMPTY. Finally, an issue that RFC 3081 fails to address, that perhaps ought to be addressed in RFC 3080 as well. "Mapping the BEEP Core onto TCP" adopts the concept of window-based flow control from TCP. Unfortunately, it fails to adopt TCP's mechanisms for minimizing framing overhead (the Nagle algorithm, RFC 896; and SWS avoidance, RFC 1122, Section 4.2.3.4). Thus, nothing in RFC 3080 or 3081 discourages a BEEP from sending many frames with single-byte payloads, either due to poor implementation, or TCP-like Silly Window Syndrome [SWS]. I believe that BEEP is vulnerable to SWS. The Nagle algorithm is not necessary as I believe one should never expect 'interactive' performance for frames within a single BEEP message; however the SWS avoidance mechanisms described in RFC 1122 are applicable. Thus, I believe that RFC 3081 (perhaps Section 3.1.2?) should be amended to include wording along the lines of: A BEEP implementation MUST include a SWS avoidance algorithm in the sender, in order to avoid excessive framing overhead due to poor fragmentation of a message into frames. To avoid sending many small frames, a BEEP should not generate a frame unless: o a maximum-sized frame can be sent; i.e. a frame can be generated that is the full MSS of the underlying transport; or o a frame of at least one-half of the maximum window size advertised may be sent [NOTE: This condition is mostly a formality; given that the TCP mapping defines a minimum 4K window size, this condition would only be met on a TCP socket with an MSS greater than or equal to 2K. This is the case on the loopback interface on many operating systems, but not on any networks of which I am aware.]; or o a frame containing all remaining data on a message may be generated. This text would alleviate my concerns of poor network utilization by BEEP; the above are the guidelines that my implementation follows and that I believe should be universal. Please let me know if I should provide further clarification on any of these concerns! Thank you for your time. -- Jered Floyd -- jered@permabit.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 01:53:43 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12664 for ; Tue, 30 Oct 2001 01:53:42 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9U6l3001873; Mon, 29 Oct 2001 22:47:03 -0800 (PST) Received: from egyptian-gods.MIT.EDU (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9U6kd001861 for ; Mon, 29 Oct 2001 22:46:40 -0800 (PST) Received: (from ghudson@localhost) by egyptian-gods.MIT.EDU (8.9.3) id BAA32495; Tue, 30 Oct 2001 01:52:47 -0500 Message-Id: <200110300652.BAA32495@egyptian-gods.MIT.EDU> To: Jered Floyd cc: beepwg@lists.beepcore.org, protocol@permabit.com Subject: Re: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) In-Reply-To: Your message of "30 Oct 2001 00:09:15 EST." <87snc1k938.fsf@questionably-configured.permabit.com> From: Greg Hudson Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Oct 2001 01:52:47 -0500 > It is unclear to me, from the above passage, in which character set > the decoded data should be taken. As far as the profile is concerned, the initialization element is a bucket of octets. The profile gets to decide how they are interpreted. See RFC 3080 section 2.2.2. (In retrospect, it does seem a bit incongruous that initialization elements do not get headers, and thus do not get a MIME type. That would seem to impede a packet tracer's ability to display initialization elements properly, which is odd since we decided not to allow profiles to specify default MIME types precisely to help out packet tracers. Still, it does not seem to be a specification ambiguity.) > Unfortunately, the only solution I can come up with is to say that > the "profile" element contained within a "start" message may also > optionally have a "text-encoding" attribute, defaulting to "UTF-8", > specifying the text encoding of base64-encoded data. Does anyone > have a better solution? Your solution seems to be searching for a problem, and would appear to violate the standard. By my reading, a BEEP library should pass the initialization element to the application as octets, not as characters. (Or the application should pass in the character set it wants the BEEP library to use to decode the initialization element.) > > [...] > In RFC 3080, Section 2.3.1, all uses of "profile" in "greeting" > elements, and many uses of "profile" in "start" elements, make use > of the XML empty element notation, "". This is poor XML. [...] > For interoperability, the empty-element tag should be used, and > should only be used, for elements which are declared EMPTY. As noted in section 1.2 of REC-xml, "for interoperability" denotes a non-binding recommendation intended to help out ancient verifying SGML implementations. I don't think it's even worth nitpicking. > I believe that BEEP is vulnerable to SWS. RFC 3081 section 3.1.4 says: o each time a frame is received, a SEQ frame should be sent whenever the window size that will be sent is at least one half of the buffer space available to this channel; and, I believe this provides SWS avoidance. The section also references the parts of RFC 1122 which deal with flow control. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 09:33:06 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01847 for ; Tue, 30 Oct 2001 09:33:05 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UEQ4024642; Tue, 30 Oct 2001 06:26:04 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UEP2024630 for ; Tue, 30 Oct 2001 06:25:02 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01564; Tue, 30 Oct 2001 09:31:23 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA17323; Tue, 30 Oct 2001 09:31:23 -0500 (EST) Received: from error-messages.mit.edu (ERROR-MESSAGES.MIT.EDU [18.101.0.169]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA17147; Tue, 30 Oct 2001 09:31:21 -0500 (EST) Received: (from ghudson@localhost) by error-messages.mit.edu (8.9.3) id JAA15162; Tue, 30 Oct 2001 09:31:21 -0500 Message-Id: <200110301431.JAA15162@error-messages.mit.edu> To: Greg Hudson cc: beepwg@lists.beepcore.org, protocol@permabit.com Subject: Re: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) In-Reply-To: Your message of "Tue, 30 Oct 2001 01:52:47 EST." <200110300652.BAA32495@egyptian-gods.MIT.EDU> From: Greg Hudson Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Oct 2001 09:31:21 -0500 I wrote: > As far as the profile is concerned, the initialization element is a > bucket of octets. The profile gets to decide how they are > interpreted. See RFC 3080 section 2.2.2. And of course, that doesn't make sense, since the initialization element might not be base64-encoded, in which case it comes as characters, not bytes. So I think this really is ambiguous. I still don't think adding a text-encoding attribute is a valid answer for an implementation, though. A library could: * Pass the PCDATA of the initialization element back to the application (as characters), along with a flag saying whether encoding="base64" was specified. Let the application figure out what to do with that. * Accept a character set specification to be used to decode base64-encoded initialization elements; for non-encoded elements, just return the PCDATA as characters. Neither seems great. But the point is, given that the BEEP specification is ambiguous here, it is up to the profile to specify what an encoded and non-encoded initialization element mean. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 12:35:10 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08304 for ; Tue, 30 Oct 2001 12:35:09 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UHS3025529; Tue, 30 Oct 2001 09:28:03 -0800 (PST) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UHRt025517 for ; Tue, 30 Oct 2001 09:27:55 -0800 (PST) Received: from FATORA (dhcpd254 [64.168.10.254] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f9UHTNf01018; Tue, 30 Oct 2001 09:29:24 -0800 (PST) Message-ID: <06c801c16169$0e3354f0$fe0aa840@FATORA> From: "Marshall T. Rose" To: "Greg Hudson" Cc: , , "Marshall Rose" References: <200110301431.JAA15162@error-messages.mit.edu> Subject: Re: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Oct 2001 09:33:57 -0800 Content-Transfer-Encoding: 7bit > I wrote: > > As far as the profile is concerned, the initialization element is a > > bucket of octets. The profile gets to decide how they are > > interpreted. See RFC 3080 section 2.2.2. > > And of course, that doesn't make sense, since the initialization > element might not be base64-encoded, in which case it comes as > characters, not bytes. we can certainly update the spec, though i'd like to see a concrete proposal as to what the change is. perhaps a good solution is to add a new value for the encoding attribute that specifies that the piggyback is a MIME object that has been encoded (headers and all) with base64. for myself, the model i currently use is to undo the base64, if any, and then pass the piggyback as application/octet-stream to the profile engine... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 14:31:01 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12358 for ; Tue, 30 Oct 2001 14:31:01 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJO4026210; Tue, 30 Oct 2001 11:24:04 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UIae025873 for ; Tue, 30 Oct 2001 10:36:40 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 4B96B13A3D; Tue, 30 Oct 2001 13:43:00 -0500 (EST) To: "Marshall T. Rose" Cc: "Greg Hudson" , , , "Marshall Rose" Subject: Re: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) References: <200110301431.JAA15162@error-messages.mit.edu> <06c801c16169$0e3354f0$fe0aa840@FATORA> From: Jered Floyd In-Reply-To: <06c801c16169$0e3354f0$fe0aa840@FATORA> Message-ID: <87zo69as0b.fsf@questionably-configured.permabit.com> Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Oct 2001 13:43:00 -0500 "Marshall T. Rose" writes: > perhaps a good solution is to add a new value for the encoding attribute > that specifies that the piggyback is a MIME object that has been encoded > (headers and all) with base64. This is certainly plausible, however if that's the solution I wish we didn't have the "encoding" attribute on profile at all; the content could have been a MIME body in itself, with the same default text encoding and content transfer encoding as a normal BEEP+XML payload. Unfortunately, such a change would not be backwards compatible. Perhaps the additional encoding attribute should be "mime", indicating the content is a MIME document, and the "base64" attribute should be depricated in favor of "mime" with a Content-Transfer-Encoding: base64 header? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 14:32:39 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12424 for ; Tue, 30 Oct 2001 14:32:38 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJQ7026244; Tue, 30 Oct 2001 11:26:07 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UIgE025916 for ; Tue, 30 Oct 2001 10:42:14 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id F00DB13A3D; Tue, 30 Oct 2001 13:48:37 -0500 (EST) To: Greg Hudson Cc: beepwg@lists.beepcore.org, protocol@permabit.com Subject: Re: [BEEPwg] Underspecifications in RFC 3080? (profile content, SWS avoidance) References: <200110300652.BAA32495@egyptian-gods.MIT.EDU> From: Jered Floyd In-Reply-To: <200110300652.BAA32495@egyptian-gods.MIT.EDU> Message-ID: <87vggxarqy.fsf@questionably-configured.permabit.com> Lines: 23 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Oct 2001 13:48:37 -0500 > > I believe that BEEP is vulnerable to SWS. > > RFC 3081 section 3.1.4 says: > > o each time a frame is received, a SEQ frame should be sent whenever > the window size that will be sent is at least one half of the > buffer space available to this channel; and, > > I believe this provides SWS avoidance. The section also references > the parts of RFC 1122 which deal with flow control. This only fulfills the recipient's responsibilities to SWS avoidance. (RFC 11.22, Section 4.2.3.3.) I believe that RFC 3081 should also explicitly state the sender's responsibilities as well. (Section 4.2.3.4) While the above quote from RFC 3081 allows to recipient to discourage sends from the peer when little window space is available, nothing in the RFC discourages the sender from (in general) sending small payloads. The sender's responsibilities were important enough to mention in RFC 1122, and so I think they're important enough to mention in RFC 3081 as well. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 14:34:07 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12489 for ; Tue, 30 Oct 2001 14:34:06 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJRT026268; Tue, 30 Oct 2001 11:27:29 -0800 (PST) Received: from sanctioned-parts-list.permabit.com ([4.36.55.2]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UIu1025995 for ; Tue, 30 Oct 2001 10:56:01 -0800 (PST) Received: by sanctioned-parts-list.permabit.com (Postfix, from userid 1028) id 6A90FCC65; Tue, 30 Oct 2001 14:02:24 -0500 (EST) From: Chris Laas To: Jered Floyd Cc: beepwg@lists.beepcore.org, protocol@permabit.com Message-ID: <20011030140224.C14231@sanctioned-parts-list.permabit.com> Mail-Followup-To: Jered Floyd , beepwg@lists.beepcore.org, protocol@permabit.com References: <1f2f01c13b9c$92f91960$8d53cf3f@FATORA> <87snc1k938.fsf@questionably-configured.permabit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87snc1k938.fsf@questionably-configured.permabit.com>; from jered@permabit.com on Tue, Oct 30, 2001 at 12:09:15AM -0500 Subject: [BEEPwg] Re: Underspecifications in RFC 3080? (profile content, SWS avoidance) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Oct 2001 14:02:24 -0500 On Tue, Oct 30, 2001 at 12:09:15AM -0500, Jered Floyd wrote: > Consider the situation where content is provided, and the "encoding" > attribute has the value "base64". It is unclear to me, from the above > passage, in which character set the decoded data should be taken. The > intuitive answer is to claim that the decoded base64 data should be > taken to be in the same character set as the enclosing MIME body. I remain unconvinced that this is an ambiguity in the BEEP spec. If the "encoding" attribute does not have the value "base64", then the content's character set is specified by the MIME type of the enclosing message, and the content is passed to the application as characters. If the "encoding" attribute is "base64", then the content is simply a chunk of octets; it may be assumed to have the MIME type application/octet-stream if it's convenient. Where is the ambiguity? --Chris _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 14:35:47 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12553 for ; Tue, 30 Oct 2001 14:35:46 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJSp026292; Tue, 30 Oct 2001 11:28:51 -0800 (PST) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJC8026100 for ; Tue, 30 Oct 2001 11:12:08 -0800 (PST) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id CB16413A3D; Tue, 30 Oct 2001 14:18:31 -0500 (EST) To: Chris Laas Cc: beepwg@lists.beepcore.org, protocol@permabit.com References: <1f2f01c13b9c$92f91960$8d53cf3f@FATORA> <87snc1k938.fsf@questionably-configured.permabit.com> <20011030140224.C14231@sanctioned-parts-list.permabit.com> From: Jered Floyd In-Reply-To: <20011030140224.C14231@sanctioned-parts-list.permabit.com> Message-ID: <87lmhtaqd4.fsf@questionably-configured.permabit.com> Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] Re: Underspecifications in RFC 3080? (profile content, SWS avoidance) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Oct 2001 14:18:31 -0500 > If the "encoding" attribute is "base64", then the content is simply a > chunk of octets; it may be assumed to have the MIME type > application/octet-stream if it's convenient. Where is the ambiguity? This provides no opportunity for the character set of this base64-encoded initialization message to be specified, if it is to be interpreted as character data. My impression of the BEEP spec is that, much as MIME content transfer encodings, the "encoding" attribute should be transparent to the application such that proxies along the way may translate between content-preserving encodings. What you propose requires two distinct interfaces to an application using BEEP, one for encoding='none' which provides a character stream to the application, one for encoding='base64' which provides a byte stream with no associated metadata. This is poor design. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Oct 30 14:36:52 2001 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12593 for ; Tue, 30 Oct 2001 14:36:52 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJTi026326; Tue, 30 Oct 2001 11:29:44 -0800 (PST) Received: from sanctioned-parts-list.permabit.com ([4.36.55.2]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id f9UJJY026160 for ; Tue, 30 Oct 2001 11:19:34 -0800 (PST) Received: by sanctioned-parts-list.permabit.com (Postfix, from userid 1028) id D6815CC65; Tue, 30 Oct 2001 14:25:57 -0500 (EST) From: Chris Laas To: Jered Floyd Cc: beepwg@lists.beepcore.org, protocol@permabit.com Message-ID: <20011030142557.D14231@sanctioned-parts-list.permabit.com> Mail-Followup-To: Jered Floyd , beepwg@lists.beepcore.org, protocol@permabit.com References: <1f2f01c13b9c$92f91960$8d53cf3f@FATORA> <87snc1k938.fsf@questionably-configured.permabit.com> <20011030140224.C14231@sanctioned-parts-list.permabit.com> <87lmhtaqd4.fsf@questionably-configured.permabit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <87lmhtaqd4.fsf@questionably-configured.permabit.com>; from jered@permabit.com on Tue, Oct 30, 2001 at 02:18:31PM -0500 Subject: [BEEPwg] Re: Underspecifications in RFC 3080? (profile content, SWS avoidance) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Tue, 30 Oct 2001 14:25:57 -0500 On Tue, Oct 30, 2001 at 02:18:31PM -0500, Jered Floyd wrote: > > > If the "encoding" attribute is "base64", then the content is simply a > > chunk of octets; it may be assumed to have the MIME type > > application/octet-stream if it's convenient. Where is the ambiguity? > > This provides no opportunity for the character set of this > base64-encoded initialization message to be specified, if it is to be > interpreted as character data. My impression of the BEEP spec is > that, much as MIME content transfer encodings, the "encoding" > attribute should be transparent to the application such that proxies > along the way may translate between content-preserving encodings. While it may have been your impression, it seems clear to me that the spec says something entirely different. > What you propose requires two distinct interfaces to an application > using BEEP, one for encoding='none' which provides a character stream > to the application, one for encoding='base64' which provides a byte > stream with no associated metadata. This is poor design. Well, I would not claim that this is an example of good design. However, I would claim that the spec is unambiguous, and that, as specified, BEEP cannot allow this interface to be transparent to the application. If you wanted the interface you outline above, you'd technically have to change the spec (as has been pointed out, it's certainly an option). On the other hand, the "require encoding=base64 contents to be MIME-encoded" solution could easily be implemented as a thin layer atop BEEP; it doesn't seem entirely odious to me that this feature could be handled at the application layer. --Chris _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg