ac> If you want a free-format, then you're probably better off ignoring the
ac> PID spec and sticking with the tearline.  PID was designed "to minimize
ac> the excessive amount of information some programs put on the tear lines
ac>  ...".  While I agree with this principle, I don't think FSC-46 should
ac> go as far as specifying a distint sub-identifiers for a program
ac> identifier as does the current version of the specification.

Then write your own spec, or ask Joho to change it.  I don't
care either way, but whilst the spec stands as it is, I think
it should be conformed to.

ac> I never said it didn't matter, but there must be a limit to how far you
ac> can take the practice of "reductio ad absurdium" (reduction to the
ac> absurd).

So don't use the PID spec.

PE> I certainly don't mind the PID spec being changed.

ac> Fine - provided it maintains its usefulness and does not invalidate
ac> previous specifications.

It would invalidate them, if it were to be written to 
encompass what people are currently putting out.  OTOH I 
don't particularly mind people saying "rightio, on 1995-06-01
we are radically changing all the specs, you've got 24 hours
to comply".

ac> Such translation should be done at the risk of the programmer, IMO.  My
ac> understanding of FSC-46 has always been that the PID kludge was never
ac> designed for any other use than human consumption; viewing purposes
ac> only (displayed but not parsed).

Which bit of FSC-46 made you think that?  FSC-46 is the only
reference you can use for FSC-46.

PE> People's lack of compliance means that such code would break. I 
PE> fail to see why people should have to code around other people's
PE> inability to conform to the specs.

ac> Because this is the real world.  Folks are always bound to either
ac> blatantly or inadvertanty ignore/misuse/misunderstand specification at
ac> one time or another.  Programmers should be aware of this, and do their
ac> best to ensure their code does not break when such instances occur.

Bloody oath, your code should never fail no matter what the input
data is.

PE> Or more to the point, I am happy to do validation that makes
PE> sure anything non-conformant gets a general error of "grunged 
PE> message", and we all know what happens to grunged messages.

Exactly.  Whoops, that's my point again.

ac> Non-conformant != Grunged.

Wrong.

ac> I would hope you would attempt to process any damaged mail manually if
ac> your system were to receive it.

I may or may not choose to do that.  I have no requirement to
do anything with grunged mail.  You, on the other hand, have a
requirement not to generate grunged mail in the first place.
BFN.  Paul.
@EOT:

---