Subject: RE: OCSP-X vs SCVP

From: Dan Ash <[email-masked]>
Date: Sun, 12 Nov 2000 18:36:26 -0500

The SCVP draft defines syntax for both ASN.1 and XML  A question about
this arose on the list a few months back, where it was mentioned that
supporting both languages would:
        -  cause "code bloat".
        -  significantly increase the testing burden
        -  and cause potential discrepancy when translating from one
language to another.

I might be completely off track here, but is it possible, and does it
make sense to include within the definition of a protocol not only
different languages to represent the content,  but also a specification
of how to translate from one language to the another?  If so,  perhaps
some arbitrary software (independent of the client or the server) could
translate from one language to another... allowing both the client and
the server to deploy in either language.  This might alleviate the
problems mentioned above.

In any case, this issue of ASN.1 vs XML is obviously a complex one.
ASN.1 is ingrained in all of PKIX's work... while the user community is
demanding XML..  and for PKIX to begin incorporating XML in anything, I
think there needs to be a direction and a consistent strategy to move
forward with.  If there isn't any general direction and strategy,  then
I believe that we'd only be promoting confusion.  For this, I certainly
agree with Ambarish....that the XML vs. ASN.1 topic should be discussed
independently of OCSPv2 and SCVP so that it may be more clear of how we
can and should proceed if and when it is decided to integrate XML
representation into PKIX efforts.

... Also, I do agree that the topic should be awarded priority if it
hasn't already.

-dan

---

From: "Peter H. Gien" <[email-masked]>
Date: Sun, 12 Nov 2000 18:27:38 -0500

Dan,

Forgive me if I digress from the original topic.
Let's agree that ASN.1 and XML are not really languages such as C and Java.
As such, ASN.1 and XML are simply tag formats that are used to describe
data. I cannot compile ASN.1 nor can I execute XML. The use of one or the
other would not necessarily result in "code bloat". Data bloat yes.

One thing that is for sure though, is that any budding VB programmer can
open an XML document without any trouble. MSXML.DLL is already on their
machine and it opens the document as if by magic. A little more study,
effort and insight is needed to open an ASN.1 file. (OK, a lot more...)

I'd like to add that going forward, XML should be a standard way of
describing all PKIX data structures. Think what has happened to assembly
programming? Delegated to the specialist backwaters of computing (Too much
studying, effort and insight was required). It was replaced with C and
shortly thereafter with C++. The same analogy applies to ASN.1 and XML. The
standard that requires the least amount of intellectual effort to comprehend
and implement is the one that wins. This does not always translate to the
best standard!)

So without sparking a riot, I'd like to agree with the rest of you who are
advocating XML.

Thanks
Peter H. Gien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dan Ash
Sent: Sunday, November 12, 2000 6:36 PM
To: [email-masked]
Subject: RE: OCSP-X vs SCVP

-dan

---

From: daniel ash <[email-masked]>
Date: Mon, 13 Nov 2000 10:06:38 -0500

> other would not necessarily result in "code bloat". Data bloat yes.

I didn't intend to imply 'programming language'...  'language' is clear enough
in context.

> effort and insight is needed to open an ASN.1 file. (OK, a lot more...)

You could find, or easily develop something to decode and "open" an ASN.1
structure.  I believe the argument stems from the fact that the syntax of XML
languages is easier to adopt for people who already have experience using
markup languages(which covers the large base of HTML programmers).... also that
the syntax is generally more intuitive.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Nov 2000 12:01:14 -0500

Peter,

>other would not necessarily result in "code bloat". Data bloat yes.

One can compile ASN.1 into various programming languages, e.g., C++. 
Such compilers have been available for 10-15 years.  That is one 
reason for adopting it for protocol data format description. One 
should also distinguish between the syntax specification aspects of 
ASN.1 and the encoding rules, something your text above does not do.

>effort and insight is needed to open an ASN.1 file. (OK, a lot more...)

Not on my Mac, I suspect :-).

>and implement is the one that wins. This does not always translate to the

I'm still in favor of creating the best standards in this WG.

Steve