RE: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and Encryption Donation

No we didn't specifically look at this one but it sounds like a great
topic for those working on this proposal!

In particular, maybe if we believe this is going to change over time or
want to support internationalization concerns then the "encoding"
directive may be desirable.

Jay

===================================
Jay Lawrence
Senior Architect
Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================

> -----Original Message-----
> From: Marcus Harnisch [mailto:marcus_harnisch@mint-tech.com]
> Sent: Thursday, May 20, 2004 12:49 PM
> To: Jay Lawrence
> Cc: vhdl-200x@eda.org; vhdl-200x-ft@eda.org
> Subject: RE: [vhdl-200x-ft] Re: [vhdl-200x] IP Protection and
> Encryption Donation
>
>
> Hi Jay,
>
> Jay Lawrence writes:
> > Because I'm basically lazy and google is faster than my
> math, I found
> > the following
> >
> > http://www.geocities.com/herong_yang/data/uuencode.html
> >
> > It contains a table of the printable range in uuencoded
> text and you are
> > correct it does not contain lower case letters. The example should
> > probably be updated to have actual encrypted/encoded text.
>
> Do you know whether BASE64 was considered as encoding scheme and
> whether uuencode was preferred?
>
> BASE64 is well standardized and generally used in MIME email
> (http://www.mhonarc.org/~ehood/MIME/2045/rfc2045.html#6.8) to encode
> binary data. There are plenty of codecs floating around.
>
> I remember reading this in the mmencode(1) man-page:
>
> RATIONALE
>
> Mimencode is intended to be a replacement for uuencode for mail
> and news use. The reason is simple: uuencode doesn't work very
> well in a number of circumstances and ways. In particular,
> uuencode uses characters that don't translate well across all mail
> gateways (particularly ASCII <-> EBCDIC gateways). Also, uuencode
> is not standard -- there are several variants floating around,
> encoding and decoding things in different and incompatible ways,
> with no "standard" on which to base an implementation. [...]
>
>
> Best regards,
> Marcus
>
> --
> Marcus Harnisch | Mint Technology, a division
> of LSI Logic
> marcus_harnisch@mint-tech.com | 200 West Street, Waltham, MA 02431
> Tel: +1-781-768-0772 | http://www.lsilogic.com
>
>
Received on Thu May 20 10:06:56 2004