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@xxxxxxx] > Sent: Tuesday, March 13, 2007 6:13 PM > To: Simon Josefsson; Hallam-Baker, Phillip > Cc: Brian E Carpenter; iesg@xxxxxxxx; ietf@xxxxxxxx; 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@xxxxxxxxxxxxx> wrote: > > > "Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf