[Top] [All Lists]

Re: A refinement to Radix-64

1992-06-02 21:09:34
The proposed change to base64 offers ZERO functional improvement.
Making that change would break the 3+ implementations already deployed
at ~500 sites.  (Not to mention screwing up the 12+ other
implementations currently being developed.)

I'm not sure where Marshall gets his numbers. My own numbers relate to PMDF, a
mail system used mostly (but not exclusively) on VMS systems. 

PMDF has had support for base64 encoding in it since version 4.0, which was
released about 8 months back. We have released PMDF V4.1 this week. We held off
doing this until MIME reached proposed standard status with the IAB. PMDF V4.1
accomodates all the changes that have gone into MIME over the past 6-8 months.

PMDF is installed at well over 1000 sites. The average site usually has around
five systems using PMDF. 

I cannot tell you what portion of these systems are running a recent enough
version of PMDF to have base64 support and I cannot tell you if any or all of
them use base64 encoding. All I can give is an estimate of how many sites have
the software and how many systems they say they run it on.

The 12+ implementations in development would not be hard to change if
they are not deployed.  It's real easy to change a table.  The more 
troubling question is the 3+ implementations already installed at 500
sites.  I didn't know about that.  Hmmm.  Are these experimental
implementations?  Released products?  How do we calculate the real
impact and costs?  Maybe it would not be worth it after all.  But
maybe people could have said that in the early days of TV, when an
early improvement in TV transmission format would have impacted
"hundreds" of installed TVs.

PMDF is a commercial product.

Well, I'm not going to keep pushing this idea if nobody wants it.  Is 
there anyone else out there who wants to say anything good about it?  
Any other critics who want to be less restrained than Marshall?

I originally made the choice of how base64 is structured in MIME. I had no
strong feelings about it; I simply wanted to use an encoding that met the
requirements. The encoding used by PEM seemed to meet all our needs and I was
reluctant to invent something new for no reason.

I have no strong technical objection to the reordering. But I also see no need
for it. I think you seriously overestimate the value of changing it. I have
read your arguments, but I think the utility of using an extensible family of
multibase encodings is nonexistent. I think I could make an equally strong
(that is, equally specious) case for using representations that overlap as
little as possible -- such a choice would make it much easier to guess what
base something is represented in.

On a procedural level, however, making such a change right now is totally
unacceptable to me. The document has advanced too far to change it for any but
the most compelling technical reasons; in my opinion this change would require
another pass through the working group and back up the hierarchy. This would
have the effect of delaying MIME for 6 months. A 6 month delay is totally
unacceptable -- we need MIME now.

The next time when such a change could be considered from a procedural
standpoint would be at the 6 month review point. By then there will be dozens
of implementations in the field and they will be installed on many thousands of

If you had brought this up six months ago I would have been much more amenable
to at least considering this change, although I would have had to run it by the
PEM people for their approval as well before I would have taken it seriously.
But it is not feasible to do it now.


<Prev in Thread] Current Thread [Next in Thread>