Options are not necessarily complications.
The only point to having XER that I can see is if you intend to allow an
orderly transition from use of ASN.1 to use of XML. Both standards do their job
fine, both are somewhat more complex than they should be. One of these choices
is surplus to requirements.
If I am writing in any modern development language that supports metadata such
as .NET I can perform XML encoding and decoding automatically by simply calling
up an encoder/decoder. To create the same capability in ASN.1 requires vastly
more effort.
If we had hundreds of ASN.1 schemas that people cared about in the IETF I might
see an argument for continuing to dual stack ASN.1 and XML indefinitely. Given
where we are enabling a phase out of ASN.1 for certain protocols makes a lot of
sense.
I don't think that this would make a lot of sense for PKIX but certainly for
SNMP and LDAP.
-----Original Message-----
From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
Sent: Tuesday, March 13, 2007 6:13 PM
To: Simon Josefsson; Hallam-Baker, Phillip
Cc: Brian E Carpenter; iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
Pekka Savola
Subject: Re: Document Action: 'Abstract Syntax Notation X
(ASN.X)' to Experimental RFC
--On Tuesday, 13 March, 2007 16:58 +0100 Simon Josefsson
<simon(_at_)josefsson(_dot_)org> wrote:
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Arguments on complexity are too easy to make. Every time a
proposal
is made I hear the complexity argument used against it.
Everything we
do is complex. Computers are complex.
Committee process usually increases complexity somewhat.
If an argument can always be used what is the discrimination power?
How about using answers to the question "Is this complexity
needed?"
as a discriminator?
Sometimes, there is no better solution than one with certain
complexity. That isn't inherently bad.
I'm not sure the need for this particular complex solution was
demonstrated. I don't recall anyone defending it. The
experimental
track thus seems appropriate, if it should be published at all.
But that was precisely where the other thread, if I recall,
came out. It wasn't an argument against complexity. It was
an argument about introducing another optional way of doing
things because we _know_ that many options lead to worse
interoperability. And it was a suggestion/ request that,
before this document was published in _any_ form, that it at
least acquire a clear discussion as to when one would select
this form over the well-established ASN.1 form for which
there is existing deployment, existing tools, etc. Put
differently, we all know that this _can_ be done but, if
there is another solution already out there, widely deployed,
and in active use, a clear explanation about _why_ it should
be done and under what circumstances it is expected to useful
is in order.
That suggestion about an explanation was a specific request
about the document, not idle theorizing about the character of
ASN.1 or the nature of complexity.
And, again, pretending that the discussion didn't occur
impresses me as a little strange.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf