🚀 go-pugleaf

I guess we need an "ISO standards FAQ" with this question answered and
mailed weekly to a number of newsgroups.

ISO standards are copyright by the International Organization for
Standardization.  ISO depends on the proceeds from the sale of the
standards to cover their operating costs.  They also maintain that
electronic copies can get out of control, i.e. be tampered with and
destroy the credibility of ISO standards, and to the advancement of the
tamperer's causes, such as a company which isn't able to conform 100% to
the requirements, and slightly modifies them, or removes the trickiest
ones.  ISO standards are available from ISO headquarters in Geneva, or
from your national ISO member body (ANSI in the U.S.).  ISO standards
are not government publications, either.

CCITT recommendations are copyright by the Comite Consultatif
International de Telegraphique et Telephonique.  CCITT publishes all its
recommendations every four years.  The last complete publication was in
1988, with the Blue Book.  The next edition is probably the White Book,
in 1992, but not available until sometime in 1994 or 1995, due to
printing and distribution constraints.  CCITT recommendations are
available from CCITT headquarters in Geneva, or from your local telecom
regulatory body.

You won't find documents from either of these organizations available
for FTP anywhere, at least not anywhere where the law is respected.

In summary, you should expect to spend a small amount of the money you
save from your net.access on paper documents.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.

enag@ifi.uio.no (Erik Naggum) writes:


>ISO standards are copyright by the International Organization for
>Standardization.  ISO depends on the proceeds from the sale of the
>standards to cover their operating costs.  They also maintain that
>electronic copies can get out of control, i.e. be tampered with and
>destroy the credibility of ISO standards, and to the advancement of the
>tamperer's causes, such as a company which isn't able to conform 100% to
>the requirements, and slightly modifies them, or removes the trickiest
>ones.  ISO standards are available from ISO headquarters in Geneva, or
>from your national ISO member body (ANSI in the U.S.).  ISO standards
>are not government publications, either.

While the above is certainly ISO's policy on the matter, it is an
unfortunately policy which is contributing to OSI's failure in the
marketplace. The free exchange of standards documents provides a
springboard for the development of compatible products.  As for the
danger of tampering, this is nonsense.  What do you think would happen
to a producer of a TCP/IP product which didn't interoperate with the
net?  Claims that their spec document was defective aren't going to
buy them a thing.  If ISO provided the documents online, the quality
ftp cites would carry them and no problems would occur.

>In summary, you should expect to spend a small amount of the money you
>save from your net.access on paper documents.

Not a small amount from what I recall.  Certainly not for a college
student seeking to explore.

James S. Vera      |         Internet           |Standard Disclaimers
Stanford University|   vera@anna.stanford.edu   |Blah Blah Blah Blah
+1.415.723.1089    |    FAX +1.415.725.7398     |

Note that at the last IETF, one guy was trying to collect signatures
in order to make the US Congress make ANSI put the ISO standards
on-line. If anyone in the US is interested in supporting this,
I suggest that someone tries to remember the guy's name.....
(as a non-US citizen, I don't think Congress pays much attention to me)
-- 
                   Harald Tveit Alvestrand
Harald.Alvestrand@delab.sintef.no
C=no;PRMD=uninett;O=sintef;OU=delab;S=alvestrand;G=harald
+47 7 59 70 94

> I guess we need an "ISO standards FAQ" with this question answered and
> mailed weekly to a number of newsgroups.
	Yes, that would probably be appropriate... particularly given
the number of us used to having RFC's and IETF working papers online.
(It is extremely useful to wais-search (or even grep) for a particular
concept, such as "out of band messages" and find the standards that
refer to it...)
	I suppose I should withdraw my earlier reference to the
"European" network standards process when refering to ISO, thanks to
the gentle correction of another reader (who pointed out that ANSI is
an ISO member :-) ANSI standards aren't available online either, I've
heard this is also because they make back operating expenses by
charging for them. (I've never heard "tampering risk" suggested
seriously as a reason not to publish them in electronic form -- if
you consider it a threat, you can either put them up yourself (or get
other parties you trust to do it) or simply put some sort of digital
signature on the document.)
	I did receive a pointer to a doc that satisfied my original request:
>> The file ASN.1.ps.Z on ftp.uni-erlangen.de in pub/doc/ISO/english
>> contains an introductory text about ASN.1 and the basic encoding rules.
	This paper is "A Layman's Guide to a Subset of ASN.1, BER, and
DER" by Burton S. Kaliski Jr. of RSA DSI; it is written with an
emphasis on parts of ASN.1 needed to implement the PKCS standards.  It
refers to CCITT X.208 and X.209, not to the ISO documents -- perhaps
the above mentioned FAQ should explain the meaning of the distinction
between CCITT and ISO. (Erik Naggum's description of the two groups
was clear, but it didn't explain why the CCITT makes recommendations
in the first place, or which direction the standards flow...)
	Thanks for your patience. I suspect these questions are coming
up more often (from American developers, at least) due to the growing
use of SNMP, RSA PEM, and Kerberos version 5, specifications for which
are freely available yet which rest on ASN.1 in particular which is
not.
				_Mark_ <eichin@athena.mit.edu>
				MIT Student Information Processing Board

James S. Vera <vera@fanaraaken.Stanford.EDU> writes:
|
|   While the above is certainly ISO's policy on the matter, it is an
|   unfortunately policy which is contributing to OSI's failure in the
|   marketplace.  The free exchange of standards documents provides a
|   springboard for the development of compatible products.  As for the
|   danger of tampering, this is nonsense.  What do you think would
|   happen to a producer of a TCP/IP product which didn't interoperate
|   with the net?  Claims that their spec document was defective aren't
|   going to buy them a thing.  If ISO provided the documents online,
|   the quality ftp cites would carry them and no problems would occur.

Please note that the International Organization for Standardization is
much, much more than Open Systems Interconnection, and that ISO has a
real concern for the integrity of their standards in a much wider
context than the connected networks.  The standards are copyright ISO
and sold through authorized outlets, so that you know you get a real ISO
standard when you buy one.  Since most end users of ISO standards and
ISO standard conforming products don't even know ISO exists, much less
want to read the specifications, it would be a simple matter for one
vendor to edit out the hardest parts to implement, increase an error
margin, or whatever, and to supply the customers with this copy.  This
would be much easier if they were electronically available, and ISO has
a real concern that ISO standards would be diluted if a tight control
over their integrity is not maintained.  Considering the many companies
who already claim their deficient software and systems are conforming, I
certainly understand this attitude.

Now, you can't compete with something which is freely available, such as
the RFC's.  RFC's also have built-in integrity checks in that anyone,
wherever they are on the connected Internet, can FTP to nic.ddn.mil and
grab the authoritative copy with no delta cost.  We all know that
getting on the connected Internet isn't exactly free, though.  In fact,
I can't go anywhere and "buy" Internet connectivity off the shelf.  Then
there's the Acceptable Use Policy, which means the customer can't use
the network for many of his needs, _if_ he gets connected in the first
place.  For _us_ on the inside, the RFC's are free, but for _them_ on
the outside, they are essentially not available, except by the favor of
a nearby University or direct-ordered from the NIC, ordering info being
available on the net.

You can say whatever you want about OSI, but ISO and CCITT aim at having
the networks operate in the commercial world with commercial up-time and
no silly restrictions on what you send on the wire.  They also think
it's fair that anyone can buy their standards from them or from national
member bodies, and not have to be connected before they can get things.

|   Not a small amount from what I recall.  Certainly not for a college
|   student seeking to explore.

This situation is new to ISO.  Never before have their standards been of
such interest to more than vendors and manufacturers.  Academia has been
actively hostile towards ISO and standards which "thwart" creativity and
are big and unimplementable by your favorite graduate student and would
ruin the University library if he should want access to all of them on
the same basis that he expects to have access to other documentation.

We should stop staring so intently at our navels and realize that we're
damn lucky and privileged to live in the electronic society where
information flows with no delta cost, and that we can't expect to see
this happen to the rest of the industrialized world for decades to come,
if ever.  When computer networks connections are as ubiquitous as the
telephone wall sockets (and we're not talking ISDN, here, mind you; it
isn't even enough for personal use) and the hub computers are big enough
to handle thousands of FTP sessions to retrieve multi-megabyte pictures
and other wasteful multi-media "infotainment" for the masses, you should
also be able to retrieve documentation and standards for "free", meaning
that your 50M standards documents is delivered to your computer in about
25 millisecond (AT&T plan to have 8Gbps pipes to all residences and
offices with an expected throughput of 2Gbps), at a cost so marginal
that you would perhaps have to do without a lump of sugar for your cup
of coffee to afford it.

We're living on the forefront of available technology, and we enjoy it
immensely, but we should never forget that this forefront costs a hell
of a lot of money which mostly governments have poured into "research"
so we can complain to each other that ISO documents aren't as free as
the T1 we have to the the T3 backbone, either of which we didn't pay
for ourselves.

We've got to understand that this is luxury, paid for by taxes and the
infrequent private donation to give a few people the knowledge and
vision to shape the future for the rest of the people.  We should not be
so damn snotty about it that we don't want to stoop to the level of mere
mortals and pay for things once in a while, no matter how much we "need"
it or "could use it" or for whatever beneficial academic cause we can
dream up.

Notwithstanding the disgusting company which used this slogan first, ISO
attends to the needs of the rest of the people, and the rest of the
people are going to pay for the standards that the manufacturers had to
buy for what seems like much money to a college student with a miniscule
fraction of the end product cost.  If the manufacturers had people on
the ISO committees, the cost of the standards themselves are blown out
of the water by costs three of four orders of magnitude larger for
sending experts all over the world to luxury hotels to twist a phrase
here and phrase there and perhaps reach a compromise about which people
in academia are going to spend megabytes of complaints and cries of
"mindless, OSIfied requirements" in comp.protocols.iso and elsewhere.

The procedure and the results can be understood and appreciated, but it
requires that your favorite academic institution and/or company is
willing to pay for the forest ISO kills every year in preparing
standards for, among other things, electronic document interchange.  (I
know, it's laughably tragic.)  I can do it, and I'm a lowly undergrad
(still) at the University of Oslo doing some consulting jobs whenever I
need money, and benefiting so much from the U of Oslo's Internet link
that I probably couldn't pay for comparable services if I worked 14
hours a day year 'round.  I consider spending about $5,000 on ISO and
CCITT standards over a three-year period to be affordable, especially
since I don't smoke or drink, and walk to the U and don't incur the
"normal" society's cost of living.  The U gets my expertise back for
free, and so does comp.text.sgml, where I write the most.

Maybe I'm just stupid, but I figured that if I wanted to learn about
this, spending a year doing so is more costly than the standards, and I
would use more money on textbooks than standards had I aimed at getting
credit points with the same level of effort I invest in standards.
Considering that I've become one of the world's handful of experts on
SGML and can reap high consulting fees now and hopefully a high salary
some years down the road, this is not such a bad deal.

Take a look at the price commercial enterprises pays for OSI courses.
If you buy the OSI standards set, and learn enough about them with the
normal academic quality standards (which are *way* higher than the
commercial quality standards), you should be able to make a killing
teaching other people, helping manufacturers and developers, etc, etc.
I manage to make a living working perhaps 12 weeks a year.  You can do
it, too, if you put your money where your mouth is and make a longer-
term cost-benefit analysis than this "Waaah, I can't get ISO 10744 with
FTP."

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.

Mark W. Eichin <eichin@athena.mit.edu> writes:
|
|	   This paper is "A Layman's Guide to a Subset of ASN.1, BER, and
|   DER" by Burton S. Kaliski Jr. of RSA DSI; it is written with an
|   emphasis on parts of ASN.1 needed to implement the PKCS standards.  It
|   refers to CCITT X.208 and X.209, not to the ISO documents -- perhaps
|   the above mentioned FAQ should explain the meaning of the distinction
|   between CCITT and ISO. (Erik Naggum's description of the two groups
|   was clear, but it didn't explain why the CCITT makes recommendations
|   in the first place, or which direction the standards flow...)

OK, I'll give it a shot.  CCITT made this OSI concept, not ISO.  ISO has
a track record of adopting useful standards wherever they are found, but
mistakenly thought CCITT's involvement in telematic services and higher
level stuff was useful, probably in the belief that the world's best
experts in wires, transmission, and other low-level communications stuff
also knew what people put their expertise to use for.  CCITT recommend-
ations are just that -- recommendations -- which the members of ITU, the
International Telecommunications Union, which are mostly government-run
monopoly telephone companies and the occasional Recognized Private
Operating Agencies (RPOA), known to CCITT as "Administrations",
generally adopt as their working procedures.  CCITT also cater to all
kinds of policy required to allow ITU members to use each other's
networks for transit, and has hairy protocols (the people-to-people
type) to set prices and thus allow international minimal connectivity.
The Internet could learn something from this, and I believe the IETF has
contacted CCITT to maybe let them handle the clearing processes involved
in a commercial Internet.

X.208 and X.209 are identical to ISO 8824 and ISO 8825, as amended.
You can get the X.200 series recommendations for about the price of the
cover page of ISO 8824 (well, not really, but substantially cheaper),
and ISO and CCITT work very hard to have their respective standards and
recommendations "technically aligned".  Had I known this a before I
bought ISO 8613 for several hundred dollers, I could have acquired T.400
for about one fourth of the cost.  Look closely before you buy.

|   Thanks for your patience. I suspect these questions are coming up
|   more often (from American developers, at least) due to the growing
|   use of SNMP, RSA PEM, and Kerberos version 5, specifications for
|   which are freely available yet which rest on ASN.1 in particular
|   which is not.

Hmmm.  ASN.1 has received much input from some RFC, and so has this
entire X.400 mess, let's see...  (grep'ing in the background :-)

841   National Bureau of Standards; NBS  Specification for message format for
      Computer Based Message Systems.  1983 January 27; 110 p. (Format:
      TXT=238774 bytes)  (Obsoletes RFC 806)

RFC 841 contains a rudimentary ASN.1 specification, due to the fact that
ASN.1 grew up in the message-handling world, or X.400 series, but was
found to be useful as a general mechanism and now lives in the X.200
series.

ASN.1 is really a quite simple and neat specification, once you get
through the language barrier that all ISO standards and CCITT
recommendations suffer from, but the BER is evil, both in specification
and in practice.  CCITT is said to suffer to "bitophobia" (abnormal fear
of wasted bits), and rather thinks that by the time anyone actually
implements ASN.1 BER, the computers won't notice the overhead in
unwinding the BER integer and floating-point formats.  (Sorry, this is
getting out of hand.)

I'll probably regret sending this.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.

In <23311C@erik.naggum.no> enag@ifi.uio.no (Erik Naggum) writes:

>...it would be a simple matter for one
>vendor to edit out the hardest parts to implement, increase an error
>margin, or whatever, and to supply the customers with this copy.  This
>would be much easier if they were electronically available...

Hmmm...have you ever tried running "diff", "sum", "crc", "md4", or
"brik" on documents printed on paper?
-- 
Rahul Dhesi <dhesi@cirrus.com>
also: dhesi@rahul.net

enag@ifi.uio.no (Erik Naggum) writes:

>ASN.1 is really a quite simple and neat specification, once you get
>through the language barrier that all ISO standards and CCITT
>recommendations suffer from, but the BER is evil, both in specification
>and in practice.  CCITT is said to suffer to "bitophobia" (abnormal fear
>of wasted bits), and rather thinks that by the time anyone actually
>implements ASN.1 BER, the computers won't notice the overhead in
>unwinding the BER integer and floating-point formats.  (Sorry, this is
>getting out of hand.)

The "bitophobia" exhibited by CCITT is quite justified.  There are 
existing applications that are forced to operate with a very small
bandwidth (e.g., cellular radio control, ground to aircraft control, etc.)
and thus cannot afford to waste a single bit.  Indeed, it is a demonstrated
need by several sectors of industry that has lead to the development
of the Packed Encoding Rules of ASN.1 (PER).  PER exhibits a far more
severe case of "bitophobia" than BER even dreamt of, but satisfies the
needs of those applications that find BER too verbose.

=====================================|========================================
Bancroft Scott			     |		Open Systems Solutions, Inc.
609-987-9073			     |		Princeton, N.J.
=====================================|========================================

In article <EICHIN.92Aug19032948@tsx-11.mit.edu>, eichin@athena.mit.edu (Mark W. Eichin) writes:
...

> 	Thanks for your patience. I suspect these questions are coming
> up more often (from American developers, at least) due to the growing
> use of SNMP, RSA PEM, and Kerberos version 5, specifications for which
> are freely available yet which rest on ASN.1 in particular which is
> not.

This gave me the idea for a quick survey of current ASN.1 use. 

The aim is to come up with a list of projects  (i.e. standards, private 
implementation projects etc.) that use ASN.1, but do not belong to the "classic" 
OSI upper layer standards. Things to be included in this list are e.g. SNMP, 
RSA PEM (what is this ?), Kerberos, and I remember someone at Thinking Machines was
working on a WAIS implementation that uses ASN.1 (this would be a 'private project'). 

This would give valuable feedback to ASN.1 compiler writers as to what
applications their compilers should aim at. Also, it would give an indication
to how "successfull" ASN.1 has been up to now outside its originally intended OSI
scope (quite successful, apparently, if it even made it to RFC's :-)).

The following questionaire might help you to describe the project. You may add further
points, of course. You can describe stuff you just heard/read about, or projects you did
yourself.

Name of project:

Short description of the project:

Documents describing the project:

For what specific purpose is ASN.1 used:

Any ASN.1 macros used:

Difficulties experienced when using ASN.1:

Which ASN.1 compiler was used:

In order to prune duplicates: 
PLEASE REPLY directly TO ME, I'll summarize (hoschka@sophia.inria.fr)

About a week ago I posted a message asking for any projects that
do not use OSI standards, but make use of ASN.1. The following is
the summary of the responses I got (thank you all again), and some data I
compiled myself from the literature.

In summary, ASN.1 is used in the following non-OSI projects:
- Kerberos (authentication protocol), 
- WAIS (information server access protocol), 
- ODA/ODIF (document interchange format), 
- SNMP (Network management protocol), 
- database front-end protocol, 
- trading-room industry protocol,
- digital video interchange protocol.

As appendix you find a detailed description for each project.

----------------------------------------------------------------------
   Philipp Hoschka              |   INRIA-Rodeo
   hoschka@sophia.inria.fr      |   2004, Route des Lucioles, BP 93
   Ph: (+33) 93 65 77 47        |   06902 Sophia Antipolis Cedex
   Fax:(+33) 93 65 77 66        |   France
----------------------------------------------------------------------

DETAILED SUMMARY:

-----------------------------------------------
Name of project: Kerberos version 5

Short description of the project: Kerberos is an authentication protocol to
      verify the identity of users, workstations, etc, developed in Project 
      Athena at MIT.

Documents describing the project: 
	  Kohl, John and Clifford Neumann. "The Kerberos Network Athentication
	   Service." Internet-Draft. (draft-ietf-cat-kerberos-00.txt)

For what specific purpose is ASN.1 used: to define the PDU's exchanged between
	 a client and an authentication server or an application server, 
	 respectively. Uses distinguished encoding rules.

Any ASN.1 macros used: None

Which ASN.1 compiler was used: The Athena implementation uses the ISODE tools.

------------------------------------------------------------

Name of project: ODA/ODIF (Open Document Architecture, Open Document
     Interchange Format

Short description of the project: ODA is an ISO (but not OSI) standard for
      document interchange.

Documents describing the project: 
	  - ISO-8613-1,-2,-4,-5,-6,-7,-8
	  - Rosenberg, Jonathan, Mark Sherman, Ann Marks and Jaap Akkerhuis.
	  Multimedia document translation: ODA and the EXPRESS project.
	  

For what specific purpose is ASN.1 used: The ODIF standard (part 5) uses ASN.1
    to define the format of the data stream to interchange office documents
    structured according to ODA. Standards defining specific content 
    architectures (characters (part 6), raster graphics (part 7), geometric 
    graphics (part 8)) also use ASN.1.

Any ASN.1 macros used: None (?)

Which ASN.1 compiler was used: The EXPRESS project used the ISODE tools.

------------------------------------------------------------
Name of the project: SNMP (Simple Network Management Protocol)

Short description of the project: SNMP serves to exchange information between
      network management software and managed network devices. It is in 
      widespread use today.

For what specific purpose is ASN.1 used: ASN.1 is applied for two purposes in 
    SNMP: Firstly, it is used to define the PDU's of the protocol. Secondly, 
    it is used to define the structure of the database of objects that can be 
    queried and changed in a managed network device by using the protocol - 
    the MIB (Management Information Base).

Documents describing the project:
	  - "A Simple Network Management Protocol" (incl. PDU's in ASN.1): 
	    RFC 1157
	  - "Structure and Identification of Management Information for 
	      TCP/IP-based Internets", RFC 1155
	  - "Management Information Base for Network Management of 
	    TCP/IP-based Internets", RFC 1157
	    (these are only the base documents - for further MIB-related RFCs,
	     see your local RFC server ....)
	  - Rose, Marshal. The simple book. Englewood Cliffs: Prentice Hall, 
	    1991.

Any ASN.1 macros used: OBJECT-TYPE macro defined in RFC 1155

Difficulties experienced when using ASN.1:
or rather simplifications made to ASN.1 (because of difficulties ?):
   - only subset of all ASN.1 types may be used in MIB: Integer, Octet String,
     Sequence (without optional components), Sequence-of, Object Identifier, 
     Null
   - only two subtyping notations may be used: size-constraints, value-range
     constraints
   - use of indefinite length form in BER encodings prohibited

Which ASN.1 compiler was used: 
      - Rose describes use of PEPSY and MOSY (special tool to process 
	OBJECT-TYPE macro).
      - An SNMP implementation that does not use an ASN.1 compiler is
	described in:
	Comer, Douglas, David Stevens. Internetworking with TCP/IP - Volume
	II. Englewood Cliffs: Prentice Hall. 1991

--------------------------------------------------
Information provided by: ses@simon.demon.co.uk

Short description of the project: WAIS is an implementation of NISo Standard 
      Z39.50 1988, which was developed pre ASN.1. The 1992 version of the 
      protocol is specified in ASN.1, hence the change. Note that the 
      profile specified for use on the Internet specifically forbids the use 
      of the session and presentation layer protocols; raw BER is fed 
      directly into TCP.

For what specific purpose is ASN.1 used: Protocol and some datatypes. In one 
    version an ASN.1 interpreter is used to allow recdord types to be defined
     on the fly.

Any ASN.1 macros used: None.

Difficulties experienced when using ASN.1:Implementing the interpreter (Why 
	     can't OSI ever decide between competing ideas instead of 
	     mandating them all).

Which ASN.1 compiler was used: Interpreter, actually :-). One version uses 
      interpreter, other is hand-coded (or will be when I get it finished). 
      Other implementors of Z39.50 have used ISODE, plus various whacky stuff
      on IBM mainframes- Melvyl was done in Pl/1 + assembler, hand coded. 
      The official IBM product had serious problems with recursive data 
      types.

---------------------------------------------------
Information provided by: mitra@pandora.sf.ca.us 

Sorry I cant answer all your questions, this is a commercial project,
and I am bound by non-disclosure.

Name of project: Pandora database front-end 

Short description of the project: Initial phase involves producing a 
      client-server database access project for specific databases on a 
      specific host. User's accessing via modem

Documents describing the project: None at present

For what specific purpose is ASN.1 used: Refining and extending Z39.50 
    to meet specific needs

Any ASN.1 macros used: None so far

Difficulties experienced when using ASN.1: Obtaining documentation,
	     specifically of ASN.1 itself, current versions of the standard 
	     in machine readable form. Finding a compiler.

Which ASN.1 compiler was used: None yet - have not received replies
      to emailed requests for documentation and pricing on compilers.

------------------------------------------------
Information provided by: Paul Andon <pandon@micrognosis.co.uk> 

Status: Private project

Name of project: URD

Short description of the project:
        Aimed primarily at the trading room industry, 
        the Universal Record Distribution (URD) protocol 
        is a connectionless realtime reliable transport
        level protocol for transporting variable length 
        records on a one to many basis.

Documents describing the project: Confidential

For what specific purpose is ASN.1 used:
        Unlike most high-performance realtime protocols
        nearly all fields in URD were of variable length.
        ASN.1 was used primarily as a definition language
        with which to define all inter-host and inter-process 
        URD messages.  ALL encodings were done manually in 
        order to "guarentee" performance.  The intention is
        to make use of ASN.1 compilers when peformance of 
        generated code becomes acceptible.

Which ASN.1 compiler was used: none 

----------------------------------------------
Information provided by: "David C. Carver" <dcc@Athena.MIT.EDU>

Short desription of the project:
For what specific purpose is ASN.1 used:
    I'm currently working in a taskforce in the Society of Motion Picture 
    and Television Engineers (SMPTE) and we are considering the use of ASN.1 
    to implement headers and descriptors for digital video interchange.