W3C home > Mailing lists > Public > ietf-discuss@w3.org > April 2001

Re: Two new drafts: Multipart/Interleaved and Application /BatchBeep

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 24 Apr 2001 15:24:41 -0400
Message-Id: <200104241924.PAA0000070099@torque.pothole.com>
To: discuss@apps.ietf.org

And, of course, none of this has to do with ASN.1 but rather to do
with BER, PER, DER, etc., i.e., with particular ASN.1 Encoding
Rules. One could define a VER (Verbose Encoding Rules) for ASN.1 which
was worse than any of the compared alternatives. Similarly, one can
define more compact XML encoding rules, e.g., WAP's Binary XML.

Donald

From:  Keith Moore <moore@cs.utk.edu>
Message-Id:  <200104241917.PAA17760@astro.cs.utk.edu>
X-URI:  http://www.cs.utk.edu/~moore/
To:  Jacob Palme <jpalme@dsv.su.se>
cc:  Keith Moore <moore@cs.utk.edu>, discuss@apps.ietf.org
In-reply-to:  Your message of "Tue, 24 Apr 2001 20:29:50 +0200."
	                  <p05010407b70b755d01a3@[130.237.150.141]> 
Date:  Tue, 24 Apr 2001 15:17:54 -0400
Sender:  moore@cs.utk.edu
List-Unsubscribe:  <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
>> >there's more than one kind of typing.  in your ASN.1 examples, you don't
>> >appear to include the "name" of each datum, whereas in your ABNF and XML
>> >examples, you do.
>> 
>> The main principle of efficient coding of protocols is to only send 
>> the information which varies over time. Information which is static, 
>> like the names of the fields, is either suppressed or compacted very 
>> strongly.  It is this compacting of this information which is a main 
>> reason why the ASN.1 encoding got so compact. 
>
>This isn't a feature of ASN.1.  It's a feature of encoding the 
>field names implicitly via their position in the data stream vs. 
>encoding them explicitly with tags.  ASN.1 can do this either
>way.  For instance, SNMP uses ASN.1 but tags each datum with an OID.
>
>You can also do positional encoding with RFC 822 headers or XML.
>It's just a question of how much of the syntax of the underlying
>data that you expose/export into the outer presentation syntax.
>
>> The disadvantage with this, of course, is that the encoded date is 
>> much more difficult to read for a human not using a special program.
>
>That's only one disadvantage of positional encoding.  You're making
>assumptions about which data is static and which data isn't static
>that aren't even appropriate for the examples that you cite, much less 
>in general.
>
>> Did you also look at my comparison between RFC822 and XML
>> 
>> RFC822 example:
>>      From: Father Christmas <fchristmas@northpole.arctic>
>> 
>> XML encoding of the same information:
>> 
>>      <from>
>>        <user-friendly-name>Father Christmas</user-friendly-name>
>>        <e-mail-address>
>>          <localpart>fchristmas</localpart>
>>          <domainpart>
>>            <domainelement>northpole</domainelement>
>>            <domainelement>arctic</domainelement>
>>        </domainpart>
>>      </from>
>> 
>> The XML encoding uses five times as many characters. 
>
>you could have as easily said:
>
><from>Father Christmas &#60;fchristmas@northpole.arctic&#62;</from>
>
>and that would have been a more accurate comparison.  The XML version
>uses a few more characters, but it's not a huge difference overall. 
>
>Keith
Received on Tuesday, 24 April 2001 15:26:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:38:01 UTC