* Pieter Hintjens p...@imatix.com [140424 08:49]:
Hi Marvin,
Thanks for the suggestions. I've also wanted to fix some of the
character choices in Z85. Why don't we make a V2 spec with your
changes?
The process is: fork the RFC, make the necessary changes, send a pull
request to the RFC
On Thu, Apr 24, 2014 at 3:49 PM, Marvin Renich m...@renich.org wrote:
I did not see your response right away because I am not subscribed;
please CC me in responses.
:-( Not a simple thing, requires laborious copy/paste, not practical
on a mobile phone. Maybe you would subscribe to the list?
[I am not subscribed; please CC me in responses]
I was looking to ASCII-encode binary values to be saved as HTTP cookies,
and I came across Z85 (as well as Adobe's Ascii85). I disqualified
Ascii85 because the encoding character set includes characters not
allowed in cookies. I like Z85, but it
Pieter, I appreciate your overall rationale, but there seems to be a gap in
the explanation and that's the reasoning for which 23 of the 33
non-alphanumeric printable ASCII characters to include.
As far as I can see, you've disqualified single and double quotes and
probably backslashes. That
On Wed, Jul 10, 2013 at 1:02 PM, Peter Taylor pe...@vidavia.com wrote:
As far as I can see, you've disqualified single and double quotes and
probably backslashes. That still leaves free choice of 7 other characters to
exclude. Was that choice arbitrary, or did you use additional criteria? If
Le 29/06/2013 19:32, Pieter Hintjens a écrit :
Correct, it's only for source code and config files and perhaps
sending by email.
Yes, ascii85 is MIME compatible : http://en.wikipedia.org/wiki/Ascii85
___
zeromq-dev mailing list
I'll explain the reasons for creating Z85.
The first time I needed to use Curve keys, it broke. This was in CZMQ
where we generate the socket options test cases. Here's what I wanted
to put into my model:
option name = curve_publickey type = blob mode = rw
test = PUB
Correct, it's only for source code and config files and perhaps
sending by email.
For email you would always use Base64 , there is no efficiency gain due to
the header costs and every system uses it.
For source and config , it would only apply to older languages , most
modern languages have all
On 07/01/2013 11:38 AM, Pieter Hintjens wrote:
I'll explain the reasons for creating Z85.
I still don't get it.
First, AFAIK base85 is not compatible with XML (for config files.)
Second, why should ZMQ_CURVE_SECRETKEY use any encoding at all? Instead
I would expect that the config file reader
On Mon, Jul 1, 2013 at 3:19 PM, Bjorn Reese bre...@mail1.stofanet.dk wrote:
First, AFAIK base85 is not compatible with XML (for config files.)
The example I showed was XML. So yes, it's compatible with XML unless
you like to put values between tags instead of in quotes.
Second, why should
On Mon, Jul 1, 2013 at 2:17 PM, Bennie Kloosteman bkloo...@gmail.com wrote:
I also dont understand the issue with Base64 , not a single standard , well
the whole interenet uses it in html and email so there must be a common
standard and being 3 bytes when you convert it to a byte[]you
Hi Pieter,
Any specific reason to create Z85 instead of going with Base64, which
doesn't present the escape characters drawback that Ascii85 has? I
understand that there's a few percent difference in terms of efficiency,
but, other than that?
Considering switching from Base256 to Z85 already
On Sat, Jun 29, 2013 at 2:01 PM, Sebastian Lauwers
sebastian.lauw...@gmail.com wrote:
Any specific reason to create Z85 instead of going with Base64, which
doesn't present the escape characters drawback that Ascii85 has? I
understand that there's a few percent difference in terms of
Hi all,
I've pushed a new RFC[1], which defines a format Z85 for encoding
binary as text.
The reason for making this is that it's painful to use Base256
(binary) keys, since you can't exchange them by email or put them into
code except with manual reformatting.
Z85 uses a Base85 encoding taken
14 matches
Mail list logo
