Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt (fwd)

From: Linus Walleij <[email-masked]>
Date: Fri, 29 Oct 2004 18:37:58 +0200 (CEST)

My colleagues have trouble getting their mail through to apps. Here is a 
forwarded message from one of the authors.

Linus Walleij

---------- Forwarded message ----------
Date: Thu, 28 Oct 2004 22:57:29 +0200
From: Joachim Strömbergson <[email-masked]>
Subject: Re: I-D ACTION:draft-strombergson-shf-02.txt

Aloha!

Linus Walleij wrote:
>> If your dump consists of a single <block>, 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 <block>.
> 
> 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...

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 
usually not a problem if you work on 32-bit++ computer systems, but when 
worling in cramped embedded systems then protocols with lots of optionals is a 
big hassle. And the way I see it, SHF is a typical protocol to implement in 
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 
them), people tend to implement what they MUST implement and leave the icing on 
the cake for some future day when they need it. This situation does not improve 
interoperability.

I can agree with you comment Tom that for dumps that have one block, the name 
_might_ not add much. OTOH, after seeing the talent and ingenuity people can 
show when naming files just to save a character, having a 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.
> 
> 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 
more importantly that all other dump formats have had checksums and are used to 
check the integrity. I have a hard time to see people starting to use a new 
dump format that lacks this function.

Also, in general more and more protocols/formats contain integrity checks due 
to increasing need for them. A data storage/transport format 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 problem is 
memory where SHA-1 eats up a bit more than 512 Bytes, but otherwise it can be 
very fast on even small 8-bit MCUs.

The argument for the length field is similar to the checksum: Cumbersome to 
have optionals, risks adding interoperability tests, other dump format contains 
basic sanity checks/info on the name.

>>    <dump name="Simplest SHF example">
>>      <block address="0400">
>>          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
>>      </block>
>>    </dump>
> 
> 
> 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.

-- 
Med vänlig hälsning, Cheers!

Joachim Strömbergson
============================================================================
Joachim Strömbergson - ASIC designer, nice to *cute* animals.
     snail:                  phone:                     mail & web:
Östra Eriksbergsgatan 74  +46 31 - 12 14 01         [email-masked]
417 63 Göteborg           +46 733 75 97 02       www.ludd.luth.se/~watchman
============================================================================