From mailman-bounces@ietf.org Fri Oct 1 05:45:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11272 for ; Fri, 1 Oct 2004 05:45:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDK6z-0002wm-7Y for discuss-web-archive@ietf.org; Fri, 01 Oct 2004 05:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJTb-0004g4-H5 for discuss-web-archive@ietf.org; Fri, 01 Oct 2004 05:13:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: apps.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: discuss-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:02:22 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your apps.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@apps.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@apps.ietf.org. Thanks! Passwords for discuss-web-archive@ietf.org: List Password // URL ---- -------- discuss@apps.ietf.org axuhzo https://www1.ietf.org/mailman/options/discuss/discuss-web-archive%40ietf.org From discuss-bounces@apps.ietf.org Mon Oct 11 08:59:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03658 for ; Mon, 11 Oct 2004 08:59:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzw9-0007V5-KP for discuss-web-archive@ietf.org; Mon, 11 Oct 2004 09:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzjf-0004ek-QC; Mon, 11 Oct 2004 08:57:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGzhp-0004CL-JH for discuss@megatron.ietf.org; Mon, 11 Oct 2004 08:55:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03496 for ; Mon, 11 Oct 2004 08:55:12 -0400 (EDT) Received: from cliffie.verisignlabs.com ([65.201.175.9] helo=mail.verisignlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGzsM-0007QZ-Tu for discuss@apps.ietf.org; Mon, 11 Oct 2004 09:06:07 -0400 Received: from dul1shollenbl1 ([::ffff:216.168.239.87]) (AUTH: LOGIN shollenb, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by mail.verisignlabs.com with esmtp; Mon, 11 Oct 2004 08:54:41 -0400 id 004202D0.416A8291.000067F3 From: "Scott Hollenbeck" To: discuss@apps.ietf.org Subject: Apps Area Agenda Topics? Date: Mon, 11 Oct 2004 08:55:03 -0400 Message-ID: <7468147AEE316B41B3B55152959CE2181290B3@dul1wnexm05.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@ietf.org Errors-To: discuss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Does anyone have anything that they'd like to talk about at the open apps-area meeting at IETF-61? Please let Ted and me know so we can fit you into the agenda. -Scott- From discuss-bounces@apps.ietf.org Fri Oct 22 10:48:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11074 for ; Fri, 22 Oct 2004 10:48:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0vc-0008At-C8 for discuss-web-archive@ietf.org; Fri, 22 Oct 2004 11:02:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL0di-0008Ir-JE; Fri, 22 Oct 2004 10:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL0Vl-0004di-Uf for discuss@megatron.ietf.org; Fri, 22 Oct 2004 10:35:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09383 for ; Fri, 22 Oct 2004 10:35:18 -0400 (EDT) Received: from almso1.att.com ([192.128.167.69] helo=almso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0iZ-0007hT-A2 for discuss@apps.ietf.org; Fri, 22 Oct 2004 10:48:35 -0400 Received: from maillennium.att.com ([135.25.114.99]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id i9MEYikS000794 for ; Fri, 22 Oct 2004 10:34:45 -0400 Received: from [135.210.105.26] (unknown[135.210.105.26](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20041022143554gw100goggme> (Authid: tony); Fri, 22 Oct 2004 14:35:54 +0000 Message-ID: <41791A81.4040304@att.com> Date: Fri, 22 Oct 2004 10:34:41 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: discuss@apps.ietf.org, Joachim.Strombergson@InformAsic.com, triad@df.lth.se, paf@cisco.com Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt References: <200410211950.PAA13139@ietf.org> In-Reply-To: <200410211950.PAA13139@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@ietf.org Errors-To: discuss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Nits: Consider: o name: A compulsory string of arbitrary length used by any interested party to identify the specific Block. If your dump consists of a single , the name of that single block will often be redundant with the name of the dump. Look at your own examples and consider what 'name="Code"' really adds. Make name optional for . Consider: o word_size: A compulsory 64 bit hexadecimal value representing the number of Bytes (the width) of one Word of the data. If this is not given, the Word width is assumed to be 1, i.e. one Byte. You say compulsory, but then talk about it defaulting to 1 if not present. Change "compulsory" to "optional". I still feel that the length and checksum should be optional. s/recieveing/receiving/ Consider: o The words inside a Dump may be in the native endianness of the consumer, since this represents raw memory. However implementers may choose to store also this data in a Big Endian format for ease of reading: Big Endian values are more human-readable than Little Endian ones. Should there be an optional "endness" attribute (defaulting to Big Endian, of course) for those times when the user has chosen a different ordering. Possible values might be endness=big, endness=little, and endness=native. Consider: whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)+ hexdigit ::= [0-9A-Fa-f] hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)* I believe there's a shift-shift error here. The + should be removed from whitespace -- it's supposed need is covered by the * in hexbytes. Consider: A parser reading in an SHF file should silently ignore any other characters that (by mistake) appear in any of these elements or The word "A" is indented incorrectly. Consider: Also note that "whitespace" has no semantic meaning, it is only valid for the reason of improving the human readability of the Dump. Change the "," to a ";". Consider: Word_size is optional and should be marked #IMPLIED. Of course, I also feel that name, length and checksum should also be marked #IMPLIED, leaving only address as #REQUIRED. Consider adding this example: The next example is the simplest SHF Dump allowed: 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a Regards, Tony Hansen tony@att.com From discuss-bounces@apps.ietf.org Fri Oct 22 11:32:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14268 for ; Fri, 22 Oct 2004 11:32:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1bz-0000XG-WB for discuss-web-archive@ietf.org; Fri, 22 Oct 2004 11:45:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1NF-0000uX-ON; Fri, 22 Oct 2004 11:30:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL1HA-00077Z-Tc for discuss@megatron.ietf.org; Fri, 22 Oct 2004 11:24:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13407 for ; Fri, 22 Oct 2004 11:24:16 -0400 (EDT) Received: from igloo.df.lth.se ([194.47.250.47] helo=df.lth.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL1Ty-0000Lt-9p for discuss@apps.ietf.org; Fri, 22 Oct 2004 11:37:34 -0400 Received: from www.df.lth.se (frodo.df.lth.se [194.47.250.40]) by df.lth.se (8.13.1/8.13.1) with ESMTP id i9MFNwZJ009906; Fri, 22 Oct 2004 17:24:02 +0200 (CEST) Received: from 194.237.142.21 (SquirrelMail authenticated user triad); by www.df.lth.se with HTTP; Fri, 22 Oct 2004 17:24:02 +0200 (CEST) Message-ID: <34514.194.237.142.21.1098458642.squirrel@194.237.142.21> In-Reply-To: <41791A81.4040304@att.com> References: <200410211950.PAA13139@ietf.org> <41791A81.4040304@att.com> Date: Fri, 22 Oct 2004 17:24:02 +0200 (CEST) Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt From: "Linus Walleij" To: "Tony Hansen" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 8bit Cc: discuss@apps.ietf.org, paf@cisco.com, triad@df.lth.se, joachim.strombergson@informasic.com X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@ietf.org Errors-To: discuss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 8bit Thanks for your comments Tony, clear as always. > If your dump consists of a single , the name of that single block > will often be redundant with the name of the dump. Look at your own > examples and consider what 'name="Code"' really adds. Make name optional > for . Whereas for a while I had rewritten the draft to make almost everything optional, my fellow cowriters vote me down on that. The main reason was that things not compulsory are seldom implemented. Joachim and Patrik will surely comment on this at some length... > Consider: > o word_size: A compulsory 64 bit hexadecimal value representing the > number of Bytes (the width) of one Word of the data. If this is > not given, the Word width is assumed to be 1, i.e. one Byte. > > You say compulsory, but then talk about it defaulting to 1 if not > present. Change "compulsory" to "optional". Oops a leftover from the "everything optional" version. Good you saw it. > I still feel that the length and checksum should be optional. I could accept it, perhaps with the exception of checksum, which is very important for verifying that you actually get what you request. We must battle this one out i think... > Should there be an optional "endness" attribute (defaulting to Big > Endian, of course) for those times when the user has chosen a different > ordering. Possible values might be endness=big, endness=little, and > endness=native. Hm. Will this not be apparent in the application context anyway? What practical purpose does it serve? > Consider: > whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)+ > hexdigit ::= [0-9A-Fa-f] > hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)* > > I believe there's a shift-shift error here. The + should be removed from > whitespace -- it's supposed need is covered by the * in hexbytes. You're right. Fixing it. > Consider: > A parser reading in an SHF file should silently ignore any other > characters that (by mistake) appear in any of these elements or > > The word "A" is indented incorrectly. Yep. > Consider: > Also note that "whitespace" has no semantic meaning, it > is only valid for the reason of improving the human readability of > the Dump. > > Change the "," to a ";". Yep. > Word_size is optional and should be marked #IMPLIED. Of course, I also > feel that name, length and checksum should also be marked #IMPLIED, > leaving only address as #REQUIRED. See above... > Consider adding this example: > > The next example is the simplest SHF Dump allowed: > > > > 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72 > 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a > > Similar to the ones we saw before... Yes it is elegant, we must now decide if it is practical. :-) Linus From discuss-bounces@apps.ietf.org Thu Oct 28 23:04:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00160 for ; Thu, 28 Oct 2004 23:04:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNNHm-0001yi-0G for discuss-web-archive@ietf.org; Thu, 28 Oct 2004 23:18:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNMX8-00052E-OH; Thu, 28 Oct 2004 22:30:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNHLN-0004rr-9X for discuss@megatron.ietf.org; Thu, 28 Oct 2004 16:58:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10950 for ; Thu, 28 Oct 2004 16:57:59 -0400 (EDT) Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNHZV-0003L3-JV for discuss@apps.ietf.org; Thu, 28 Oct 2004 17:12:38 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 880CC38021; Thu, 28 Oct 2004 22:57:27 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6BA4637E56; Thu, 28 Oct 2004 22:57:27 +0200 (CEST) Received: from [192.168.0.10] (h110n2fls11o1005.telia.com [217.211.199.110]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0A03137E43; Thu, 28 Oct 2004 22:57:26 +0200 (CEST) Message-ID: <41815D39.30102@ludd.ltu.se> Date: Thu, 28 Oct 2004 22:57:29 +0200 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041003 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Walleij Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt References: <200410211950.PAA13139@ietf.org> <41791A81.4040304@att.com> <34514.194.237.142.21.1098458642.squirrel@194.237.142.21> In-Reply-To: <34514.194.237.142.21.1098458642.squirrel@194.237.142.21> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 28 Oct 2004 22:30:29 -0400 Cc: discuss@apps.ietf.org, paf@cisco.com, Tony Hansen X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@ietf.org Errors-To: discuss-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Aloha! Linus Walleij wrote: >>If your dump consists of a single , the name of that single bloc= k >>will often be redundant with the name of the dump. Look at your own >>examples and consider what 'name=3D"Code"' really adds. Make name optio= nal >>for . >=20 > Whereas for a while I had rewritten the draft to make almost everything > optional, my fellow cowriters vote me down on that. The main reason > was that things not compulsory are seldom implemented. >=20 > Joachim and Patrik will surely comment on this at some length... Yes. My experience with optional thingys is bad in two ways: (1) They add loads of complexity for the parser/protocol FSM. Agreed=20 this is usually not a problem if you work on 32-bit++ computer systems,=20 but when worling in cramped embedded systems then protocols with lots of=20 optionals is a big hassle. And the way I see it, SHF is a typical=20 protocol to implement in this type of environment. I can clearly see=20 applications for it there. (2) Optionals don't get implemented. For many reasons (see (1) for one=20 of them), people tend to implement what they MUST implement and leave=20 the icing on the cake for some future day when they need it. This=20 situation does not improve interoperability. I can agree with you comment Tom that for dumps that have one block, the=20 name _might_ not add much. OTOH, after seeing the talent and ingenuity=20 people can show when naming files just to save a character, having a=20 compulsory name-field might just be the thing needed to decipher a dump. If it bothers you, just define the name to "". >>I still feel that the length and checksum should be optional. >=20 > I could accept it, perhaps with the exception of checksum, which is > very important for verifying that you actually get what you request. > We must battle this one out i think... The cheksum SHOULD/MUST be mandatory. Not only for parsing hassle=20 reasons but more importantly that all other dump formats have had=20 checksums and are used to check the integrity. I have a hard time to see=20 people starting to use a new dump format that lacks this function. Also, in general more and more protocols/formats contain integrity=20 checks due to increasing need for them. A data storage/transport format=20 without an integrity check in 2004 looks to me like an incomplete format. Doing the check is not a big isse in terms of execution. The main=20 problem is memory where SHA-1 eats up a bit more than 512 Bytes, but=20 otherwise it can be very fast on even small 8-bit MCUs. The argument for the length field is similar to the checksum: Cumbersome=20 to have optionals, risks adding interoperability tests, other dump=20 format contains basic sanity checks/info on the name. >> >> >> 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72 >> 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a >> >> >=20 >=20 > Similar to the ones we saw before... Yes it is elegant, we must now > decide if it is practical. :-) Add a checksum and length and it would be fine with me. --=20 Med v=E4nlig h=E4lsning, Cheers! Joachim Str=F6mbergson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Joachim Str=F6mbergson - ASIC designer, nice to *cute* animals. snail: phone: mail & web: =D6stra Eriksbergsgatan 74 +46 31 - 12 14 01 watchman@ludd.ltu.s= e 417 63 G=F6teborg +46 733 75 97 02 www.ludd.luth.se/~watc= hman =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D From discuss-bounces@apps.ietf.org Fri Oct 29 12:59:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15506 for ; Fri, 29 Oct 2004 12:59:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNaK3-0003Qd-Nw for discuss-web-archive@ietf.org; Fri, 29 Oct 2004 13:13:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZzg-0006A4-12; Fri, 29 Oct 2004 12:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNZlU-0005Pb-Ac for discuss@megatron.ietf.org; Fri, 29 Oct 2004 12:38:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13781 for ; Fri, 29 Oct 2004 12:38:09 -0400 (EDT) Received: from igloo.df.lth.se ([194.47.250.47] helo=df.lth.se) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNZzn-0002uZ-84 for discuss@apps.ietf.org; Fri, 29 Oct 2004 12:52:59 -0400 Received: from igloo.df.lth.se (localhost [127.0.0.1]) by df.lth.se (8.13.1/8.13.1) with ESMTP id i9TGbwoJ022623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Oct 2004 18:37:58 +0200 (CEST) Received: from localhost (triad@localhost) by igloo.df.lth.se (8.13.1/8.13.1/Submit) with ESMTP id i9TGbwLa022620 for ; Fri, 29 Oct 2004 18:37:58 +0200 (CEST) X-Authentication-Warning: igloo.df.lth.se: triad owned process doing -bs Date: Fri, 29 Oct 2004 18:37:58 +0200 (CEST) From: Linus Walleij To: discuss@apps.ietf.org Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA13781 X-BeenThere: discuss@apps.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: general discussion of application-layer protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: discuss-bounces@ietf.org Errors-To: discuss-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable My colleagues have trouble getting their mail through to apps. Here is a=20 forwarded message from one of the authors. Linus Walleij ---------- Forwarded message ---------- Date: Thu, 28 Oct 2004 22:57:29 +0200 From: Joachim Str=F6mbergson Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt Aloha! Linus Walleij wrote: >> If your dump consists of a single , the name of that single blo= ck >> will often be redundant with the name of the dump. Look at your own >> examples and consider what 'name=3D"Code"' really adds. Make name opti= onal >> for . >=20 > Whereas for a while I had rewritten the draft to make almost everything > optional, my fellow cowriters vote me down on that. The main reason > was that things not compulsory are seldom implemented. >=20 > Joachim and Patrik will surely comment on this at some length... Yes. My experience with optional thingys is bad in two ways: (1) They add loads of complexity for the parser/protocol FSM. Agreed this= is=20 usually not a problem if you work on 32-bit++ computer systems, but when=20 worling in cramped embedded systems then protocols with lots of optionals= is a=20 big hassle. And the way I see it, SHF is a typical protocol to implement = in=20 this type of environment. I can clearly see applications for it there. (2) Optionals don't get implemented. For many reasons (see (1) for one of= =20 them), people tend to implement what they MUST implement and leave the ic= ing on=20 the cake for some future day when they need it. This situation does not i= mprove=20 interoperability. I can agree with you comment Tom that for dumps that have one block, the = name=20 _might_ not add much. OTOH, after seeing the talent and ingenuity people = can=20 show when naming files just to save a character, having a compulsory name= -field=20 might just be the thing needed to decipher a dump. If it bothers you, just define the name to "". >> I still feel that the length and checksum should be optional. >=20 > I could accept it, perhaps with the exception of checksum, which is > very important for verifying that you actually get what you request. > We must battle this one out i think... The cheksum SHOULD/MUST be mandatory. Not only for parsing hassle reasons= but=20 more importantly that all other dump formats have had checksums and are u= sed to=20 check the integrity. I have a hard time to see people starting to use a n= ew=20 dump format that lacks this function. Also, in general more and more protocols/formats contain integrity checks= due=20 to increasing need for them. A data storage/transport format without an=20 integrity check in 2004 looks to me like an incomplete format. Doing the check is not a big isse in terms of execution. The main problem= is=20 memory where SHA-1 eats up a bit more than 512 Bytes, but otherwise it ca= n be=20 very fast on even small 8-bit MCUs. The argument for the length field is similar to the checksum: Cumbersome = to=20 have optionals, risks adding interoperability tests, other dump format co= ntains=20 basic sanity checks/info on the name. >> >> >> 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72 >> 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a >> >> >=20 >=20 > Similar to the ones we saw before... Yes it is elegant, we must now > decide if it is practical. :-) Add a checksum and length and it would be fine with me. --=20 Med v=E4nlig h=E4lsning, Cheers! Joachim Str=F6mbergson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Joachim Str=F6mbergson - ASIC designer, nice to *cute* animals. snail: phone: mail & web: =D6stra Eriksbergsgatan 74 +46 31 - 12 14 01 watchman@ludd.ltu.s= e 417 63 G=F6teborg +46 733 75 97 02 www.ludd.luth.se/~watc= hman =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D