Re: ASN.1 (Was: [9fans] More 'Sam I am')

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[quanstro]

i worked on a project for years that used a format equivalent
to XML or ASN.1, but we thought simplier.

naming the entities presented no efficiency problems for us.
i spent 6 months in several stints profiling that system
and for a 10k result set, the tcp overhead was greater than
the packing and unpacking overhead, but neither represented
1% of the runtime of any end-to-end process that i looked at.

with the exception of word processors, web browsers, and maybe gcc
i do not agree with your corollary to moore's law. 15 years ago
i was stuck with sun 160s and vaxen. 10 years ago i had a
ibm rs/6000 41t and a 66mhz pentium II. i'm still not up-to-date,
but by all my performance metrics, the 997mhz system i
use now is *way* faster. i've even got a better internet
connection via dialup than the sun/vax setup did in the late 80s.

- erik

On Sat Feb 11 02:24:26 CST 2006, lucio@proxima.alt.za wrote:
> > So why not /lib/ndb format: textual attribute=value pairs
> > with grouping?
> 
> Because (a) they are language/alphabet specific and (b) they are
> inefficient.
> 
> Before you jump down my throat, I am aware that the inefficiencies
> smack of premature optimisation, but in ASN.1 days they were mere
> failures of vision.  And I do maintain that saving processor cycles
> and storage is not a futile quest.  The corollary to Moore's Law is
> "Software bloat exceeds any gains in processor performance even before
> such gains can be exploited".

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> i worked on a project for years that used a format equivalent
> to XML or ASN.1, but we thought simplier.
> 
> naming the entities presented no efficiency problems for us.
> i spent 6 months in several stints profiling that system
> and for a 10k result set, the tcp overhead was greater than
> the packing and unpacking overhead, but neither represented
> 1% of the runtime of any end-to-end process that i looked at.
> 
Thing is, the ITU-T could not put a simpler design into their
recommendations: as Geoff correctly points out, that is not how PTTs
operate, they have long before anyone else been the leaders in
globalisation.  The Internet has shaken those foundations, but we'll
be paying a price for that before long, when ISP consolidate into a
monopolistic mass.  In case you want to know where I'm coming from, my
belief is that the cooperative nature of the Internet will be lost to
econmies of scale that will quickly suffer from diminishing returns
and escalating costs.  The role played by the small participant is
already insignificant, soon it will become unwanted.

As an indicator, I use the metric that twenty years ago, without much
financial backing, I could engineer adapters for the PC that were in
demand and could be built by a small team at a reasonable price.
Since the advent of PCI, the entry bar has been raised considerably.

> with the exception of word processors, web browsers, and maybe gcc
> i do not agree with your corollary to moore's law. 15 years ago
> i was stuck with sun 160s and vaxen. 10 years ago i had a
> ibm rs/6000 41t and a 66mhz pentium II. i'm still not up-to-date,
> but by all my performance metrics, the 997mhz system i
> use now is *way* faster. i've even got a better internet
> connection via dialup than the sun/vax setup did in the late 80s.
> 
Sure, but are you more productive?  And are your personal
opportunities any greater?  Consider the equipment that NASA needed to
put Neil Armstrong on the Moon in 1969.  It ought to cost peanuts to
reproduce those items using today's technology, instead, the cost of a
space mission seems to be beyond the reach of any modern entrepreneur.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Christopher Nielsen]

On 2/11/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
[snip]
> instead, the cost of a space mission seems to be beyond the reach of
> any modern entrepreneur.

that's utterly false. SpaceShipOne. not to mention all the other
x-prize participants. a commercial venture did something that
no government funded space program has been able to do.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Russ Cox]

On 2/11/06, Christopher Nielsen <cnielsen@pobox.com> wrote:
> On 2/11/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> [snip]
> > instead, the cost of a space mission seems to be beyond the reach of
> > any modern entrepreneur.
>
> that's utterly false. SpaceShipOne. not to mention all the other
> x-prize participants. a commercial venture did something that
> no government funded space program has been able to do.

weren't you the one complaining about there being too many
conversations that had nothing to do with plan 9?

russ

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Christopher Nielsen]

On 2/11/06, Russ Cox <rsc@swtch.com> wrote:
> weren't you the one complaining about there being too many
> conversations that had nothing to do with plan 9?

you're absolutely right, russ. sorry.

--
Christopher Nielsen
"They who can give up essential liberty for temporary
safety, deserve neither liberty nor safety." --Benjamin Franklin

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Russ Cox]

> you're absolutely right, russ. sorry.

actually, you weren't (thanks uriel).
sorry, not paying enough attention.

russ

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Skip Tavakkolian]

9fans are so nice, even the flaming is civilized.
who said "tact sucks"?!

>> you're absolutely right, russ. sorry.
> 
> actually, you weren't (thanks uriel).
> sorry, not paying enough attention.

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Bruce Ellis]

i can't think of something to flame about.  oh yeah it's
overcast and i was planning on brunch.

brucee

On 2/12/06, Skip Tavakkolian <9nut@9netics.com> wrote:
> 9fans are so nice, even the flaming is civilized.
> who said "tact sucks"?!
>
> >> you're absolutely right, russ. sorry.
> >
> > actually, you weren't (thanks uriel).
> > sorry, not paying enough attention.

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[quanstro]

On Sat Feb 11 13:54:32 CST 2006, lucio@proxima.alt.za wrote:

> > all i'm saying is that it is not true that using a computer is now
> > slower than it used to be.
> > 
> Yes it is.  Just hunting down a floppy that has no bad sectors
> consumes significant fractions of my working day.  

i'm not going to ask why you're looking for a floppy.

> In fact, Ubuntu Linux takes exception of my 2.4GHz Celeron board that
> has only 128MB of RAM and runs about as fast as it does on the above,
> which is perfectly unusable.

there are lots of solutions here, if you choose to take them.

i've got gentoo running on a 128M ibm thinkpad 570. i'm sure you
could get gentoo running on your celery machine or, now here's a thought,
plan 9. 

> PS: I warrant that conditions here are hardly the norm, but I am a
> sophisticated computer user and only rarely do I get the benefits of
> Moore's law, > whereas I am constantly reminded of the corollary you
> reject.  

suit yourself.  i'm pretty sure things have gotten better since
dos TSR programs and sneaker nets. 

- erik

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Jack Johnson]

On 2/11/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> suit yourself.  i'm pretty sure things have gotten better since
> dos TSR programs and sneaker nets.

That depends.

We have a site that used to be connected via T1, and when we were
looking at options for offsite backup we did the math and -- given the
distance -- anything bigger than about a CD's worth of data was faster
to walk over.

But, aside from that, I agree. :)

-J

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Bruce Ellis]

doesn't help if you are doing remote video surveillance of many
things 12,000km away.

brucee

On 2/12/06, Jack Johnson <knapjack@gmail.com> wrote:
> On 2/11/06, quanstro@quanstro.net <quanstro@quanstro.net> wrote:
> > suit yourself.  i'm pretty sure things have gotten better since
> > dos TSR programs and sneaker nets.
>
> That depends.
>
> We have a site that used to be connected via T1, and when we were
> looking at options for offsite backup we did the math and -- given the
> distance -- anything bigger than about a CD's worth of data was faster
> to walk over.
>
> But, aside from that, I agree. :)
>
> -J
>

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> 
> i'm not going to ask why you're looking for a floppy.
> 
To boot an unconfigured machine?  For NetBSD, I need two.

> i've got gentoo running on a 128M ibm thinkpad 570. i'm sure you
> could get gentoo running on your celery machine or, now here's a thought,
> plan 9. 
> 

Point is, the 2.4GHz clock is a lie.  It is not 300 times faster than
an 8MHz 8088 (only?  I would have thought more) and sometimes it
doesn't feel like it's any faster at all.  And it restricts me in ways
the old PC-Clones never did.  I won't deny one can do lots more today
than in 1983, but it's hardly as much more as Moore's law would
suggest.

> suit yourself.  i'm pretty sure things have gotten better since
> dos TSR programs and sneaker nets. 
> 
No, jmk is right, we're closer to the wheels falling off.  Despite (to
bring the thread in line _and_ hopefully, put it to bed) the likes of
Plan 9 showing how to tighten the bolts.

But, in all truth, I'm not taking an 8088-based laptop to Cape Town
with me :-)

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Bruce Ellis]

a 600MHz P3 is adequate (my old single brain-dead config as
mr chaote called it).  my 3GHz cpu server is blindingly fast.

for a terminal a P1 is fine.

brucee

On 2/12/06, lucio@proxima.alt.za <lucio@proxima.alt.za> wrote:
> >
> > i'm not going to ask why you're looking for a floppy.
> >
> To boot an unconfigured machine?  For NetBSD, I need two.
>
> > i've got gentoo running on a 128M ibm thinkpad 570. i'm sure you
> > could get gentoo running on your celery machine or, now here's a thought,
> > plan 9.
> >
>
> Point is, the 2.4GHz clock is a lie.  It is not 300 times faster than
> an 8MHz 8088 (only?  I would have thought more) and sometimes it
> doesn't feel like it's any faster at all.  And it restricts me in ways
> the old PC-Clones never did.  I won't deny one can do lots more today
> than in 1983, but it's hardly as much more as Moore's law would
> suggest.
>
> > suit yourself.  i'm pretty sure things have gotten better since
> > dos TSR programs and sneaker nets.
> >
> No, jmk is right, we're closer to the wheels falling off.  Despite (to
> bring the thread in line _and_ hopefully, put it to bed) the likes of
> Plan 9 showing how to tighten the bolts.
>
> But, in all truth, I'm not taking an 8088-based laptop to Cape Town
> with me :-)
>
> ++L
>
>

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[quanstro]

how did we get here? "personal oppertunities"?

all i'm saying is that it is not true that using a computer is now
slower than it used to be.

who rembers pc 5¼" disk drives? sppppt chunk chunk chunk ...
spppppt chunk chunk chunk brrrrrrrrrrrrrrrrrf. all for 64k.

On Sat Feb 11 09:57:24 CST 2006, lucio@proxima.alt.za wrote:

> Sure, but are you more productive?  And are your personal
> opportunities any greater?  Consider the equipment that NASA needed to
> put Neil Armstrong on the Moon in 1969.  It ought to cost peanuts to
> reproduce those items using today's technology, instead, the cost of a
> space mission seems to be beyond the reach of any modern entrepreneur.
> 
> ++L
> 

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> how did we get here? "personal oppertunities"?
> 
Oh, I'm obscurely asking whether in fact your faster computer does
provide the additional time and opportunity one might expect it to.
In my experience, it doesn't.  Not only, but the additional
unreliability (fans conking out topping a peculiarly rich list of
failure modes) leads to frustration and stress, at least in my case.
And very poor productivity.

> all i'm saying is that it is not true that using a computer is now
> slower than it used to be.
> 
Yes it is.  Just hunting down a floppy that has no bad sectors
consumes significant fractions of my working day.  Even out the box.
CD-ROMs seem to develop faults and brand new drives can't read them.
Memory is unreliable and unavailable for any but the latest models of
motherboards, not to talk of CPUs and adapters.  And a friend whinged
that ATA is no longer supported on recent motherboards.  He's just
invested in 6 swappable trays, so he's got good reason to be miffed.

Hell, I was thinking that gaming had improved considerably, but my
favourite game recently managed to hang the system the first time I
tried it on a fresh Win'98 installation.

> who rembers pc 5¼" disk drives? sppppt chunk chunk chunk ...
> spppppt chunk chunk chunk brrrrrrrrrrrrrrrrrf. all for 64k.

I wish I still had my Osborne model II to prove that I can still read
90K floppies with working versions of SuperCalc, WordStar and DBase2,
whereas I have no ways of running mountains of Windows software
because my best available platform is a 400MHz Celeron with only 64MB
of RAM.

In fact, Ubuntu Linux takes exception of my 2.4GHz Celeron board that
has only 128MB of RAM and runs about as fast as it does on the above,
which is perfectly unusable.

++L

PS: I warrant that conditions here are hardly the norm, but I am a
sophisticated computer user and only rarely do I get the benefits of
Moore's law, whereas I am constantly reminded of the corollary you
reject.  Perhaps I ought to have been less specific about software
bloat, but hopefully I'll have explained why I believe all these
"advances" are not progress.

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Richard Miller]

> who rembers pc 5¼" disk drives? sppppt chunk chunk chunk ...
> spppppt chunk chunk chunk brrrrrrrrrrrrrrrrrf. all for 64k.

Don't need to remember -  got one right here:

cpu% ls -l /dev/fd1*
--rw-rw---- f 0 miller miller      0 Dec 22 10:19 /dev/fd1ctl
--rw-rw---- f 0 miller miller 368640 Dec 22 10:19 /dev/fd1disk
cpu% cat /dev/fd1ctl; echo
5¼DD
cpu% time cat /dev/fd1disk >/dev/null
0.00u 0.03s 20.37r 	 cat /dev/fd1disk

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[quanstro]

i worked on a project for years that used a format equivalent
to XML or ASN.1, but we thought simplier.

naming the entities presented no efficiency problems for us.
i spent 6 months in several stints profiling that system
and for a 10k result set, the tcp overhead was greater than
the packing and unpacking overhead, but neither represented
1% of the runtime of any end-to-end process that i looked at.

with the exception of word processors, web browsers, and maybe gcc
i do not agree with your corollary to moore's law. 15 years ago
i was stuck with sun 160s and vaxen. 10 years ago i had a
ibm rs/6000 41t and a 66mhz pentium II. i'm still not up-to-date,
but by all my performance metrics, the 997mhz system i
use now is *way* faster. i've even got a better internet
connection via dialup than the sun/vax setup did in the late 80s.

- erik

On Sat Feb 11 02:24:26 CST 2006, lucio@proxima.alt.za wrote:
> > So why not /lib/ndb format: textual attribute=value pairs
> > with grouping?
> 
> Because (a) they are language/alphabet specific and (b) they are
> inefficient.
> 
> Before you jump down my throat, I am aware that the inefficiencies
> smack of premature optimisation, but in ASN.1 days they were mere
> failures of vision.  And I do maintain that saving processor cycles
> and storage is not a futile quest.  The corollary to Moore's Law is
> "Software bloat exceeds any gains in processor performance even before
> such gains can be exploited".

Re: [9fans] More 'Sam I am'

[quanstro]

isn't this the "i don't trust new software" argument resurrected?
let's all install V7 from mag tape on our pdp-11s. ;-)

sorry. i couldn't resist.

- erik

On Fri Feb 10 16:54:45 CST 2006, lucio@proxima.alt.za wrote:
> > Would you pick
> > XML or ASN.1 if those were the only two options?  If the pointy-haired
> > powers that be are mandating one or the other and, ``neither'' isn't in
> > the range of possible solutions?
> 
> What are the alternatives?  My pick is ASN.1, any time.  You can call
> the ITU-T by as many ugly names as you like, but their standards are
> considerably more firm than more recent publications.
> 
> ++L
> 

ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> isn't this the "i don't trust new software" argument resurrected?
> let's all install V7 from mag tape on our pdp-11s. ;-)
> 
> sorry. i couldn't resist.

You're welcome, but I think you're off the mark.  X.680 is less than
100 pages and is written in that peculiar jargon that CCITT/ITU-T have
evolved to make sure that the real niggly faults are well hidden where
they can only be discovered in the most painful fashion.

Perhaps it is seriously flawed, but I have only a single paper by Carl
Ellison entitled ASN.1 Misuse (September 15, 1995) to back that
argument:

	"The ASN.1 standard (Abstract Syntax Notation 1) is
	proliferating, in spite of cries of anguish by computer
	professionals who are faced with implementing to those
	standards.  The standard is flawed.  Some of those flaws come
	from its complexity and ambiguity - a product most likely of
	having started down the wrong path and been subject to
	corrections by various interested parties along the way.  It
	has acquired various warts and is apparently the result of a
	committee effort.  Other flaws come from its misuse, and those
	are the one addressed in this paper."

I note I'm missing pages 5 to 6 (of 6 :-).  Thing is, XML is not 100
pages long, is nothing like less "complex or ambiguous" and is still
work in progress.  How much can one add to such a beast before its
camel back breaks?

And my question remains: "What is a better option for the conveying of
platform-independent data than ASN.1 or XML?"

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

> "What is a better option for the conveying of platform-independent
> data than ASN.1 or XML?"

A somewhat-flippant answer would be text strings and numbers expressed
as strings.  But what ASN.1 (or BER) and XML seem to be trying to do
is to permit the export and later import of essentially arbitrary C
structs in a manner that will be portable across processor
architectures.  /sys/src/libsec/port/x509.c seems to be mostly
concerned with ASN1 and it's 2,559 lines long, and that's short
compared with the openssl ASN1 routines, which total 16,071 lines in
my copy.  So why not /lib/ndb format: textual attribute=value pairs
with grouping?

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> So why not /lib/ndb format: textual attribute=value pairs
> with grouping?

Because (a) they are language/alphabet specific and (b) they are
inefficient.

Before you jump down my throat, I am aware that the inefficiencies
smack of premature optimisation, but in ASN.1 days they were mere
failures of vision.  And I do maintain that saving processor cycles
and storage is not a futile quest.  The corollary to Moore's Law is
"Software bloat exceeds any gains in processor performance even before
such gains can be exploited".

It also strikes me as remarkable that you'd think ASN.1 is intended to
represent C structures.  I would think the intent was to be a message
format on the wire and the internal representation was left as a
matter of implementation.  The latter, of course, is where it all fell
apart because (a) there were issues that could not be finalised
without conflict and (b) there were mistakes that were only discovered
once different implementations could not interoperate.

In the latter case, I have to concede that the IETF is better geared
for the laying down of standards.  Skip is right in that standards
ought not to be accepted until there has been an implementation, but
of course that sword has two edges, too.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

Hmm, the old language-specific argument.  The usual solution to this
is to use a binary encoding, the theory being that by avoiding words,
you avoid chauvinism.  I'd still rather have a textual format, even if
the attribute names have to be translated for speakers of other
languages (they'd have to translate a binary encoding into their own
language anyway).  If we wanted to inconvenience everyone equally, the
attribute names could be gibberish.

I'm not convinced that the slight inefficiency matters, particular for
a message format.  We do build indices in /lib/ndb to speed searches,
but that's for searching, not just encoding for transmission.  If
you're thinking of binary-decimal conversion overheads, one could
insist upon using octal representation (as tar does), which can be
converted more quickly than decimal, though that does make it a little
less human-friendly.

There has to be mapping between message format and something like a C
struct (some internal representation).  ASN.1 attempts to describe
both, as I understand it, to facilitate conversion between the two.

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> If we wanted to inconvenience everyone equally, the
> attribute names could be gibberish.
> 
Or binary.  Even your argument goes full circle.  And because we're
talking about information on the wire, why not stick to what the end
points process best?

Not that ASN.1 should be defended, but your argument needs its holes
poked :-)

> If
> you're thinking of binary-decimal conversion overheads, one could
> insist upon using octal representation (as tar does), which can be
> converted more quickly than decimal, though that does make it a little
> less human-friendly.
> 
The human-friendly bit is a chimera, It's data on the wire, it was
never the intent of CCITT (I presume) to treat it as anything else.
Much as you can't detect the magnetic properties of core to decide
what is in memory, you need some sort of translator to inspect the
data on the wire.  In CCITT terms, that isn't a problem as cost was
never a consideration when investing in projects with 30- to 50-year
life spans.  It's the urgency of new technology that forces costs all
the way down and deprives R&D departments of multi-digit budgets.

> There has to be mapping between message format and something like a C
> struct (some internal representation).  ASN.1 attempts to describe
> both, as I understand it, to facilitate conversion between the two.

I'm not an ASN.1 guru, never will be.  But I think ASN.1 is intended
to be the permanent representation, with ephemeral internal formats as
dictated by processing.  I'm not sure where in the ITU-T
recommendations I'd have to look to contradict you, however.

It is perfectly possible for the ITU-T committee to have decided to
intrude where they did not belong.  They certainly mirrored the
computer architectures of the time, with various predefined integer
sizes as well as a variable length alternative, so they are guilty of
parochial thinking.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Steve Simon]

> So why not /lib/ndb format: textual attribute=value pairs
> with grouping?

Vote 1 for Geoff.

Seriously I tried this for a project, but got loads of flak for not
using The Standard (XML) so when I "threw one away" last year I reworked
the system using XML.

To be honest the pain was short lived - writing the parser, and since
then I don't see much difference. There are some of XMLs stranger rules
and all those [<>/] which look a mess to my C trained eyes but I try
not to look too often.

(Before anyone jumps doen my throat I wrote a parser because I am on a
small embedded system)

-Steve

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Bruce Ellis]

I implemented both in ozinferno.  ASN is almost ludicrous.
XML was remarkably easy but ruthless.  anyhow my XML
parser does parse the XML spec (written in XML) and i'm
yet to find a commercial product that does.

brucee

On 2/11/06, Steve Simon <steve@quintile.net> wrote:
> > So why not /lib/ndb format: textual attribute=value pairs
> > with grouping?
>
> Vote 1 for Geoff.
>
> Seriously I tried this for a project, but got loads of flak for not
> using The Standard (XML) so when I "threw one away" last year I reworked
> the system using XML.
>
> To be honest the pain was short lived - writing the parser, and since
> then I don't see much difference. There are some of XMLs stranger rules
> and all those [<>/] which look a mess to my C trained eyes but I try
> not to look too often.
>
> (Before anyone jumps doen my throat I wrote a parser because I am on a
> small embedded system)
>
> -Steve
>

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Skip Tavakkolian]

i think any committee that comes up with a proposed standard should
individually be responsible for implementing it.  note that this would
work for large or small efforts.  if the committee is able to
implement it and it works, then it would be adopted.

specific to the question, i like the S-expression approach I've not
used it for anything so my advice is as good as the random committee
member.

> And my question remains: "What is a better option for the conveying of
> platform-independent data than ASN.1 or XML?"

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[geoff]

> i think any committee that comes up with a proposed standard should
> individually be responsible for implementing it.

That's not how PTTs do things!  How do you think they came up with
crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[lucio]

> That's not how PTTs do things!  How do you think they came up with
> crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

Come, come, Geoff!  They did precisely as they needed to.  It probably
has a lot in common with the urethra doubling back into the prostrate
gland.  Has anyone produced a better mouse trap yet?  I note with
horror that internationalisation is creeping into LDAP.

++L

Re: ASN.1 (Was: [9fans] More 'Sam I am')

[Skip Tavakkolian]

>> i think any committee that comes up with a proposed standard should
>> individually be responsible for implementing it.
> 
> That's not how PTTs do things!  How do you think they came up with
> crap like OSI (X.400, X.500)?  Sheesh, get real, kid!  ☺

what i meant to say was "if i was philosopher-king in charge of the world i
would make any committee ..."