Subject: Re: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt)

From: [email-masked]
Date: Fri, 9 Jul 1999 13:14:59 EDT

Bill,

Good call.    I have people on my team pursuing both approaches, but remain 
agnostic because I have been down this road myself  before.   I believe that 
standards compliance and interoperability are critical for most apps, but 
have been known to build custom non-interoperable stuff using alot of glue 
when necessary.   I think I will wait this one out, but bet on ASN.1 
surviving...Kawika

Kawika Daguio
EVP - Financial Information Protection Association

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 9 Jul 1999 19:40:47 +0200 (MET DST)

> Bill Burr 

> But, I've been around long enough to remember when very similar claims that
> never panned out, were made for SGML and ASN.1 itself.  It seems perhaps a
> bit too early to just assume that XML will be the great unifying data model
> and format for the next millennium. 
> 
> It replacement of ASN.1 be a reasonable idea to consider, but I'd like to
> see how XML plays our a little more, before jumping head first into the XML
> pool.
> Regards,

If you read the chapter abeot service elements in X.400
(for exemple chapter 4 in the 84 version) you do not find
any indication of ASN.1 or even a data format. 

There is a clear distinction between the semantics of the
abstract service, the data formats used, and the way how
several elements are set in order to provide the desired
service elements.

An interesting example to read is RFC987 and its successors, especially
the comments about service elements in RFC822 (they are IMPLIED), etc. 

> Phillip M Hallam-Baker:

> Tony Hoare once argued that programming language features should be 
> argued separately from the syntax. I would be much happier if IETF
> process encouraged a separation of protocol semantics and syntax.

Impossible, this would be too OSI :-) In some cases it seems to
me that the actual semantics of a protocol is not completely defined
in advance, or the developer of the protocol ist playing the
half-open game: I already put the syntax in the public domain, but
not the semantics. 

Peter Sylvester

---

From: "Rich Ankney" <[email-masked]>
Date: Sat, 10 Jul 1999 08:52:44 -0400

Actually, there's been a little work on XML Encoding Rules
(XER).  Check out, e.g., http://asf.gils.net/xer/standard.html.
I've also seen proposals that include an indication of the
primitive (ASN.1) datatype for an element in the XML encoding,
which would be useful till there's a standard way to do that in XML.
One such proposal is at
http://www.oclc.org/~levan/docs/xerencodingrules.html.

Regards,
Rich
-----Original Message-----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: IETF PKIX <[email-masked]>
Date: Friday, July 09, 1999 7:35 PM
Subject: Re: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-00.txt)

>Frank - good point on the XML encoding of ASN.1 Structures - I like it.
>
>Add 'the about to be proposed' preprocessor to resolve all the persistent
>objects, their policy, and authentication requirements and who-ha!
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>; <>
>Sent: Friday, July 09, 1999 11:38 AM
>Subject: RE: ASN.1 vs XML (used to be RE: I-D
>ACTION:draft-ietf-pkix-scvp-00.txt)
>
>
>> ASN.1 is a syntax
>
>technically its a language. It has a syntax.
>
>> that enables protocol engineers to communicate abstractly
>> about bits that may travel down a wire, including the qualities:
>
>after being interpreted by an BER or DER encoder it does.
>
>>
>> optional elements
>> default values
>> inheritance (using object classes)
>> constraints
>>
>> XML is markup language that can be used to format (or encode) bits that
>> travel down a wire.
>>
>> There is no reason why ASN.1-defined data can not be formatted as XML.
>
>Absolutely True !!! Actually this is an interesting observation to make.
>That there is really no reason that you cannot write ASN.1 in XML...
Imagine
>being able to have one framework that encapsulates all service models.
>
>
>>
>> For those of you advocating the use of XML, does XML provide a rich set a

>> abstract qualities for engineers to use when communicating about bits
that
>> may travel down a wire?
>
>Sure it does, or "it could" is a better answer -  becuase there is really
no
>reason you or anyone else cannot write an XML encoder (ala BER or DER) to
>produce this said same datastream.
>
>XML, like ASN.1 is a language and a related syntax to support the
conveyance
>of certain abstractions. Nothing more. Without the BER or DER encoders to
>reduce ASN.1 to its data form.
>
>The fact that no one has one of these tools floating about today is merely
>an inconvience in the bigger picture.
>
>>
>> Frank Balluffi
>> CertCo
>>
>
>Todd
>
>---SNIP---
>
>
>