Subject: User Petition on Standards to Netscape and Microsoft

From: "Williams, Herb" <[email-masked]>
Date: Tue, 30 Dec 1997 20:57:43 -0500

>   Gentlemen:
>  
>   With talk of reverting to BNF-style syntax from which
> encoder/decoders
>   cannot be automatically generated, I fear we are being pushed back
> to 
>   the stone age. The ability to make use of ASN.1 compilers is to me
> the
>   primary reason for even thinking of using ASN.1. Having a notation
>   that allows a compiler to generate my data structures as well as
> complete
>   encoder/decoders makes a world of difference between being able to
> get
>   portable, reliable and fully interoperable code completed as quickly
> as
>   possible versus my people having to dwell on the details of encoding
> and
>   decoding. As a District Manager, directing software development, I
> prefer
>   that my teams spend their time being productive rather than wielding
> 
>   stone axes.
>  
>   In terms of productivity, the 1994 ASN.1 version is a definite
> improvement
>   over the 1988 version, not just because of the bug fixes, but
> because it 
>   makes much clearer what needs to be implemented, and it makes
> possible
>   smaller, simpler and quicker implementations. Using the 1988 version
> of
>   ASN.1 precludes everyone  from realizing and enjoying the
> productivity
>   gains possible when the syntax is written using the 1994 notation.
> On the other 
>   hand, those  with 1988 tools can reduce the ASN.1 to a more
> primitive form suitable
>   for processing by such tools, as was done by some in the case of
> SET, and
>   other protocols.
>  
>   Herb Williams - District Mgr.
>   AT&T Billing Systems Development  
>

---

From: Bancroft Scott <[email-masked]>
Date: Fri, 2 Jan 1998 11:48:43 -0500 (EST)

Christian Huitema wrote:

> > > Numbers are encoded in the minimum number of bits, and multiple values
> > > can be packed into a single byte.  For example, if a value is 
> > > constrained to be between 100 and 107, the encoded form will only use 
> > > three bits.  
> > 
> > I'll admit to not knowing much about PER, but I'm curious: what 
> > happens when, in the future, that value becomes a number from 100 to 
> > 108?  

You would constrain the type to between 100 and 107 only if you intend for
the range to never change, similar to how you would define it as an
INTEGER only if you intend for the type to never change to a SEQUENCE or
some other type.  If you want the flexibility of later increasing the set
of values that can be encoded then you would not constrain the INTEGER
type at all, in which case the value is encoded with a length prefix and
can carry any value, or you can indicate that the constraint is
extensible, meaning that if its value lies within 100-107 it gets encoded
very efficiently, and if the value is outside this range it gets encoded
with a length prefix.  Note though that although the value 108 is not
encoded as compactly as values in the range 100-107, its encoding is still
more efficient than than in BER since no tag is encoded. 

> The field size increases from 3 to 4 bits. 

No.  The *encoder* gets a constraint violation, for it
is being asked to encode a value that is not allowed by the range.

> This is the Achille's heel
> of PER.  It has all the good points that Simon mention,which makes it
> comparable to XDR in terms of complexity, in a more compact way.
> However, it can only be decompiled if the receiver has a full knowledge
> of the syntax used by the sender. 

No.  The sender and receiver can have different syntaxes, so long as one
is an extension of the other. 

> One could argue that the full knowledge is also required in XDR, but PER
> pushes this one step further.  One shall not only specify that this type
> is coded as an integer -- one must also specify the range of values,
> and changing the range changes the encoding.

No.  You specify the range of values only if you know what they are ahead
of time and are certain that they will not change for this version of your
protocol. 

> Similarly, there is an extension facility to add components to Sequences
> in a protocol revision, but the only thing PER can do is detect that the
> extension was used.  In cannot do the common trick of just ignoring the
> added elements -- something that the IETF protocols such as RFC-822, or
> HTTP use and abuse.

No.  The PER extension facility does allow you to detect when extensions
are in use and allows you to ignore the added elements.

--------------------------------------------------------------------------
Bancroft Scott                                Toll Free    :1-888-OSS-ASN1
Open Systems Solutions, Inc.                  International:1-609-987-9073
[email-masked]                                  Tech Support :1-732-249-5107
http://www.oss.com                            Fax          :1-732-249-4636

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 6 Jan 1998 11:47:20 -0800

Hi - 

This discussion of time representation sounds like a step-by-step
replay of the reasoning used to produce the time representation
defined in ISO DIS 10164-20 | ITU-T X.743, Time Management Function.

By the way, the CMIP specification has still not been re-cast to
ASN.1:1994;  there was a window of oppurtunity when the spec was
republished last year, integrating various technical corrigenda.

 -------------------------- NEW ADDRESS! -------------------------------
 Randy Presuhn           Email: [email-masked]      http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Peter Deutsch <[email-masked]>
Date: Wed, 7 Jan 1998 15:08:31 -0500

[ You wrote: ]

}    Date: Tue, 06 Jan 1998 11:16:39 -0800
}    From: "sanjay kulkarni" <[email-masked]>
} 
}    This approach though very simple is not without its problems. Remember
}    time_t
}    gets into trouble in 2036. (Assuming 32 bits for an integer).
} 
} If we're still using 32 bit OS's by the year 2036.....

DANGER WILL ROBINSON!!

hmmm...

	2036 - 1998 = 38 years

	1998 - 38 years = 1960

What are the chances that there is a technical assumption
made in 1960 that is affecting us today that was justified
by exactly that line of reasoning?? It does predate the
System/360, but perhaps something to do with the Fortran
compilers then in use? Cobol? Eight bit bytes? There are
certainly a few...

Now, in 1960 I was watching cartoons, so I can't be held
personally responsible for anything done back then, but
this email thread is being archived, so in 2036 somebody
may dig this out and we'd better not leave such evidence
of our assumptions lying around!  :-)

				- peterd

-- 
------------------------------------------------------------------------------
     Peter Deutsch,                                   (514) 875-8611  (phone)
  Bunyip Information Systems Inc.                     (514) 875-8134  (fax)
    <[email-masked]>                               http://www.bunyip.com

   "Did you ever walk in a room and forget why you walked in? I think
   that's how dogs spend their lives."
                                                  --Sue Murphy
-----------------------------------------------------------------------------