HDTenEightyP/NetNews huggingface dataset:
From: petja@xopen.co.uk (Petr Janecek)
Newsgroups: comp.std.unix
Subject: Re: Information on X/Open Transport Interface (XTI)
Date: 8 Sep 1992 13:58:24 -0700
Organization: UUNET Communications
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: petja@xopen.co.uk (Petr Janecek)

 With respect to the request below and any other similar ones:

> I am looking for information on XPG's X/Open Transport Interface (XTI).
> Firstly, is it Posix compliant? If it is, what are the Unix vendors
> that support this API?

 1. Since there is no POSIX standard for Detailed Network Interface yet,
    XTI can hardly comply with it. However, the P1003.12 group at POSIX has
    chosen XTI as one of its two C-lanuage binding alternatives for DNI.

 2. The XTI specification can be obtained by sending a cheque for USD 70.00
    + 22.50 for shipping and handling to

                   X/Open Company Limited (Publications)
                                P.O.Box 109
                            Penn, High Wycombe
                         Buckinghamshire HP10 8NP
                                England

    Please give reference XO/CAE/91/600 (XTI). Card numbers for American
    Express, VISA, Mastercard or Eurocard are also accepted.

 3. Technical enquiries about XTI issues should be sent electronically to
                        xoxti@xopen.co.uk

 4. The following companies have so far obtained the X/Open brand for their
    XTI products on X/Open-compliant UNIX systems: Bull, Fujitsu, ICL,
    Olivetti, Siemens/Nixdorf. In addition, there are several more
    implementations of XTI which I have heard about but which have not yet
    been turned into formally released products. The number of XTI products
    on the market is expected to increase dramatically when the X/Open XPG4
    branding scheme is announced in October.

 With the best regards,

 Petr Janecek

----------------------------------------------------------------------------
 Dr Petr Janecek                           X/Open Company Limited
 CAE Development Manager                   Apex Plaza, Forbury Road
 EMail:p.janecek@xopen.co.uk               Reading RG1 1AX, England
 FAX: +(44) (0)734 500110                  Tel: +(44) (0)734 508311 ext 2239
----------------------------------------------------------------------------

Volume-Number: Volume 29, Number 20
From: mike@getafix.cs.uoregon.edu (Michael John Haertel)
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Date: 14 Sep 1992 16:24:09 -0700
Organization: CS Dept, University of Oregon
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: mike@getafix.cs.uoregon.edu (Michael John Haertel)

In article <192n6aINNlt2@ftp.UU.NET> preece@urbana.mcd.mot.com (Scott E. Preece) writes:
>And if
>you're a responsible engineer, you have to resist standardizing bad
>practice just because it is existing practice.

The problem is that often one person's bad practice is another's holy
grail.  Certainly, we can all agree that some things are bad practice.
But there are also many more things that lots of people still don't
agree on.  For example, I happen to think that Berkeley's socket
interface is a terrible way to do networks.  I know lots of people who
agree with me.  But I also know lots of people who disagree, often
quite vehemently.

So where do you draw the line between resisting the standardization
of bad practice, and gratuitously standardizing some committee member's
notion of the One True Way (existing implementations be damned)?

Existing systems all have their flaws, but at least we know what they
are.  Any new invention, by a standardization commitee or anyone else,
will inevitably include new flaws.  I feel the scope of standards
should be restricted to what's well-understood.  Introducing new flaws
that are not well understood to a standard that is to be carved in
stone is not a Good Idea.


Volume-Number: Volume 29, Number 36
From: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)
Newsgroups: comp.std.unix
Subject: Re: Report on POSIX.2: Shell and Utilities
Date: 14 Sep 1992 22:30:49 -0700
Organization: IR
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (D. J. Bernstein)

Scott E. Preece writes:
> So you have to write a
> standard that specifies things nobody specified before and you have to
> try to merge different versions of the same functionality.

Ah, but you never _have_ to write a standard.

You see that systems vary widely in, e.g., the output format of ``who'',
and even the type of information stored in /etc/utmp (or whatever file
``who'' reads). Does this mean you have to apply your imagination,
specify what the market hasn't specified, merge what the market hasn't
merged? No. It's a very strong signal that standardization is premature.
You shouldn't standardize ``who'' at all. Wait for market convergence.

You see that the market has come to agree on what you are sure is bad
practice. Does this mean you have to resist documenting that practice in
a standard? No. It means that your conceptions of what's good and bad
are out of sync with the market. Your responsibility as standards-writer
is to document what's being done, not to dream up new solutions. ``Only
those who code have the right to dream.'' If you can identify a
technical flaw in the bad practice, go ahead and document that! If
you're sure that you can make a better solution, try it on the market!

---Dan, still wondering why POSIX [:digit:] is better than Perl \d


Volume-Number: Volume 29, Number 37
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.std.unix,comp.unix.programmer
Subject: Re: File Locking across NFS mounts
Followup-To: comp.unix.programmer
Date: 9 Sep 1992 14:18:37 -0700
Organization: I.E.C.C.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)

>Submitted-by: lebrun@ll.mit.edu ("Steven F. LeBrun")
>I am looking for a method of file locking what works across NFS
>mounted directories and am interested on what methods other 
>people are using.

You aren't likely to get very satisfactory results using record locking.
Many versions of the locking daemon don't work at all, and the crash
recovery seems to me to be hopelessly amateurish.  I've worked on projects
that tried to use record locking and even after doing six backflips to try
and work around the record locking bugs, at least to get to the point that
we didn't just hang if the locking daemon wasn't working, the results
still were not great.

The time-honored technique of using a directory as a semaphore and using
mkdir() and rmdir() as lock and unlock works fairly well, although it's
rather slow.  Using link() and unlink() also works, at least on systems
that use the Unix semantics that you can't link on top of an existing
file.

If you're serious about having the locks work, in the long run you'll get
much better results if you write your own daemon that listens to a TCP/IP
socket and handles reserve and release messages, or maybe even manages the
file itself and accepts requests to atomically update and read from the
file.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 22
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Date: 11 Sep 1992 13:36:52 -0700
Organization: I.E.C.C.
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)

>>Submitted-by: johnl@iecc.cambridge.ma.us (John R. Levine)
>>The time-honored technique of using a directory as a semaphore and using
>>mkdir() and rmdir() as lock and unlock works fairly well, although it's
>>rather slow...

>Submitted-by: henry@zoo.toronto.edu (Henry Spencer)
>It isn't reliable, however.  The crucial point is that NFS does not provide
>a sufficiently good imitation of Unix filesystem semantics.  I'm told -- I
>have not seen details and don't have a reference -- that if you look hard
>enough at the problem, and consider things like finite cache sizes, you
>can prove that there is *no way* to do reliable locking through the NFS
>protocol.

Yeah.  The problem is that although the NFS calls are all individually
idempotent, they aren't in combination, and there is no way to enforce
exactly-once semantics in NFS.  Here's the classic example:

client					server

creat("foo")          ---------->	truncates "foo"
		      +----------       ack creat
		      | slow network
creat("foo)" retry ---|------+
receive ack       <---+      |
write data		-----|--->      writes data
receive ack             <----|---   	ack write
			     +--->	truncates file again
discard dup response         <---	ack creat

So all of the requests were executed and acked, but the repeated creat()
threw away the data.  Oops.

This apparently was a real problem, according to a paper at Usenix a few
years ago.  Sun has added a request cache and discards any request that is
a duplicate of one in the cache, but you can only keep requests for a few
seconds in a reasonable sized cache, and long-haul networks can easily
have delays longer than that. 

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl


Volume-Number: Volume 29, Number 32
From: iand@labtam.labtam.oz.au (Ian Donaldson)
Newsgroups: comp.std.unix
Subject: Re: File Locking across NFS mounts
Date: 15 Sep 1992 13:46:23 -0700
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
NNTP-Posting-Host: ftp.uu.net
X-Submissions: std-unix@uunet.uu.net

Submitted-by: iand@labtam.labtam.oz.au (Ian Donaldson)

johnl@iecc.cambridge.ma.us (John R. Levine) writes:
>Yeah.  The problem is that although the NFS calls are all individually
>idempotent, they aren't in combination, and there is no way to enforce
>exactly-once semantics in NFS.  Here's the classic example:

>client					server

>creat("foo")          ---------->	truncates "foo"
>		      +----------       ack creat
>		      | slow network
>creat("foo)" retry ---|------+
>receive ack       <---+      |
>write data		-----|--->      writes data
>receive ack             <----|---   	ack write
>			     +--->	truncates file again
>discard dup response         <---	ack creat

>So all of the requests were executed and acked, but the repeated creat()
>threw away the data.  Oops.

If each NFS_create transmission request had a different xid wouldn't this 
problem vanish?  This is provided that you don't start writing until you 
get a response to the last request you sent (ie: ignoring arrivals
of delayed earlier sent ones).

Isn't the current problem that many NFS client implementations
use clnt_call() once and it uses the same xid in each request it retransmits,
and returns when it gets any response with a matching xid?  Thus it doesn't
know if there are any further requests still on the way to the server,
because it can't tell which response it got.

If a different xid is used in each request, the host wouldn't need
to keep a cache of request-id's at all as each request would have
a unique xid, and this would make the problem of the "state" that
the server temporarily keeps about such requests, go away.  

The client would need to check for obvious errors in replies due to duplicated
attempts to do things that change server state such as mkdir/rmdir/unlink/chown,
due to lost replies from the server.

Anyway, isn't this also only a problem with popular UDP based NFS 
implementations?  With TCP this problem shouldn't exist.  

Ian Donaldson

Email:  iand@labtam.labtam.oz.au
Phone:  +61-3-587-1444
Fax:    +61-3-580-5581

[ I think followups should go to comp.protocols.nfs -- mod ]

Volume-Number: Volume 29, Number 38
From: dgs@53iss6.Waterloo.NCR.COM (David G. Schwartz)
Newsgroups: comp.std.misc
Subject: TIFF Specification
Summary: What level, where?
Date: 14 Sep 92 15:31:02 GMT
Reply-To: dgs@ncrwat.Waterloo.NCR.COM (David G. Schwartz)
Distribution: usa
Organization: Imaging Systems Division, NCR Corp, Waterloo, Ont., CANADA


I would appreciate knowing what is the current _released_ version of the
TIFF specification and from where I can get it (electronically).
Please respond by e-mail.

Thanx

.............Dave

-------

Remember: Net.advice is usually worth what you pay for it.
VOICE:(519) 884-1710x701 FAX:(519) 884-0610 NCR VoicePlus: 643-1701 DoD#: 0066
Dave.Schwartz@Waterloo.NCR.COM   UUCP: {uunet!ncrcom,maytag}!ncrwat!53iss6!dgs
From: rbrown@redgum.bcae.oz.au (rbrown)
Newsgroups: comp.std.misc
Subject: Help on 1201.X, X3H3.6.
Date: 28 Aug 92 01:11:22 GMT
Organization: UCNV, Bendigo, Victoria, Australia
Originator: rbrown@redgum.ucnv.edu.au

Dear standards experts,

I am planning on giving a seminar on X windows in my department in the
near future, before I can do this I need some information about the
status of the ANSI X3H3.6 and the POSIX 1201.X standards.  Is it possible
that someone on the Net could send me some E-mail regarding their status
as of the month of August.  If this is impossible could someone show me
some pointers as to where I could best get this information from.  At
the moment all I have are some Australian Unix User Group Newsletters
(AUUGN's).

BTW I hope this is the right place to ask these questions about such
standards, if this is not the right forum then I offer my humble
apologies and would be happy to be pointed to the correct newsgroup.

Thanks in advance,

Ross Brown,
Lecturer Dep. Inf. Sci. U.C.N.V.,
Email : rbrown@redgum.ucnv.edu.au
------------------------------------------------------------------------
Newsgroups: comp.std.misc,comp.protocols.iso,comp.protocols.iso,comp.std.internat,alt.internet.services
From: ddavis@cass.ma02.bull.com (Dave Davis)
Subject: Online Catalog of Standards/Protocols?
Organization: Bull World Wide Information Systems Inc.
Distribution: na
Date: Fri, 11 Sep 1992 20:45:09 GMT


What internet resources are available (No, I don't have
my friends Archie or Wais handy to ask :-) ) for the *identification*
of standards- i.e., name, number, topic(s), issuing body?

Note: This is not yet-another-call for the text of Standard XYZZY.

If this info is available in a FAQ somewhere, then I
humbly beg your collective pardon. If it isn't, it should be.

Thanks in advance for any pointers.


Dave Davis, ddavis@ma30.bull.com
These are my opinions & activities alone

QOTD:

The winds must come from somewhere when they blow
There must be reasons why the leaves decay
Time will say nothing but I told you so. 
				Auden
From: ath@linkoping.trab.se (Anders Thulin)
Newsgroups: comp.std.internat
Subject: Re: ISO 639 language list wanted
Date: 5 Sep 92 07:38:07 GMT
Organization: Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden

In article <1992Sep4.113300.5807@onionsnatcorp.ox.ac.uk> dominic@natcorp.ox.ac.uk (Dominic Dunlop) writes:
>Also, while I'm here, is anyone aware of a list more comprehensive
>than ISO 639 (covering many archaic or dead languages, for example)?

ISO 639 is being revised. I believe the new revision will use (or
permit) three-letter names.

For a list of languages, see Ethnologue: Languages of the World, ed.
Barbara grimes, 11th ed, Dallas, TX: Summer Instititute of
Linguistics, 1988.

It is fairly comprehensive - more than 6000 languages are identified.

-- 
Anders Thulin       ath@linkoping.trab.se 
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
From: myk@vax5.cit.cornell.edu
Newsgroups: comp.std.internat
Subject: The Case of the Mysterious MHEG
Date: 14 Sep 92 17:28:05 EDT
Summary: is working doc or something available?
Reply-To: myk@cornellc.cit.cornell.edu
Keywords: MHEG standard how get
Distribution: world
Organization: Interactive Multimedia Group, Cornell University

I am working on a project that requires the representation of multimedia
material with hyperlinks.  We have all the information we need about
HyTime, but we need more information about MHEG.  I have seen a number
of inquiries go by on the net, but I haven't seen any leads except one,
and when I used the lead, I did not receive any reply.  I need more
information than is seen in the popular-press articles.  I assume that
MHEG is still in committee/working draft form.  Does anyone know how
to contact the group?

P.S. I am talking about MHEG, a standard-in-work for representing
hypermedia information in binary form, not MPEG, the standard for
compression of motion video into binary form.
--------
Mike Oltz      myk@cornellc.cit.cornell.edu

Newsgroups: comp.std.internat
From: gtoal@pizzabox.demon.co.uk (Graham Toal)
Subject: Wanted: Dead or Alive! 
Distribution: world
Organization: Cuddlehogs Anonymous
Date: Thu, 10 Sep 1992 12:21:39 +0000


In article <27548@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu writes:
>  WANTED.  Dead or Alive.  Information concerning any of the following
>  scripts.  Prefer information in the form of repertoire listings,
>  explanatory material, or bibliographic references to significant sources
>  of information easily obtainable by mere mortals within the boundaries of
>  the continental US.  Please contact me if you have sighted any of these.
>  Allow 10-14 working days for reply.  Void where prohibited.  Post in plain
>  sight.
>
>          Rick_McGowan@NeXT.COM

Have you got a copy of an old book called 'Grammatography' - I don't know
the date - 1800's sometime - or any other info as my third-generation
photocopy has managed to lose the frontispiece - but it is a wonder of
a book if you are interested in character sets.  Check out the search
facilities of some *major* library and you might find it.

[Or in a *real* pinch you could have mine though it won't survive another
generation of photocopies and still be visible, and I'm reluctant to part
with it unless I have to, so have a *good* look around first! :-)]

G
From: myk@vax5.cit.cornell.edu
Newsgroups: comp.std.internat
Subject: Three-letter abbrev for a language
Date: 14 Sep 92 17:31:55 EDT
Summary: Esperanto is EO; is it ETO?
Reply-To: myk@cornellc.cit.cornell.edu
Distribution: world
Organization: Interactive Multimedia Group, Cornell University

I need to find out the *three-letter* ISO abbreviation for the
Esperanto language.  The two letter abbreviation is EO, but there
is a new standard coming out, no?  I have been assuming that it
will be ETO (not ESP, which would confuse with Spanish).  Does
anyone have a draft of the new standard, or know its number?
--------
Mike Oltz  myk@cornellc.cit.cornell.edu
From: ct@dde.dk (Claus Tondering)
Newsgroups: comp.std.internat
Subject: Unicode documentation wanted
Date: 9 Sep 92 11:06:12 GMT
Organization: Dansk Data Elektronik A/S

When and how can I obtain version 1.1 of the Unicode standard?

-- 
Claus Tondering
Dansk Data Elektronik A/S, Herlev, Denmark
E-mail: ct@dde.dk
Newsgroups: comp.std.internat
From: gtoal@pizzabox.demon.co.uk (Graham Toal)
Subject: Latin unification in ISO 10646 
Distribution: world
Organization: Cuddlehogs Anonymous
Date: Thu, 10 Sep 1992 12:21:37 +0000


In article <1992Sep9.163417.8803@corax.udac.uu.se> andersa@Riga.DoCS.UU.SE writes:
>Programmers are used to being able to perform case conversion on
>letters of the ASCII table by simply adding or subtracting a certain
>constant to the character code, given that the code is within a
>particular range (A-Z or a-z).  With later ISO standards, this is
>not quite such a simple task due to the sometimes ad-hoc layout of
>lowercase letters with respect to corresponding uppercase letters
>(examples available upon request), but it would still be possible
>using tables showing the relationship.

The upper/lower conversions were a fortunate hack that the original 7-bit
character set allowed.  These should nowadays be done by the application,
along with similar functions to add or remove accents.  The invariance
of tolower(toupper(x)) has been broken since ESZET -> "SS" -> "ss" first
happened.

Even if you want to use the simple facilities of the language, rather
than writing a custom function, you're still hampered by the <locale.h> stuff
being the trivial implementation in just about every Ansi library around :-(

G
Newsgroups: comp.std.internat
From: wai@csuvax1.csu.murdoch.edu.au (Julian Wai)
Subject: Standard for Data Dictionary
Organization: Murdoch University
Date:  7 Sep 92 03:17:35 GMT

Hi,

Has anyone heard of IS 10728?  It is supposed to be a standard for Data 
dictionary.  

Any information concerning standard data dictionary will be appreciated.

Thanks in advance.

Julian
wai@csuvax1.csu.murdoch.edu.au
Newsgroups: comp.std.internat
From: fab@fungus.zso.dec.com (F Avery Bishop)
Subject: Re: Latin unification in ISO 10646
Summary: Latin, Greek, and Cyrillic are not unifiable
Organization: Digital Equipment Corporation - DECwest Engineering
Date: Tue, 15 Sep 1992 23:33:28 GMT

In article <27738@life.ai.mit.edu> glenn@wheat-chex.ai.mit.edu (Glenn A. Adams) writes:
>
>10646 encodes the elements of scripts, independent of their use by particular
>languages.  Latin and Cyrillic, though both derived from the Greek alphabet
>along with influences from Etruscan and Aramaic, are clearly distinct
>scripts.  On the other hand, the Han script, as used in China, Japan, Korea,
>and Vietnam, is clearly one script, though some innovations were introduced
>in its different writing systems.
>
>Since Cyrillic, Greek, and Latin are separate scripts, their elements are
>encoded separately, even when they happen to have some overlap of form.
>
>An even more important reason for their distinction in 10646 is because they
>are distinct in ISO8859-5.  The prime directive, as it were, for 10646 was
>to facilitate a 1-1 round-trip mapping between 10646 and existing character
>sets.  This precludes any unification of the few similar Cyrillic, Greek,
>and Latin characters.
>

  An even more important reason is that the three cannot be unified in
  any reasonable way.  The only character with the same upper and
  lower case forms in these three languages is O/o.  Thanks to Joe
  Becker to pointing this out.

/fab


-- 
-- 
F. Avery Bishop, (206)-865-8916 | Sushi -- breakfast of champions
Digital Equipment Corporation   |  
fab@zso.dec.com			|  
Xref: sparky comp.std.internat:638 comp.fonts:2600