HDTenEightyP/NetNews huggingface dataset:
From: cudep@warwick.ac.uk (Ian Dickinson)
Newsgroups: comp.protocols.iso.dev-environ,comp.unix.bsd
Subject: Re: ISODE in BSD 4.4 release?
Date: 13 Apr 92 17:06:49 GMT
Organization: Team Limpid's Meathead With Aptitude - Kunst und Wahnsinn

In article <702812270.9645@fxisms.fxis.fujixerox.co.jp> taka@fxis.fujixerox.co.jp (Takahiro Kanbe) writes:
>In article <7382@brchh104.bnr.ca> dawkins@bnr.ca (Spencer Dawkins) writes:
>> I have heard from unreliable sources that BSD 4.4 will include ISODE. Does
>> anyone know if this is true?

I believe so, though the lower layers will be in the kernel with a socket
interface, using the standard ISODE distribution for upper layers.

>I heard so.  But What relation with ISODE Consortium???

Dunno about that, though releases up to 7.0 are freely available.
Upcoming releases will be freely licensable to educational sites.
Where the real nitty gritty comes in.......

Cheers,
-- 
\/ato - Ian Dickinson - NIC handle: ID17                       if (!take(joke))
vato@csv.warwick.ac.uk  ...!mcsun!uknet!warwick!vato               em = fork();
/I=I/S=Dickinson/OU=CSV/O=Warwick/PRMD=UK.AC/ADMD= /C=GB/
@c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson
From: jara@fulcrum.bt.co.uk (Jara Kandhola)
Newsgroups: comp.protocols.iso.dev-environ
Subject: CMIP
Date: 30 Mar 92 17:37:09 GMT
Organization: Fulcrum Communications Ltd., Birmingham, England


Does any one know of CMISE available for use with ISODE ?

Thanks

Jara
From: <csg@able.eng.pyramid.com>
Newsgroups: comp.protocols.iso.dev-environ
Subject: Re: ISODE 7.0 on System 5 Release 4
Date: 9 Apr 1992 05:12:32 GMT
Organization: Pyramid Technology Corp., San Jose, CA
Reply-To: <csg@pyramid.com>
NNTP-Posting-Host: able.eng.pyramid.com
Keywords: SVR4
Originator: csg@able

Oops. Sorry about the botched reply address. New NNTP software, and all.

<csg>
Xref: sparky comp.protocols.iso.dev-environ:103 comp.unix.bsd:721
From: taka@fxis.fujixerox.co.jp (Takahiro Kanbe)
Newsgroups: comp.protocols.iso.dev-environ,comp.unix.bsd
Subject: Re: ISODE in BSD 4.4 release?
Date: 9 Apr 92 09:37:49 GMT
Organization: Fuji Xerox Information Systems Co., Ltd., Tokyo, Japan.
X-Nntp-Posting-Host: aron.nwt.fxis.fujixerox.co.jp
In-reply-to: dawkins@bnr.ca's message of 8 Apr 92 18:06:31 GMT

Hi.

In article <7382@brchh104.bnr.ca>
	dawkins@bnr.ca (Spencer Dawkins) writes:
> I have heard from unreliable sources that BSD 4.4 will include ISODE. Does
> anyone know if this is true? 
I heard so.  But What relation with ISODE Consortium???

--
Takahiro Kanbe <taka@fxis.fujixerox.co.jp>
FXIS / Network Team.
Newsgroups: comp.protocols.iso.dev-environ
From: axel@ubka.uni-karlsruhe.de (Axel Maurer)
Subject: ISODE for OS/2
Organization: University of Karlsruhe, Germany
Date: Tue, 7 Apr 1992 11:33:58 GMT

Does any one know of ISODE available for OS/2 V1.x or 2.0 ?


-- 
Axel Maurer (Maurer@ubka.uni-karlsruhe.de) 
Newsgroups: comp.protocols.iso.dev-environ
From: john@citr.uq.oz.au (John Gottschalk)
Subject: specification languages in OSI
Keywords: Estelle, LOTOS, OSI
Organization: Prentice Centre, University of Queensland
Date: Wed, 15 Apr 1992 06:50:15 GMT


Hello all,

I would like to know of other people's thoughts in using Estelle, LOTOS or Z
in the specification and implementation of OSI application layer services. 
The idea is to use these languages is not just in the specification of the 
services and protocols, but also in the implementation by the use of a
compiler to C or C++ (for example). The discussion should not be mainly 
concerned with the availability of a good compiler, but with the 
suitability of these languages in the implementation of the layer 7 services. 

Regarding the Estelle option, the software design should consider 
whether a mixed implementation should be used (i.e. there would  
be external data types and functions defined in another language), or would
Estelle be used completely as an implementation language. A mixed
implementation could use the strengths of Estelle to specify and implement
the components that it is especially good at, while using another language
for other operations. This appraoch may apply to other specification languages
as well (is this possible?).

Some specific questions which could be answered are:

	* Is a mixed implementation the best approach, or should the
	implementation be based entirely on the specification language.

	* If a mixed implementation is a good idea then what parts should the
	specification language be used for? How much of the software
	would this be approximately (e.g. 10%, 50%, 90%)?

	* How suitable are the languages for the implementation of
	OSI application layer services? For example, the implementation must 
	consider the protocol specification (a finite state machine)
	and the service specification. How useful are Estelle, etc., for
	these parts. Note that experiences in the lower layers may not
	necessarily apply directly to the application layer where there
	is perhaps a relatively smaller protocol specification, and a 
	greater service aspect.

	* Would anybody seriuosly consider implementing an application
	layer service using one of these specification languages?

	* Has anybody implemented an application
	layer service using one of these languages?

Please present other ideas if they are relevant. Also, refer to journal 
articles or other documents if they are useful in the discussion.


If there is plenty of interest then I will summarise the responses.


			-- thanks for your time, John Gottschalk

===================================================================== 
     John Gottschalk (john@citr.uq.oz) 
     Centre for Information Technology Research,
     The University of Queensland, 4072, 
     Brisbane, Queensland, Australia,
     +61 7 365 4321 (phone), +61 7 365 4399 (fax)
=====================================================================
From: buffum@sw.stratus.com (Jeff Buffum)
Newsgroups: comp.protocols.iso
Subject: CMIP ASN1 types - Why no Create error response type?
Date: 9 Apr 92 14:21:45 GMT
Article-I.D.: transfer.2046
Organization: Stratus Computer, Inc.

In the CMIP specification, get, set, delete, and action all have both positive
and negative response types defined in ASN1.  Create only has a positive response
type although section 8.3.4.1 of CMIS indicates error values for a response.  How 
are these errors returned?  Section 8.3.4.2 (procedures) of CMIS says that if an 
error occurs, to ignore the remainder of the section.  It does not provide an 
explanation of what to do.  In section 6.7.3 of CMIP, they indicate that a APDU
should be constructed but not which APDU.

Any help would be appreciated.
-- 
+---------------------------------------------------------------------+
| Jeffrey Buffum                  Phone:    (508) 490-6822            |
| Stratus Computer                Internet: buffum@vos.stratus.com    |
| Marlboro, MA 01752              Fax:      508-624-7488              |
+---------------------------------------------------------------------+
From: baos@caip.rutgers.edu (Bancroft Scott)
Newsgroups: comp.protocols.iso
Subject: Re: negative integers in ObjectIdentifierValue?
Date: 12 Apr 92 13:08:01 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

mds@hpcndaw.CND.HP.COM (Mark Smith) writes:

|>No, it never was the intent to allow the use of negative numbers within
|>an ObjectIdentifierValue.  Note in ISO 8825 (1990), clause 22.2, it states
|>that each subidentifier is an unsigned binary number.

|So then, is there a defect in section 28.4 ??  Should 28.4 be limited to
|a reference to an integer with a non-negative value ?

I agree.  I'll submit it as a defect.

Bancroft Scott
From: zhang@dset.UUCP (Ju Zhang)
Newsgroups: comp.protocols.iso
Subject: Re: C++ posy/pepy
Date: 9 Apr 92 21:41:36 GMT
Organization: DSET Corporation, Lebanon, NJ
Keywords: C++, ASN.C, Second Generation Interface



isode@nic.ddn.mil (Nathan Banks) writes:
>or just pointers and ideas may help me in convincing the decision makers to
>use ASN.1.
>
>Has anyone heard of any work related to creating object oriented ASN.1
>parsers?  e.g. a set of tools (posy++, pepy++) which generate C++ classes
>which encapsulate contents of the ASN.1 message and provides encode, decode,
>and selector operations.

ASN.C from DSET (908-832-6533) will have two interfaces. One is the AC/AD 
preprocessor interface. Another is the C++ interface. It will simply be an 
option of our ASN.1 compiler.

When you compile your ASN.1 source code with -p option, it will generate
a C++ class for every ASN.1 type.

For example, suppose you have an ASN.1 type,

-----------------------------
T ::= SET OF SET OF SET {
                a [1] INTEGER,
                b CHOICE {
			c INTEGER,
			d SET OF INTEGER
		}
        }
-----------------------------

Compile it:

-----------------------------
asn -p test32.asn
-----------------------------

Type T is mapped to a class

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

class D_id0 : 	...

...

class T : public D_nd, public D_rt{
        int size;
        D_id0 *elements;
        public:
        int alloc(int);
        D_id0& operator[](int);
};

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

You don't need to read or understand this mapping. The accessing to fields
will be as if T is mapped to (the AD output from ASN.1 compiler):

-----------------------------
AD_TYPE struct {
    int a;
    union {
        int     c;
        int     d[];
    } b;
} T[][];
-----------------------------

Your application code will look like

-----------------------------
T t_inst1;
char *bufferP;
int  size;

t_inst1.alloc(1);		/* SET has one element */
t_inst1[0].alloc(2);		/* This element has two element */
t_inst1[0][0].a = 13
t_inst1[0][0].b.pick_d();	/* d is selected in CHOICE */
t_inst1[0][0].b.d.alloc(3);
t_inst1[0][0].b.d[1] = 14;
t_inst1[0][1].a = 12

t_inst1.print();

t_inst1.encode(BER, &bufferP, &size);

...

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

See if this sample code can convince your management. Second Generation
ASN.1 tools turn using ASN.1 definition almost as easy as using just 
another type definition in C or C++.

This C++ support will be sent to the ASN.C customers for beta testing
from this summer.

If you don't have to map ASN.1 type to C++ class, we have a more efficient
approach to achieve the same level of development convenience. 



						Ju Zhang

(908)832-7296
-- DSET Co., NJ
Newsgroups: comp.protocols.iso
From: sklower@diva.Berkeley.EDU (Keith Sklower)
Newsgroups: comp.protocols.iso
Subject: Re: IP Encapsulation in CLNP (ISO 8473)
Date: 13 Apr 92 06:03:59 GMT
Organization: /etc/organizaton

In article <1992Apr8.170023.836@tridom.com> sat@tridom.uucp (Stephen Thomas) writes:
>Actually, my original post was not purely academic. I do indeed need to
>transport IP traffic across a network that only understands ISO. In fact,
>I also need to be able to transport DECnet (phase IV), IPX, XNS, ... across
>the same network.

I have the impression that the dual - ISIS draft says something
at the very least about encapsulating IP packets in CLNP pdu's
(for partition repair).  If my memory is correct, the encapsulation
is to use a CLNP pdu with NSAP having the final byte (NSEL) being 0,
and have the first data byte be 0xcc.

Other identifiers could be drawn from the space specified by
ISO TR9577 (I believe -- I'm working from home and don't have
the magic numbers with me).  This is something about protocol
identifiers in the network layer.

the CCITT has reserved 0x80 for 802.2 encapsulation, so you
could also use SNAP headers for XNS, or whatever else SNAP
buys you (Like 802 bridging?).  You might also want to look at
the internet draft about mutliprotocol over frame relay.
From: hta@boheme.er.sintef.no (Harald Tveit Alvestrand)
Newsgroups: comp.protocols.iso
Subject: Re: IP Encapsulation in CLNP (ISO 8473)
Keywords: IP CLNP CLNS 8473 ISO OSI
Date: 7 Apr 92 06:50:40 GMT
Reply-To: harald.alvestrand@delab.sintef.no
Organization: SINTEF DELAB, Norway

In article <1992Apr5.155151.5567@newshost.anu.edu.au>, cmf851@huxley.anu.edu.au (Albert Langer) writes:
|> 
|> Alternatively, instead of running X.25 PLP over TCP,
|> TCP could be treated as a Permanent Virtual Circuit and a single channel
|> CONS provided over that. The TCP "urgent data" pointer could be used to
|> mark the end octet of each DLSDU or NPDU for the "data link" version or
|> similar for a "network layer" version (e.g. using the T.70 "minimal
|> network layer" 2 octet headers plus the TCP acknowledgement status for an 
|> equivalent to the X.25 PVC with full Q bit and D bit facilities).
|> 
As usual, I stick to what I know, ignoring the thornbushes that line
the path.....
I had this idea also (about using the URG pointer for something).
I actually checked it with Jon Postel at the time (1984):
When a recipient is reassembling TCP segments, and finds the sequence


(byte 12 to 72; URG at 73)
(byte 73 to 112; URG at 113)

it is perfectly legal to return to the user bytes 12 to 112, and only signal
the URG at position 113.
So URGs are useless for anything other than their stated purpose: To indicate
to the recipient that there is urgent data somewhere down the data stream.
It gives no help in finding out where the urgent data actually is.

-- 
                   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
Xref: sparky comp.protocols.iso:633 comp.std.internat:501 comp.text.sgml:538
From: jxr@thumper.bellcore.com (Jonathan Rosenberg)
Newsgroups: comp.protocols.iso,comp.std.internat,comp.text.sgml
Subject: Re: ODA information wanted
Date: 16 Apr 92 21:13:56 GMT
Organization: Bellcore

From: richardb@cognos.uucp (Richard Brosseau)
Newsgroups: comp.protocols.iso,comp.std.internat,comp.text.sgml
Subject: ODA information wanted
Date: 16 Apr 92 15:32:39 GMT

> I'm looking for tow ODA related tools :

> - An ODA programmer toolkit. I remember reading about one available some
>  time ago. I think it was from CMU.

There was an ODA tool kit developed at CMU & made freely available for
use as part of the MIT X Distribution.  I believe that the tool kit was
not part of the latest X distribution.  But, I believe it is still
available from somewhere for free or a small fee.  I have cc'ed this
message to two of the other developers of this tool kit (I was also
one), who I believe can answer these questions.  I hope they will answer
directly to these newsgroups.

Complete documentation for this tool kit can (only) be found in the book

	Multi-media Document Translation: ODA & the EXPRES Project
	Jonathan Rosenberg, Mark Sherman, Ann Marks & Jaap Akkerhuis
	Springer-Verlag
	ISBN 0-387-97397-4
	ISSN 3-540-97397-4	

> - Any ASN.1 compilers. I know of at least one. Probably more are available.

I know of 2 such tools (there are undoubtedly more):

	- one in the ISODE package (known as PEPY, as I recall)
	- another one we are currently planning to use (I can't recall the details
	  bount this one.  I have cc'ed a colleague (Darren New) who has the
	  detailed info on this package

> Can anybody send me the names of companies that sell/give these?

Done.

> Please reply via e-mail, as my news system expires articles quickly.
> Thanks...

Ok.

> -- 
> Richard Brosseau - Cognos Incorporated  UUNET:uunet!cognos.uucp!richardb
> BITNET:ccs.carleton.ca!cognos.uucp!richardb

Jonathan Rosenberg
Director, Information Networks Research
Bellcore
Morristown, NJ
USA
Newsgroups: comp.protocols.iso
From: maffeis@ifi.unizh.ch (Silvano Maffeis)
Subject: ISO norms: where?
Organization: University of Zurich, Department of Computer Science
Distribution: comp.protocols.iso
Date: Tue, 7 Apr 92 07:39:50 GMT

Hello!

I'm seeking ftp-archives providing downloadable iso-norm specifications.
Any hint is appreciated.

Silvano Maffeis


-- 
Silvano Maffeis, CS Dept. University of Zurich, Switzerland
  email: maffeis@ifi.unizh.ch  
  voice: +411 257 43 27
Newsgroups: comp.protocols.iso
From: mskuhn@cip.informatik.uni-erlangen.de (Markus Kuhn)
Subject: Re: Getting ISO/CCITT documents off the NET?
Organization: Student Pool, CSD, University of Erlangen, Germany
Date: Wed, 8 Apr 1992 12:54:49 GMT

csg@pyramid.pyramid.com (Carl S. Gutekunst) writes:

>It's also worth mentioning that the documents available in the experiment
>were not useful.  Many of the most important were missing (like almost all
>of the X series), and most of those that were present had such severe
>formatting problems and missing pieces that they could not be trusted. 

>The reality is, if you are implementing CCITT and ISO protocols, you are
>going to have to shell out serious bucks. If you are not implementing, and
>just want to know how the stuff works, then get a copy of Marshall Rose's
>"The Open Book." You won't be able to read the standards, anyway.

It's also worth mentioning that the non-availability of ISO documents for
students and university members who just want to have a quit look at a
special detail is one of the reasons, why ISO standards aren't as popular
as other standards which ARE available over the net.

This especially true for small standards (e.g. ISO formats for day and time,
ISO format for geographical positions) were the costs and time needed to get
the documents are an order of magnitude worse than the costs and time for
implementing them.

An other example: I spent the last 3 weeks with implementing an asynch
LAPB / X.25 prototype for MS-DOS. It took me longer than 3 weeks to get
the people here to order the ISO specifications. For every new detail
(e.g. another HDLC-XID-parameter field for address resolution), I have to
wait some weeks and search people who spent $50 for a few ISO pages.
ISO really isn't encouraging people who want to implement public domain
software according to their standards in their spare time!

I want to have the complete data that will also be used to produce the paper
documents in one single format (including graphics, formulas, tables, ...),
e.g. SGML.

Is this really impossible in the information technology age?

Markus

---
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
Don't worry over what other people are thinking about you. ----------------
---------- They're too busy worrying over what you are thinking about them.
From: mds@hpcndaw.CND.HP.COM (Mark Smith)
Date: Wed, 8 Apr 1992 17:41:56 GMT
Subject: negative integers in ObjectIdentifierValue?
Organization: HP Colorado Networks Division
Newsgroups: comp.protocols.iso

While I'm sure this was not the intent, it appears that negative integers
are valid within an ObjectIdentifierValue.

My reasoning is thus:

   ISO/IEC 8824: 1990 states

   NumberForm        ::= number | DefinedValue
   NameAndNumberForm ::= identifier (NumberForm)

   28.4 The "DefinedValue" in "NumberForm" shall be a reference to a value
   of type integer, or of a type derived from integer by tagging.


Since section 28.4 does NOT restrict DefinedValue to be a reference to a
non-negative integer value, it appears valid to use negative integers in
an ObjectIdentifierValue.

Does 8824 specifically disallow negative integers in an ObjectIdentifierValue?
If so, where?

Has the intent always been to allow the use of negative integers?


Mark Smith
Newsgroups: comp.protocols.iso
From: mskuhn@immd4.informatik.uni-erlangen.de (Markus Kuhn)
Subject: DFR for anonymous archives vs. FTAM
Organization: CSD., University of Erlangen, Germany
Date: Mon, 13 Apr 1992 13:01:06 GMT

At present nearly all public domain files in the netland are available
with the FTP protocol. This is a widely used but not very comfortable
solution.

What do you believe OSI has to offer as an alternative?

Well, most people I asked about this told me: FTAM. Yes, FTAM has a number of
advantages, e.g. together with the latest Amendment 1, it has a well defined
machine readable directory format, which would allow nice GUI applications,
but this is not enough for archives.

The optimal protocol should not just offer access to a UNIX type filesystem
as FTP or FTAM do. There you only get a list of quite cryptic filenames and
you always have to read README files before you know which file you want to
download.

It would be fine to have a protocol which provides things like

   - free names for files/documents (e.g. with spaces, ISO 10646 characters).
   - for comfortable browsing attributes like a one-line-description of
     the file contents
   - an attribute that contains a longer description like the README file
     in many of today's *.tar.Z files. I want to be able to read this
     attribute before I load the whole package.
   - attributes like author, version number, keywords, ... in order
     to make browsing through the archive more comfortable.
   - search operations for keywords, author, names ... (a de luxe archie).
   - distributed search operations
   - a well defined unique identifier for each document
   - all attribute contents should be as much machine readable
     as possible in order to allow developping comfortable
     browsing tools.

Both FTP and FTAM have far less capabilities and are not the optimal
choice for a public file archive system.

Can anyone tell me whether the ISO DFR (document filing and retrieval)
protocol and service (ISO 10166) describes a better alternative?

Markus

---
Markus Kuhn, Computer Science student -=-=- University of Erlangen, Germany
Internet: mskuhn@immd4.informatik.uni-erlangen.de  |  X.500 entry available
Don't worry over what other people are thinking about you. ----------------
---------- They're too busy worrying over what you are thinking about them.
From: vlachopo@nunki.usc.edu (Panagiotis Vlachopoulos)
Newsgroups: comp.protocols.iso
Subject: SRP - CRC
Date: 7 Apr 1992 20:44:22 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: nunki.usc.edu
Summary: Trivial but valuable...
Keywords: SRP - CRC


Hi Netters,
I am searching for two things:

(1)     A simulation of the Selective Repeat Protocol written in ANY
computer language. It will be used to calculate and plot the efficiency
of the protocol vs. buffer size. (I know it's in Tanenbaum, but I'd
rather have it in anything else than Pascal).
(2)     A piece of code that calculates CRC's for a given generator.

As I'm not reading this group I would like to have any responses
sent to panosv@theseas.ntua.gr
Thanx in advance :-)
From: csg@pyramid.pyramid.com (Carl S. Gutekunst)
Newsgroups: comp.protocols.iso
Subject: Re: Getting ISO/CCITT documents off the NET?
Date: 7 Apr 92 19:03:53 GMT
Distribution: comp
Organization: Pyramid Technology Corp.

>The net result is that there are a lot of electronic copies out there,
>but it is not legal to make them available for anonymous FTP after
>December 31, 1991.

The "net" result? :-)

It's also worth mentioning that the documents available in the experiment
were not useful.  Many of the most important were missing (like almost all
of the X series), and most of those that were present had such severe
formatting problems and missing pieces that they could not be trusted. 

The reality is, if you are implementing CCITT and ISO protocols, you are
going to have to shell out serious bucks. If you are not implementing, and
just want to know how the stuff works, then get a copy of Marshall Rose's
"The Open Book." You won't be able to read the standards, anyway.

For standards, the U.N. Bookshop in New York offers the best price for CCITT
Blue Books; ANSI and IEEE you get from National Technical Information Service
(NTIS) in Washington; ISO from Omnicom. The McGraw-Hill Encyclopedia of Data-
communications Standards is the best buy for a cross-section of standards,
and is highly recommended for any development group.

<csg>