[no subject]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
I believe this kind of discussion is out of proportions. In fact, I wonder
if there is any *REAL* restriction to issue an RFC in any other language.
Of course, people do in English for the sake of making them be understood
by the majority.
Also, to say that IETF is a meeting in *English* is to be short-sighted.
I have seen people talking in many languages around all the meetings. I
also had the opportunity to talk with Mr. Ohta in Japanese last IETF. Also,
I had opportunity to speak in other people in my broken Mandarin, Spanish..
Unfortunately I cannot understand Hebrew or many other languages people
around speak between themselves. I also think there is no *REAL*
restrictions to even have a presentation in Japanese, if mr. Ohta so
desires. I might be there, but how many others?
Oh... Btw... Isnt mr. ohta the same person who 5 years ago tried to deny
to foreigners living in Japan to have a newsgroup in English?... I wonder...
--
Claude Huss
Received: from ietf.org by ietf.org id aa22142; 30 Oct 96 2:54 EST
Received: from dxmint.cern.ch by ietf.org id aa21925; 30 Oct 96 2:51 EST
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id IAA06962; Wed, 30 Oct 1996 08:50:12 +0100 (MET)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA25937; Wed, 30 Oct 1996 08:50:10 +0100
Message-Id: <9610300750.AA25937 at dxcoms.cern.ch>
Subject: Re: The cartel begins to crumble?
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Date: Wed, 30 Oct 1996 08:50:10 +0100 (MET)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
Cc: perry at piermont.com, dcrocker at brandenburg.com, frezza at interramp.com,
ietf at ietf.org, namedroppers at internic.net
In-Reply-To: <199610300210.LAA07743 at necom830.hpcl.titech.ac.jp> from "Masataka Ohta" at Oct 30, 96 11:10:22 am
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Masataka,
>
> That is, unless we can use English very well, it is difficult to
> join the discussion at face-to-face meeting.
Je propose que nous utilisons le francais a partir de maintenant.
> And, I'm afraid telephone conference of Nomcom is much harder to
> join.
Bien sur, ceux sont des discussions autour des personnes, c'est
normale.
Cordialement,
Brian
Received: from ietf.org by ietf.org id aa22974; 30 Oct 96 3:23 EST
Received: from ecrc.de by ietf.org id aa22902; 30 Oct 96 3:21 EST
Received: from scorpio.ecrc.de by ecrc.de with SMTP id AA06626
(5.65c/IDA-1.4.4 for <ietf at ietf.org>); Wed, 30 Oct 1996 09:19:48 +0100
Received: from acrab25.ecrc.de by scorpio.ecrc.de (4.1/SMI-3.2)
id AA06696; Wed, 30 Oct 96 09:19:47 +0100
Date: Wed, 30 Oct 96 09:19:47 +0100
Sender:ietf-request at ietf.org
From: Dave Morton <Dave.Morton at ecrc.de>
Message-Id: <9610300819.AA06696 at scorpio.ecrc.de>
To: mohta at necom830.hpcl.titech.ac.jp, perry at piermont.com
Subject: Re: The cartel begins to crumble?
Cc: dcrocker at brandenburg.com, frezza at interramp.com, ietf at ietf.org,
namedroppers at internic.net
Source-Info: From (or Sender) name not authenticated.
>I hope that the situation will improve as the number of non-US
>participants increases. But, a chicken-or-egg problem is that
>as long as IETF is US centric, non-US participants may not increase.
>
>For example, these days, IETF has been continuously held in North
>America only, which will maximize the number of (mostly US)
>participants.
Masataka,
This is not quite true - there have been IETF meetings in the recent
past in both Amsterdam and Stockholm and in fact the Aug. 97 meeting
will be held here in Munich. Actually holding meetings in Europe or
elsewhere doesnt in itself guarantee lots of non-US participants as
flying from Stockholm to say Munich is at least, if not more, expensive
than flying to San Jose. Still holding IETF meetings outside of NA
now and then does help perhaps "politically" :-). We should not forget
though that regardless of where the meetings are held there will still
be a large contingent of US participants - and why not.....
Cheers,
Dave
Received: from ietf.org by ietf.org id aa23824; 30 Oct 96 3:37 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa23718;
30 Oct 96 3:36 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610300831.RAA08803 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id RAA08803; Wed, 30 Oct 1996 17:31:33 +0900
Subject: Re: The cartel begins to crumble?
To: chikkanr at agcs.com
Date: Wed, 30 Oct 96 17:31:31 JST
Cc: rgowda at blr.sni.de, krishnas at agcs.com, raosa at agcs.com, dorian at cic.net,
mohta at necom830.hpcl.titech.ac.jp, ietf at ietf.org
In-Reply-To: <9610292327.ZM2063 at odc1>; from "chikkanr at agcs.com" at Oct 29, 96 11:27 pm
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> > > One of the problems of IETF compared to other standardization
> > > bodies is that it's too much US centric.
> > >
> > > That is, unless we can use English very well, it is difficult to
> > > join the discussion at face-to-face meeting.
> >
> > Above two things are orthogonal. What do you propose we do, speak
> Esperanto?
> > English is the lingua franca. Until that changes, I don't see what
> having to
> > speak English well enough to be understood have to do with whether
> IETF is US
> > centric.
> >
> > -dorian
>
>
> I agree that there has to be a common language for interaction and it
> is nobody's fault that English is the lingua franca.
.....
Of course, US constitution is written in English and English
is not a lingua franca.
But, it is the best compromise for IETF.
Forcing English only is a lot better to force English and French at
the same time.
The problem I pointed out is:
unless we can use English very well, it is difficult to
join the discussion at face-to-face meeting.
That is, compared to other international bodies, native users of
English bother less to speak clearly and slowly with some written
documents.
To use English for the international discussion, native users of
English must accept trade language quality English.
But, what I have experienced so far in IETF, instead, is that
technically cornered people suddenly attacked my English was
not perfect.
It was not a problem for me, but for those who are less impudent
and less rude than me, such a shameless attitude is the problem.
Masataka Ohta
Received: from ietf.org by ietf.org id aa26906; 30 Oct 96 4:24 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa26658;
30 Oct 96 4:21 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610300918.SAA08980 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id SAA08980; Wed, 30 Oct 1996 18:18:42 +0900
Subject: Re: The cartel begins to crumble?
To: Dave Morton <Dave.Morton at ecrc.de>
Date: Wed, 30 Oct 96 18:18:40 JST
Cc: mohta at necom830.hpcl.titech.ac.jp, perry at piermont.com,
dcrocker at brandenburg.com, frezza at interramp.com, ietf at ietf.org,
namedroppers at internic.net
In-Reply-To: <9610300819.AA06696 at scorpio.ecrc.de>; from "Dave Morton" at Oct 30, 96 9:19 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
Dave;
> >For example, these days, IETF has been continuously held in North
> >America only, which will maximize the number of (mostly US)
> >participants.
>
> Masataka,
>
> This is not quite true -
I said "these days".
> there have been IETF meetings in the recent
> past in both Amsterdam and Stockholm and in fact the Aug. 97 meeting
> will be held here in Munich.
Then, perhaps in Australia and Italy. I know, of course.
> Still holding IETF meetings outside of NA
> now and then does help perhaps "politically" :-).
And chiken-or-egg debate can continue forever.
Masataka Ohta
Received: from ietf.org by ietf.org id aa04694; 30 Oct 96 10:27 EST
Received: from smtp1.interramp.com by ietf.org id aa03429; 30 Oct 96 10:06 EST
Received: from [38.26.44.118] by smtp1.interramp.com (8.8.1/SMI-4.1.3-PSI-irsmtp)
id KAA14321; Wed, 30 Oct 1996 10:03:41 -0500 (EST)
Date: Wed, 30 Oct 1996 10:03:41 -0500 (EST)
X-Sender: frezza at pop3.interramp.com
Message-Id: <v03007804ae9cd2f9dbf1 at [38.26.44.118]>
In-Reply-To: <v0310060bae9c04f0474c at [205.214.160.86]>
References: <Pine.BSI.3.93.961029092827.183I-100000 at sidhe.memra.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Dave Crocker <dcrocker at brandenburg.com>
Sender:ietf-request at ietf.org
From: Bill Frezza <frezza at interramp.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
Dave Crocker writes:
>You may have concerns over the current operation of IANA. You may
>have specific changes in mind. But rest assured that the solution will
>require a central authority, if the solution is to be viable.
HONEST QUESTION (please cc: me as I do not monitor all these groups)
Please describe how this central authority will compel people around the
world to obey its edicts.
Thanks you,
Bill Frezza
CommunicationsWeek
frezza at interramp.com
http://techweb.cmp.com/nc/frezza/frezza.html
Received: from ietf.org by ietf.org id aa04697; 30 Oct 96 10:27 EST
Received: from io.org by ietf.org id aa03628; 30 Oct 96 10:12 EST
Received: from dyna-52.net7b.io.org (dyna-52.net7b.io.org [204.92.49.52]) by io.org (8.6.12/8.6.12) with SMTP id KAA04956; Wed, 30 Oct 1996 10:11:37 -0500
Message-Id: <199610301511.KAA04956 at io.org>
Comments: Authenticated sender is <armcomp at mail2.io.org>
Sender:ietf-request at ietf.org
From: "George T. McCallum" <armcomp at io.org>
Organization: ARM Computer Techniques Inc.
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Date: Tue, 29 Oct 1996 22:09:54 -500
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: The cartel begins to crumble?
CC: ietf at ietf.org
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
Source-Info: From (or Sender) name not authenticated.
On 30 Oct 96 at 17:31, Masataka Ohta wrote:
> > > > One of the problems of IETF compared to other standardization
> > > > bodies is that it's too much US centric.
> > > >
> > > > That is, unless we can use English very well, it is difficult to
> > > > join the discussion at face-to-face meeting.
> > >
> > > Above two things are orthogonal. What do you propose we do, speak
> > > Esperanto? English is the lingua franca. Until that changes, I
> > > don't see what having to speak English well enough to be understood
> > > have to do with whether IETF is US centric.
> > >
> > I agree that there has to be a common language for interaction and it
> > is nobody's fault that English is the lingua franca.
>
> Of course, US constitution is written in English and English
> is not a lingua franca.
>
"Lingua franca" means "language of commerce". For better or worse,
English is probably the closest to a lingua franca that the world has.
> But, it is the best compromise for IETF.
>
> Forcing English only is a lot better to force English and French at
> the same time.
>
> The problem I pointed out is:
>
> unless we can use English very well, it is difficult to
> join the discussion at face-to-face meeting.
>
> That is, compared to other international bodies, native users of
> English bother less to speak clearly and slowly with some written
> documents.
>
> To use English for the international discussion, native users of
> English must accept trade language quality English.
>
Here, I agree with Ohta-san. The quality of grammar, diction, and
rhetoric (not to mention spelling), that appears on this (and many other
lists) is pretty low. To say that it is confusing for non-native speakers
of English is an understatement. The contributors to this and other lists
are so sensitive about their lack of ability to use the English language
correctly that complaints about spelling and grammar are banned from
discussion...
Even for us native speakers, the English that we use in technical discussions
is not the English that we learned at our mother's knee. Our engineering
schools do a very poor job of teaching us how to present our thoughts
clearly and convincingly in technical English.
What appears as US-centric is more likely the arrogance of the poorly-
educated.
> But, what I have experienced so far in IETF, instead, is that
> technically cornered people suddenly attacked my English was
> not perfect.
>
> It was not a problem for me, but for those who are less impudent
> and less rude than me, such a shameless attitude is the problem.
>
> Masataka Ohta
George T. McCallum,
ARM Computer Techniques Inc.
412 Mt. Pleasant Road,
Toronto, Canada. M4S 2L7
(tel) 416-488-1757
(fax) 416-488-1758
(ema) armcomp at io.org
Received: from ietf.org by ietf.org id aa04734; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01947; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ietf-otp at bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-otp-ext-01.txt
Date: Wed, 30 Oct 1996 09:50:51 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01947 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the One Time Password
Authentication Working Group of the IETF.
Title : OTP Extended Responses
Author(s) : C. Metz
Filename : draft-ietf-otp-ext-01.txt
Pages : 11
Date : 10/29/1996
This document provides a specification for a type of response to
an OTP [RFC 1938] challenge that carries explicit indication of
the response's encoding. Codings for the two mandatory OTP data
formats using this new type of response are presented.
This document also provides a specification for a response that
allows OTP generator to request that a server re-initialize a sequence
and change parameters such as the secret pass phrase.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-otp-ext-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-otp-ext-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-otp-ext-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029160928.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-otp-ext-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-otp-ext-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029160928.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04765; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01899; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-atm2TC-05.txt
Date: Wed, 30 Oct 1996 09:50:32 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01899 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Textual Conventions and OBJECT-IDENTITIES
for ATM Management
Author(s) : M. Noto, K. Tesink
Filename : draft-ietf-atommib-atm2TC-05.txt
Pages : 17
Date : 10/29/1996
This memo describes Textual Conventions and OBJECT-IDENTITIES used for
managing ATM-based interfaces, devices, networks and services.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atm2TC-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm2TC-05.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atm2TC-05.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029150649.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm2TC-05.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm2TC-05.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029150649.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04764; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01931; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-atm1ng-02.txt
Date: Wed, 30 Oct 1996 09:50:44 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01931 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Managed Objects for ATM Management
Author(s) : K. Tesink
Filename : draft-ietf-atommib-atm1ng-02.txt
Pages : 101
Date : 10/29/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing ATM-based
interfaces, devices, networks and services.
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-atm1ng-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-atm1ng-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-atm1ng-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029151517.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-atm1ng-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-atm1ng-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029151517.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04760; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01915; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-sonetng-02.txt
Date: Wed, 30 Oct 1996 09:50:38 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01915 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Definitions of Managed Objects for the SONET/SDH
Interface Type
Author(s) : K. Tesink
Filename : draft-ietf-atommib-sonetng-02.txt
Pages : 87
Date : 10/29/1996
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in TCP/IP-based
internets. In particular, it defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects. This
document is a companion document with Definitions of Managed Objects for
the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and RFC1407 [13].
This memo specifies a MIB module in a manner that is both compliant to the
SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-sonetng-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-sonetng-02.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-sonetng-02.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029151116.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-sonetng-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-sonetng-02.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029151116.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04682; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01835; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: ipng at sunroof.eng.sun.com
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-ipngwg-ipv6-routing-00.txt
Date: Wed, 30 Oct 1996 09:50:11 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01835 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the IPNG Working Group of the
IETF.
Title : IPv6 Routing Table Size Issues
Author(s) : R. Atkinson
Filename : draft-ietf-ipngwg-ipv6-routing-00.txt
Pages : 4
Date : 10/29/1996
This note describes certain issues relating to the size of the IPv6 routing
table in backbone routers. It also suggests several possible approaches to
dealing with those issues.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-ipngwg-ipv6-routing-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029111155.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-ipngwg-ipv6-routing-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-ipngwg-ipv6-routing-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029111155.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa04748; 30 Oct 96 10:28 EST
Received: from localhost by ietf.org id aa01867; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Sender:ietf-announce-request at ietf.org
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-kashef-frmib-dte-dcp-00.txt
Date: Wed, 30 Oct 1996 09:50:22 -0500
X-Orig-Sender: cclark at ietf.org
Message-ID: <9610300950.aa01867 at ietf.org>
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Management Information Base for Frame Relay DCP DTE
Extensions for Data Compression over Frame Relay
Author(s) : M. Kashef
Filename : draft-kashef-frmib-dte-dcp-00.txt
Pages : 6
Date : 10/29/1996
This memo defines a portion of the Management Information Base (MIB) for
use with network management protocols in TCP/IP-based internets. In
particular, it defines objects for managing Data Compression over a Frame
Relay virtual circuit. This memo does not specify a standard for the
Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-kashef-frmib-dte-dcp-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-kashef-frmib-dte-dcp-00.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-kashef-frmib-dte-dcp-00.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029112857.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-kashef-frmib-dte-dcp-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-kashef-frmib-dte-dcp-00.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029112857.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa05154; 30 Oct 96 10:31 EST
Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa05079;
30 Oct 96 10:30 EST
Sender:ietf-request at ietf.org
From: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Message-Id: <199610301528.AAA09802 at necom830.hpcl.titech.ac.jp>
Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1)
id AAA09802; Thu, 31 Oct 1996 00:27:54 +0859
Subject: Re: The cartel begins to crumble?
To: "George T. McCallum" <armcomp at io.org>
Date: Thu, 31 Oct 96 0:27:54 JST
Cc: mohta at necom830.hpcl.titech.ac.jp, ietf at ietf.org
In-Reply-To: <199610301511.KAA04956 at io.org>; from "George T. McCallum" at Oct 31, 96 12:10 am
X-Mailer: ELM [version 2.3 PL11]
Source-Info: From (or Sender) name not authenticated.
> "Lingua franca" means "language of commerce". For better or worse,
> English is probably the closest to a lingua franca that the world has.
It depends on which commerce you belong to.
> > To use English for the international discussion, native users of
> > English must accept trade language quality English.
> Here, I agree with Ohta-san. The quality of grammar, diction, and
> rhetoric (not to mention spelling), that appears on this (and many other
> lists) is pretty low.
Written e-mail conversation is not so much a problem, though
frequently updated voluminous Internet Drafts and RFCs with little
engineering content and a lot of excuse (or debate or reasoning
or whatever) are.
Masataka Ohta
Received: from ietf.org by ietf.org id aa05318; 30 Oct 96 10:35 EST
Received: from excaliber.digitalink.com by ietf.org id aa05234;
30 Oct 96 10:34 EST
Received: from mjolnir.digitalink.com by excaliber.digitalink.com; (5.65v3.0/1.1.8.2/15Jan96-0459PM)
id AA06179; Wed, 30 Oct 1996 10:32:37 -0500
Received: from vincewolodkin by mjolnir.digitalink.com; (5.65v3.0/1.1.8.2/10Jan96-0415PM)
id AA01324; Wed, 30 Oct 1996 10:32:36 -0500
X-Orig-Sender: wolodkin at digitalink.com
Message-Id: <3277742F.7CB13899 at digitalink.com>
Date: Wed, 30 Oct 1996 10:28:47 -0500
Sender:ietf-request at ietf.org
From: Vince Wolodkin <wolodkin at digitalink.com>
Organization: Digital Ink (Home of http://www.washingtonpost.com)
X-Mailer: Mozilla 3.0b7 (X11; I; Linux 1.2.13 i586)
Mime-Version: 1.0
To: Bill Frezza <frezza at interramp.com>
Cc: Dave Crocker <dcrocker at brandenburg.com>, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Subject: Re: NEWDOM: Re: The cartel begins to crumble?
References: <Pine.BSI.3.93.961029092827.183I-100000 at sidhe.memra.com> <v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Bill Frezza wrote:
>
> Dave Crocker writes:
>
> >You may have concerns over the current operation of IANA. You may
> >have specific changes in mind. But rest assured that the solution will
> >require a central authority, if the solution is to be viable.
>
> HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
> Please describe how this central authority will compel people around the
> world to obey its edicts.
>
> Thanks you,
>
> Bill Frezza
> CommunicationsWeek
> frezza at interramp.com
> http://techweb.cmp.com/nc/frezza/frezza.html
>
Hmmmm, possibly suspension of domain name???
Vince
Received: from ietf.org by ietf.org id aa05774; 30 Oct 96 10:42 EST
Received: from munnari.OZ.AU by ietf.org id aa05683; 30 Oct 96 10:41 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
id PA17624; Thu, 31 Oct 1996 02:40:37 +1100 (from kre at munnari.OZ.AU)
To: Bill Frezza <frezza at interramp.com>
Cc: ietf at ietf.org, com-pri at psi.com, newdom at ar.com
Subject: Re: The cartel begins to crumble?
In-Reply-To: Your message of "Wed, 30 Oct 1996 10:03:41 CDT."
<v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Date: Thu, 31 Oct 1996 02:40:23 +1100
Message-Id: <2568.846690023 at munnari.OZ.AU>
Sender:ietf-request at ietf.org
From: Robert Elz <kre at munnari.oz.au>
Source-Info: From (or Sender) name not authenticated.
Date: Wed, 30 Oct 1996 10:03:41 -0500 (EST)
From: Bill Frezza <frezza at interramp.com>
Message-ID: <v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Please describe how this central authority will compel people around the
world to obey its edicts.
It won't compel anyone to do anything, just as the international
phone numbering people neither do (nor can) compel me to number
my phones in accordance with the number schemes that they set.
However, I am likely to find that nothing works well unless everyone
agrees to a common standard, common TLD names, common ways of
translating the names to addresses, etc, just as the phone system
wouldn't work if everyone simply went about inventing their own
numbering schemes.
I don't need to be compelled to obey any edicts, all I need to do
is to see that unless I, and everyone else, agree on a standard way
of doing these things, then chaos ensues, and while I may be free to
name things the way I like, having named them, no-one else is
able to communicate with them. So I will adopt standard naming,
others will adopt standard methods of looking up the names, and
the whole system works.
Some others can go do their own thing if they like, there is no
compulsion, the rest of us will simply ignore them, eventually they
will see that they're cutting themselves off from almost everyone,
and rejoin the community.
kre
Received: from ietf.org by ietf.org id aa05905; 30 Oct 96 10:44 EST
Received: from ng.netgate.net by ietf.org id aa05808; 30 Oct 96 10:43 EST
Received: from [205.214.160.89] (d79.netgate.net [205.214.160.115]) by ng.netgate.net (8.7.4/8.6.9) with ESMTP id HAA08477; Wed, 30 Oct 1996 07:52:23 -0800 (PST)
X-Sender: dcrocker at ng.netgate.net
Message-Id: <v0310060eae9d220a914e at [205.214.160.89]>
In-Reply-To: <v03007804ae9cd2f9dbf1 at [38.26.44.118]>
References: <v0310060bae9c04f0474c at [205.214.160.86]>
<Pine.BSI.3.93.961029092827.183I-100000 at sidhe.memra.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Date: Wed, 30 Oct 1996 07:35:10 -0800
To: Bill Frezza <frezza at interramp.com>
Sender:ietf-request at ietf.org
From: Dave Crocker <dcrocker at brandenburg.com>
Subject: Re: The cartel begins to crumble?
Cc: ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
At 7:03 AM -0800 10/30/96, Bill Frezza wrote:
>>You may have concerns over the current operation of IANA. You may
>>have specific changes in mind. But rest assured that the solution will
>>require a central authority, if the solution is to be viable.
>
>HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
>Please describe how this central authority will compel people around the
>world to obey its edicts.
Bill, your question goes directly to the core of standardization.
Once upon a time, people thought that de jure standardization
really did compell everyone to use it. But along came a de facto standard
that dislodged it. (While I'm sure there are many examples, the one I have
in mind, of course, is OSI and TCP/IP...)
What compels people is their own desire for interoperability. The
choice is in which thing is chosen, not whether one dominates.
If you want everyone in the world to be able to find each other,
there needs to be a One True top-level data base. It's ok to have
additional, private ones (e.g., many intranets work that way, to
intentionally restrict access in or out of the corporation) but the key
word, here, is private.
Imagine, if you will, a thousand top-level data bases, none
coordinated with the other. How is a person to find them all and use them
all? It is this reality (not just potential) for complete confusion which
compels people to seek some order for the data. THAT is what the top-level
domain central authority accomplishes.
d/
ps. One answer to my question, above, might be that one or many of the
different tlds attempt to encompass all the others, thereby greatly
simplifying life for their users. That, of course, makes all such tld data
bases identical and therefore serve as the One True database...
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker at brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info at imc.org
Received: from cnri by ietf.org id aa06983; 30 Oct 96 11:04 EST
Received: from thumper-13.bellcore.com by CNRI.Reston.VA.US id aa13280;
30 Oct 96 11:04 EST
Received: from ietf.org (ietf.org [132.151.1.19]) by thumper.bellcore.com (8.7.6/8.7.3) with SMTP id KAA07472 for <atommib at thumper.bellcore.com>; Wed, 30 Oct 1996 10:42:24 -0500 (EST)
Received: from localhost by ietf.org id aa01883; 30 Oct 96 9:50 EST
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
cc: atommib at thumper.bellcore.com
From: Internet-Drafts at ietf.org
Reply-to: Internet-Drafts at ietf.org
Subject: I-D ACTION:draft-ietf-atommib-perfhistTC-01.txt
Date: Wed, 30 Oct 1996 09:50:26 -0500
Sender: cclark at ietf.org
Message-ID: <9610300950.aa01883 at ietf.org>
--NextPart
A Revised Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the AToM MIB Working Group of
the IETF.
Title : Textual Conventions for MIB Modules Using Performance
History Based on 15 Minute Intervals
Author(s) : K. Tesink
Filename : draft-ietf-atommib-perfhistTC-01.txt
Pages : 10
Date : 10/29/1996
When designing a MIB module, it is often useful to define new types similar
to those defined in the SMI. In comparison to a type defined in the SMI,
each of these new types has a different name, a similar syntax, but a more
precise semantics. These newly defined types are termed textual
conventions, and are used for the convenience of humans reading the MIB
module. This is done through Textual Conventions as defined in RFC1903[1].
It is the purpose of this document to define the set of textual conventions
to be used when performance history based on 15 minute intervals is kept.
See for example the Trunk MIB modules [3][4][5].
This memo does not specify a standard for the Internet community.
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-atommib-perfhistTC-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-atommib-perfhistTC-01.txt
Internet-Drafts directories are located at:
o Africa: ftp.is.co.za
o Europe: nic.nordu.net
ftp.nis.garr.it
o Pacific Rim: munnari.oz.a
o US East Coast: ds.internic.net
o US West Coast: ftp.isi.edu
Internet-Drafts are also available by mail.
Send a message to: mailserv at ds.internic.net. In the body type:
"FILE /internet-drafts/draft-ietf-atommib-perfhistTC-01.txt".
NOTE: The mail server at ds.internic.net can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e., documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version
of the Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <19961029145533.I-D at ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-atommib-perfhistTC-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-atommib-perfhistTC-01.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19961029145533.I-D at ietf.org>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa07585; 30 Oct 96 11:07 EST
Received: from mail2.panix.com by ietf.org id aa07273; 30 Oct 96 11:05 EST
Received: from oppedahl.dialup.access.net (oppedahl.dialup.access.net [166.84.254.90]) by mail2.panix.com (8.7.5/8.7.1/PanixM1.0) with SMTP id LAA01757; Wed, 30 Oct 1996 11:02:07 -0500 (EST)
Message-Id: <2.2.16.19961030160519.7bff9bee at popserver.panix.com>
X-Sender: oppedahl at popserver.panix.com
X-Mailer: Windows Eudora Pro Version 2.2 (16)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 30 Oct 1996 11:05:19 -0500
To: Bill Frezza <frezza at interramp.com>,
Dave Crocker <dcrocker at brandenburg.com>
Sender:ietf-request at ietf.org
From: Carl Oppedahl <carl at oppedahl.com>
Subject: Re: NEWDOM: Re: The cartel begins to crumble?
Cc: ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
At 10:03 AM 10/30/96 -0500, Bill Frezza wrote:
>Dave Crocker writes:
>
>>You may have concerns over the current operation of IANA. You may
>>have specific changes in mind. But rest assured that the solution will
>>require a central authority, if the solution is to be viable.
>
>HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
>Please describe how this central authority will compel people around the
>world to obey its edicts.
Pretty simple -- whoever controls the update stream into the root level
servers can compel anybody to do anything. Right now, that's Network
Solutions, Inc. They use the threat of cutting off domain names (feeding
data into the root level servers to make a domain name unusable) to
accomplish whatever they want, as was evidenced in numerous domain name
dispute cases. By and large, people obey NSI's edicts. The rare exception
(it's happened only seven times so far) is the domain name owner who refuses
to obey NSI's edict and says it wants to keep its domain name. Such a
domain name owner sues NSI and obtains a court order blocking NSI from
sending the cutoff message to the root name servers.
For more on the lawsuits against NSI, see <http://www.patents.com/nsi.sht>.
Received: from ietf.org by ietf.org id aa09807; 30 Oct 96 11:36 EST
Received: from mail3.microsoft.com by ietf.org id aa09711; 30 Oct 96 11:34 EST
Received: by INET-03-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56)
id <01BBC63D.3B1F1CA0 at INET-03-IMC.itg.microsoft.com>; Wed, 30 Oct 1996 08:34:57 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-68-MSG-961030163319Z-4259 at INET-03-IMC.itg.microsoft.com>
Sender:ietf-request at ietf.org
From: Eric Fleischman <ericfl at microsoft.com>
To: "'chikkanr at agcs.com'" <chikkanr at agcs.com>,
'Claude Huss' <claude at ca.mew.com>
Cc: "'rgowda at blr.sni.de'" <rgowda at blr.sni.de>,
"'krishnas at agcs.com'" <krishnas at agcs.com>,
"'raosa at agcs.com'" <raosa at agcs.com>, "'dorian at cic.net'" <dorian at cic.net>,
"'mohta at necom830.hpcl.titech.ac.jp'" <mohta at necom830.hpcl.titech.ac.jp>,
"'ietf at ietf.org'" <ietf at ietf.org>
Subject: RE: The cartel begins to crumble?
Date: Wed, 30 Oct 1996 08:33:19 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 57 TEXT
Source-Info: From (or Sender) name not authenticated.
I think that it is self-evident that English is the language used on
IETF email aliases, within RFCs, and within the major sessions of IETF
meetings. This does inadvertedly exclude many who are uncomfortable with
that language. However, the alternative is to either require that
everyone learn a larger set of languages or else to hire translators.
I can well imagine some magnificent Monty Python skits examining the
practical implications of the latter two possibilities. This all reminds
me of the cartoon where the wife is angrily saying to her husband "This
is the last time I'll let you order in French" as the waiters are
struggling to carry a stuffed rhinoceros to their table.
>----------
>From:Claude Huss[SMTP:claude at ca.mew.com]
>Sent:Tuesday, October 29, 1996 11:09 PM
>To:chikkanr at agcs.com
>Cc:rgowda at blr.sni.de; krishnas at agcs.com; raosa at agcs.com; dorian at cic.net;
>mohta at necom830.hpcl.titech.ac.jp; ietf at ietf.org
>Subject:Re: The cartel begins to crumble?
>
>From chikkanr at agcs.com:
>>
>> I agree that there has to be a common language for interaction and it
>> is nobody's fault that English is the lingua franca.
>>
>> It might be a handicap for someone who doesn't know English but I do
>> not think that it is that difficult to pick up.
>>
>> By the way, my native language is not English.
>>
>> Also one should be aware of the origins of the internet in the first
>> place.
>>
>> Regards
>
>
>I believe this kind of discussion is out of proportions. In fact, I wonder
>if there is any *REAL* restriction to issue an RFC in any other language.
>Of course, people do in English for the sake of making them be understood
>by the majority.
>
>Also, to say that IETF is a meeting in *English* is to be short-sighted.
>I have seen people talking in many languages around all the meetings. I
>also had the opportunity to talk with Mr. Ohta in Japanese last IETF. Also,
>I had opportunity to speak in other people in my broken Mandarin, Spanish..
>Unfortunately I cannot understand Hebrew or many other languages people
>around speak between themselves. I also think there is no *REAL*
>restrictions to even have a presentation in Japanese, if mr. Ohta so
>desires. I might be there, but how many others?
>
>Oh... Btw... Isnt mr. ohta the same person who 5 years ago tried to deny
>to foreigners living in Japan to have a newsgroup in English?... I wonder...
>
>--
>Claude Huss
>
>
Received: from ietf.org by ietf.org id aa10153; 30 Oct 96 11:42 EST
Received: from dxmint.cern.ch by ietf.org id aa10056; 30 Oct 96 11:40 EST
Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch
with SMTP id RAA22983 for <ietf at ietf.org>; Wed, 30 Oct 1996 17:39:51 +0100 (MET)
Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM)
id AA31904; Wed, 30 Oct 1996 17:39:50 +0100
Message-Id: <9610301639.AA31904 at dxcoms.cern.ch>
Subject: Re: The cartel begins to crumble?
To: ietf at ietf.org
Date: Wed, 30 Oct 1996 17:39:50 +0100 (MET)
Sender:ietf-request at ietf.org
From: Brian Carpenter CERN-CN <brian at dxcoms.cern.ch>
In-Reply-To: <199610301511.KAA04956 at io.org> from "George T. McCallum" at Oct 29, 96 10:09:54 pm
X-Mailer: ELM [version 2.4 PL25]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Source-Info: From (or Sender) name not authenticated.
Masataka,
Just in case my words in French were misinterpreted -
I was trying to make the same point as you, by irony:
The only practical choice of language is English, but
those of us for whom it is our native language, must
help our non-English speaking colleagues all we can.
Having worked for 20 years about half in my native
language and half in a foreign language, I feel great
sympathy for non-English speakers who are willing
to step up to the microphone in IETF meetings.
Brian Carpenter
Received: from ietf.org by ietf.org id aa11028; 30 Oct 96 11:56 EST
Received: from socks2.raleigh.ibm.com by ietf.org id aa10891;
30 Oct 96 11:53 EST
Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0)
id AA2375470; Wed, 30 Oct 1996 11:48:13 -0500
Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.83.125]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id LAA74114; Wed, 30 Oct 1996 11:48:13 -0500
Received: from localhost.raleigh.ibm.com by ludwigia.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL)
id AA16018; Wed, 30 Oct 1996 11:53:24 -0500
Message-Id: <9610301653.AA16018 at ludwigia.raleigh.ibm.com>
To: Bill Frezza <frezza at interramp.com>
Cc: Dave Crocker <dcrocker at brandenburg.com>, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Subject: Re: The cartel begins to crumble?
In-Reply-To: Your message of "Wed, 30 Oct 1996 10:03:41 EST."
<v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Date: Wed, 30 Oct 1996 11:53:14 -0400
Sender:ietf-request at ietf.org
From: Thomas Narten <narten at raleigh.ibm.com>
Source-Info: From (or Sender) name not authenticated.
Bill Frezza <frezza at interramp.com> writes:
>>You may have concerns over the current operation of IANA. You may
>>have specific changes in mind. But rest assured that the solution will
>>require a central authority, if the solution is to be viable.
>Please describe how this central authority will compel people around the
>world to obey its edicts.
I think you have it backwards. How can anyone force the vast installed
base to configure their systems to use the *unofficial* root servers,
including the new ones that haven't even been created yet?
Dave Crocker's comments were right on. Here's another take. Suppose
that someone thought the current telephone numbering scheme was broken
because the allocation of telephone numbers was managed
centrally. They go off and start assigning their own numbers, so that
folks can come up with cutesy 1-CAL-LM-ENOW numbers. Of course that's
silly, you say. That can't work because addresses _must_ be unique.
Well, the same argument holds for domain names. They must be
_globally_ _unique_, and the only way to insure uniqueness is through
a centralized management/coordination of the name space, and that
includes managing the TLDs. _Someone_ has to do it. Arguments about
_who_ should manage the space are interesting (to some), arguments
saying no management is needed miss a fundamental point.
Thomas
Received: from ietf.org by ietf.org id aa13190; 30 Oct 96 12:35 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa13080; 30 Oct 96 12:32 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id MAA23928; Wed, 30 Oct 1996 12:31:32 -0500
Message-Id: <199610301731.MAA23928 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Masataka Ohta <mohta at necom830.hpcl.titech.ac.jp>
Cc: ietf at ietf.org
Subject: Re: The cartel begins to crumble?
In-Reply-To: Your message of "Wed, 30 Oct 1996 17:31:31 +0200."
<199610300831.RAA08803 at necom830.hpcl.titech.ac.jp>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <199610300831.RAA08803 at necom830.hpcl.titech.ac.jp>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1654959000P";
BAD MSG:
micalg=pgp-md5; protocol="application/pgp-signature"
ontent-Transfer-Encoding: 7bit
Date: Wed, 30 Oct 1996 12:31:31 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1654959000P
Content-Type: text/plain; charset=us-ascii
On Wed, 30 Oct 1996 17:31:31 +0200, Masataka Ohta said:
> Forcing English only is a lot better to force English and French at
> the same time.
> ...
> But, what I have experienced so far in IETF, instead, is that
> technically cornered people suddenly attacked my English was
> not perfect.
<Note please - this is *NOT* intended as a flame, but as personal
commentary on how this sort of thing arises>...
Masataka: I can appreciate the problems you face sometimes making
yourself understood. Dealing with *any* non-native language can
create a grammatical hodgepodge that the listener is unable to parse
effectively(*). For instance, the first sentence I quoted got 3
readings before I gave up trying to decide if you were saying it was
better to force English only, or English/French.
Edited to support English only:
> Forcing English only is a lot better than forcing English and French at
> the same time.
Edited to support English/French:
> Forcing English only, it would be a lot better to force English and French at
> the same time.
The reason that flame wars start about such details is because the
primary goal of the IETF is to produce RFCs and the like, which are
intended to be usable to actually write working code from
specifications. It's actually quite hard to write clear concise
English.
Fortunately, most people on the various working groups are able to
recognise it when they see it, and offer editorial criticism.
Unfortunately, very few of us (myself included) have what it takes to
be a great editor - constructive criticism is hard to give
effectively, especially in a context such as this. I mean - we're
talking here about a group of people who make a living talking to
inanimate objects made of melted sand.
I think too many of us assume that just because we can break out the
software mallet to fix offending code fragments, that we can use a
similar mallet on verbiage written by somebody else. I'm sure I've
used said mallet myself on more than a few occasions...
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
(*) My parents are Latvian immigrants, and although they have both
acquired reasonable skill with English in the 40-some-odd years
they've been here, my mother still manages to astound me when changing
languages mid-sentence. English supports the concept of order of
part-of-speech - subject, verb, indirect object, direct object and so
on. Latvian, on the other hand, is inflected, so the part of speech
of a word can be determined by inspection. As such, sentences are
sorted in "most to least" important order. This causes problems when
she starts off in Latvian, uses up the indirect object and the verb,
decides to drop back to English, and realizes she already passed the
verb, leaving no place to put the subject....
--==_Exmh_-1654959000P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMneQ8NQBOOoptg9JAQHNngQAliEM0/3P60inPrH8XjMoljC/StrZNbnT
eO8hUoXc08xSgLxKrBvvqN/FZp64RETY9M01920Kjb3PaDNhHVSvX6IbBB/VURGA
6DP+IJMm6P/6lAL8+SVdoZ10QDGw1HDaSIrbwbVFeDmYlMwlHK/wvd7AoHG0mLQ2
q2Dxy5vDHtM=
=POvl
-----END PGP MESSAGE-----
--==_Exmh_-1654959000P--
Received: from ietf.org by ietf.org id aa13699; 30 Oct 96 12:47 EST
Received: from netcom9.netcom.com by ietf.org id aa13463; 30 Oct 96 12:42 EST
Received: (from wolfgang at localhost) by netcom9.netcom.com (8.6.13/Netcom)
id JAA15535; Wed, 30 Oct 1996 09:40:58 -0800
Date: Wed, 30 Oct 1996 09:40:58 -0800
Sender:ietf-request at ietf.org
From: Wolfgang Henke <wolfgang at netcom.com>
Message-Id: <199610301740.JAA15535 at netcom9.netcom.com>
To: frezza at interramp.com
Subject: Re: The cartel begins to crumble?
Cc: com-pri at psi.com, ietf at ietf.org, namedroppers at internic.net, newdom at ar.com
Source-Info: From (or Sender) name not authenticated.
HONEST QUESTION (please cc: me as I do not monitor all these groups)
Please describe how this central authority will compel people around the
world to obey its edicts.
Thanks you,
Bill Frezza
CommunicationsWeek
frezza at interramp.com
http://techweb.cmp.com/nc/frezza/frezza.html
It cant compel anything. It works more like the ITU which issues
*recommendations* (like for example ITU-T V.34 modem standards).
Companies or users decide voluntarily to use these recommendations
if they see a benefit in them. Some ITU recommendations get generally
bypassed, others are widely implemented.
Wolfgang
Wolfgang Henke wolfgang at whnet.com . http://www.whnet.com
WH Networks ... ftp://ftp.whnet.com
2672 Bayshore Parkway, Suite 503 .......... fax (415) 390 9317
Mountain View, CA 94043 .................. (415) 390 9316
Received: from ietf.org by ietf.org id aa15411; 30 Oct 96 13:10 EST
Received: from red.jnx.com by ietf.org id aa15236; 30 Oct 96 13:08 EST
Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com (8.7.6/8.7.3) with ESMTP id KAA10001; Wed, 30 Oct 1996 10:07:04 -0800 (PST)
Received: (from tli at localhost) by chimp.jnx.com (8.7.5/8.7.3) id KAA10762; Wed, 30 Oct 1996 10:06:57 -0800 (PST)
Date: Wed, 30 Oct 1996 10:06:57 -0800 (PST)
Message-Id: <199610301806.KAA10762 at chimp.jnx.com>
Sender:ietf-request at ietf.org
From: Tony Li <tli at jnx.com>
To: Bill Frezza <frezza at interramp.com>
Cc: ietf at ietf.org, namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
In-reply-to: frezza at interramp.com's message of 30 Oct 96 15:03:41 GMT
Subject: Re: The cartel begins to crumble?
References: <v0310060bae9c04f0474c at [205.214.160.86]>
BAD MSG:
<v03007804ae9cd2f9dbf1 at [38.26.44.118]>
ource-Info: From (or Sender) name not authenticated.
>You may have concerns over the current operation of IANA. You may
>have specific changes in mind. But rest assured that the solution will
>require a central authority, if the solution is to be viable.
HONEST QUESTION (please cc: me as I do not monitor all these groups)
Please describe how this central authority will compel people around the
world to obey its edicts.
The authority need not "compel". The authority only has authority because
the public agrees to abide by the decisions of the central authority.
Remember that the Internet is a cooperative anarchy, not a dictatorship.
If the cooperation ceases, then the Internet simply implodes.
The implication is that the authority can be replaced wholesale, redirected
or repaired, but the need for a central authority to administrate the top
of the DNS (or any other) hierarchy remains.
Tony
Received: from ietf.org by ietf.org id aa17882; 30 Oct 96 13:34 EST
Received: from mail4.microsoft.com by ietf.org id aa17675; 30 Oct 96 13:32 EST
Received: by mail4.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56)
id <01BBC64D.A48D0F70 at mail4.microsoft.com>; Wed, 30 Oct 1996 10:32:25 -0800
Message-ID: <c=US%a=_%p=msft%l=RED-69-MSG-961030183134Z-5613 at mail4.microsoft.com>
Sender:ietf-request at ietf.org
From: Peter Ford <peterf at microsoft.com>
To: 'Dave Crocker' <dcrocker at brandenburg.com>,
'Bill Frezza' <frezza at interramp.com>
Cc: "'ietf at ietf.org'" <ietf at ietf.org>,
"'namedroppers at internic.net'" <namedroppers at internic.net>,
"'com-pri at psi.com'" <com-pri at psi.com>, "'newdom at ar.com'" <newdom at ar.com>
Subject: RE: The cartel begins to crumble?
Date: Wed, 30 Oct 1996 10:31:34 -0800
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 48 TEXT
Source-Info: From (or Sender) name not authenticated.
Bill,
You have a simple world model problem. Your statement seems to stem
from a belief that people do things because they are compelled by others
to do them. Consider an alternative model whereby people elect to do
things because it allows them to do things with a large body of like
minded entities. Alternatively, consider a model where people follow
leadership.
While one can say there is not global agreement on how addresses and
names are managed, it is pretty hard to say that the ideas are not
shopped around, responses not measured, and pragmatic solutions not
being put into place. As evidence, there has been substantial evolution
of the processes over the last 5 years (RIPE, APNIC, other national and
organizational administration units coming into existence) that leads me
to believe that we will continue to see constructive evolutionary
changes.
As long as people can continue to get Internet names and addresses and
interconnect and the perceived cost of these actions is low, it is
likely you will see little effort to radically change things.
One area worth investigating, since you seem to have interest in this,
is how we might get a system that is easier/faster. Bringing solutions
along with the problem statements would help make your points.
cheers, peter
>>>
>HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
>Please describe how this central authority will compel people around the
>world to obey its edicts.
>
>Thanks you,
>
>Bill Frezza
>CommunicationsWeek
>frezza at interramp.com
>http://techweb.cmp.com/nc/frezza/frezza.html
>
>
>
Received: from ietf.org by ietf.org id aa18413; 30 Oct 96 13:48 EST
Received: from black-ice.cc.vt.edu by ietf.org id aa18105; 30 Oct 96 13:43 EST
Received: from black-ice.cc.vt.edu (valdis at LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.2/8.8.2) with ESMTP id NAA53976; Wed, 30 Oct 1996 13:42:27 -0500
Message-Id: <199610301842.NAA53976 at black-ice.cc.vt.edu>
X-Mailer: exmh version 1.6.9 8/22/96
To: Bill Frezza <frezza at interramp.com>
Cc: Dave Crocker <dcrocker at brandenburg.com>, ietf at ietf.org,
namedroppers at internic.net, com-pri at psi.com, newdom at ar.com
Subject: Re: The cartel begins to crumble?
In-Reply-To: Your message of "Wed, 30 Oct 1996 10:03:41 EST."
<v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Sender:ietf-request at ietf.org
From: Valdis.Kletnieks at vt.edu
X-Url: http://black-ice.cc.vt.edu/~valdis/
References: <Pine.BSI.3.93.961029092827.183I-100000 at sidhe.memra.com>
<v03007804ae9cd2f9dbf1 at [38.26.44.118]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-1489451064P";
BAD MSG:
micalg=pgp-md5; protocol="application/pgp-signature"
ontent-Transfer-Encoding: 7bit
Date: Wed, 30 Oct 1996 13:42:27 -0500
Source-Info: From (or Sender) name not authenticated.
--==_Exmh_-1489451064P
Content-Type: text/plain; charset=us-ascii
On Wed, 30 Oct 1996 10:03:41 EST, Bill Frezza said:
> Dave Crocker writes:
>
> >You may have concerns over the current operation of IANA. You may
> >have specific changes in mind. But rest assured that the solution will
> >require a central authority, if the solution is to be viable.
>
> HONEST QUESTION (please cc: me as I do not monitor all these groups)
>
> Please describe how this central authority will compel people around the
> world to obey its edicts.
Umm.. if you don't play by the rules, you can't reach domains that DO play
by the rules?
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
--==_Exmh_-1489451064P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.2
iQCVAwUBMnehkNQBOOoptg9JAQGkhgQAitIzjfGjS5b/mweL8QIMCJHteCppjiyg
TlyQ6ljhqfnhsk4owvoFxPwgTcQyfAycy3lspYFQP8rGTQ/bHiwQAUUyF1RohBnf
9V0aLu0q9pYHZLOrCSiApOdDUeWVh5wP28ZRTR8uc92TFUfi1gn8VcwihX7USf7k
DyiQx/+DEHM=
=fIew
-----END PGP MESSAGE-----
--==_Exmh_-1489451064P--
Received: from ietf.org by ietf.org id aa19110; 30 Oct 96 13:58 EST
Received: from zephyr.isi.edu by ietf.org id aa18685; 30 Oct 96 13:52 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA21205>; Wed, 30 Oct 1996 10:51:00 -0800
Message-Id: <199610301851.AA21205 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2038 on RTP Payload Format for MPEG1/MPEG2 Video
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Oct 96 10:53:49 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2038:
Title: RTP Payload Format for MPEG1/MPEG2 Video
Author: D. Hoffman, G. Fernando, V. Goyal
Date: October 1996
Mailbox: don.hoffman at eng.sun.com,
gerard.fernando at eng.sun.com,
goyal at precept.com
Pages: 11
Characters: 23,266
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2038.txt
This memo describes a packetization scheme for MPEG video and audio
streams. The scheme proposed can be used to transport such a video or
audio flow over the transport protocols supported by RTP. Two
approaches are described. The first is designed to support maximum
interoperability with MPEG System environments. The second is
designed to provide maximum compatibility with other RTP-encapsulated
media streams and future conference control work of the IETF. This RFC
is a product of the Audio/Video Transport Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should be sent
to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961030104807.RFC at ISI.EDU>
SEND /rfc/rfc2038.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2038.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030104807.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa20514; 30 Oct 96 14:02 EST
Received: from zephyr.isi.edu by ietf.org id aa19435; 30 Oct 96 13:59 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA21752>; Wed, 30 Oct 1996 10:58:44 -0800
Message-Id: <199610301858.AA21752 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2035 on RTP Payload Format for JPEG Video
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Oct 96 11:01:33 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2035:
Title: RTP Payload Format for JPEG-compressed Video
Author: L. Berc, W. Fenner, R. Frederick, S. McCanne
Date: October 1996
Mailbox: berc at pa.dec.com, fenner at cmf.nrl.navy.mil,
frederick at parc.xerox.com, mccanne at ee.lbl.gov
Pages: 16
Characters: 30,079
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2035.txt
This memo describes the RTP payload format for JPEG video streams.
The packet format is optimized for real-time video streams where codec
parameters change rarely from frame to frame. This RFC is a product of
the Audio/Video Transport Working Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961030105536.RFC at ISI.EDU>
SEND /rfc/rfc2035.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2035.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030105536.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id aa21058; 30 Oct 96 14:07 EST
Received: from zephyr.isi.edu by ietf.org id aa20804; 30 Oct 96 14:05 EST
Received: from pog.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23)
id <AA22143>; Wed, 30 Oct 1996 11:04:22 -0800
Message-Id: <199610301904.AA22143 at zephyr.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2029 on RTP Payload Format
Cc: rfc-ed at isi.edu
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 30 Oct 96 11:07:11 PST
Sender:ietf-announce-request at ietf.org
From: RFC Editor <rfc-ed at isi.edu>
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2029:
Title: RTP Payload Format of Sun's CellB Video Encoding
Author: M. Speer, D. Hoffman
Date: October 1996
Mailbox: michael.speer at eng.sun.com, don.hoffman at eng.sun.com
Pages: 6
Characters: 11,216
Updates/Obsoletes: None
URL: ftp://ds.internic.net/rfc/rfc2029.txt
This memo describes a packetization scheme for the CellB video
encoding. The scheme proposed allows applications to transport CellB
video flows over protocols used by RTP. This document is meant for
implementors of video applications that want to use RTP and
CellB. This RFC is a product of the Audio/Video Transport Working
Group of the IETF.
This is now a Proposed Standard Protocol.
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state and
status of this protocol. Distribution of this memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST at CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST at ISI.EDU.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info at ISI.EDU with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info at ISI.EDU
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to admin at DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
Submissions for Requests for Comments should be sent to
RFC-EDITOR at ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Mary Kennedy
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv at ds.internic.net"
Content-Type: text/plain
Content-ID: <961030110302.RFC at ISI.EDU>
SEND /rfc/rfc2029.txt
--OtherAccess
Content-Type: Message/External-body;
name="rfc2029.txt";
site="ds.internic.net";
access-type="anon-ftp";
directory="rfc"
Content-Type: text/plain
Content-ID: <961030110302.RFC at ISI.EDU>
--OtherAccess--
--NextPart--
Received: from ietf.org by ietf.org id ab22155; 30 Oct 96 14:22 EST
Received: from nausicaa.mew.com by ietf.org id aa21839; 30 Oct 96 14:20 EST
Received: from yupa.ca.mew.com (yupa.ca.mew.com [158.118.11.11]) by nausicaa.mew.com (8.6.11+2.5Wb2/3.4W-NAUSICAA-950728) with ESMTP id LAA02038; Wed, 30 Oct 1996 11:19:34 -0800
Received: from kiki.ca.mew.com (kiki.ca.mew.com [158.118.11.12]) by yupa.ca.mew.com (8.6.11+2.5Wb2/3.4W-YUPA-950728) with SMTP id LAA07801; Wed, 30 Oct 1996 11:16:00 -0800
Sender:ietf-request at ietf.org
From: Claude Huss <claude at ca.mew.com>
Message-Id: <199610301916.LAA07801 at yupa.ca.mew.com>
Subject: Re: The cartel begins to crumble?
To: Wolfgang Henke <wolfgang at netcom.com>
Date: Wed, 30 Oct 1996 11:19:32 -0800 (PST)
Cc: frezza at interramp.com, com-pri at psi.com, ietf at ietf.org,
namedroppers at internic.net, newdom at ar.com
In-Reply-To: <199610301740.JAA15535 at netcom9.netcom.com> from "Wolfgang Henke" at Oct 30, 96 09:40:58 am
X-Disclaimer: Opinions expressed here are strictly my own
Organization: Matsushita Electric Works, Ltd.
X-Mailer: ELM [2.4 PL23.Japanese] (Claude Huss)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Length: 1306
Source-Info: From (or Sender) name not authenticated.
To be sincere, this seems like a cheap kind of journalism. The guy is
interested to write something about what people think about standards
and just created a flame to make people do his own work...
I am sorry if I am wrong, but I got this impression.
Claude
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
