RFD: comp.std.cli
Nigel Perry
unmoderated group comp.std.cli
This is a formal Request For Discussion (RFD) for the creation of
the worldwide unmoderated newsgroup comp.std.cli. This is not
a Call for Votes (CFV); you cannot vote at this time. Procedural
details are below.
Newsgroup line:
comp.std.cli Discussions on the ECMA/ISO Common Language.
RATIONALE: comp.std.cli
There are no newsgroups to discuss the ECMA/ISO Standard for the Common
Language Infrastructure (CLI). There are multiple implementations of
this standard; including the Microsoft product C#, Mono, Rotor and
DotGNU; and a forum for the discussion of the Standard and possible
future directions would be of benefit to the community. The ECMA
Technical Groups for the CLI and C# are proposing this newsgroup and
will monitor the postings.
CHARTER: comp.std.cli
The purpose of this newsgroup shall be to establish and maintain a forum
for the open discussion of issues related to the ECMA/ISO CLI Standard.
Topics may include but are not limted to matters such as the following:
- Meaning of the Standard
- Impementation of the Standard
- Issues arising from implementing the Standard on different hosts
- Possible errors/omissions in the Standard
- Possible future directions of the Standard
ECMA and ISO have formal procedures for input to, and reporting errors in,
Standards. This group will in no way replace those procedures. The group
is intended as a forum for the community. However the ECMA Technical
Group for the Standard will monitor and take note of discussions on the
newsgroup.
END CHARTER.
PROCEDURE:
This is a request for discussion, not a call for votes. In this phase
of the process, any potential problems with the proposed newsgroups
should be raised and resolved. The discussion period will continue
for a minimum of 21 days (starting from when the first RFD for this
proposal is posted to news.announce.newgroups), after which a Call For
Votes (CFV) will be posted by a neutral vote taker. Please do not
attempt to vote until this happens.
All discussion of this proposal should be posted to news.groups.
This RFD attempts to comply fully with the Usenet newsgroup creation
guidelines outlined in "How to Create a New Usenet Newsgroup" and "How
to Format and Submit a New Group Proposal". Please refer to these
documents (available in news.announce.newgroups) if you have any
questions about the process.
DISTRIBUTION:
This RFD has been posted to the following newsgroups:
news.announce.newgroups
news.groups
and the following mailing lists:
<dotnet...@di.unipi.it>
Subcribe via: dotnet-ssc...@di.unipi.it
<dotnet...@discuss.develop.com>
<dotn...@discuss.develop.com>
<dotne...@discuss.develop.com>
Proponent: Nigel Perry <ni...@cosc.canterbury.ac.nz>
(on behalf of ECMA TC39 TG2&3)
Proponent: Rex Jaeschke <r...@rexjaeschke.com>
(on behalf of ECMA TC39 TG2&3)
Nigel Perry
Markus Kuhn
tuning:
For example:
> - Impementation of the Standard
^^l
> comp.std.cli Discussions on the ECMA/ISO Common Language.
Better: ECMA/ISO Common Language Infrastructure standard
> comp.std.csharp Discussions on the ECMA/ISO Common Language.
No: ECMA/ISO C# programming language standard
The words "Discussions on the" are redundant for describing a USENET
group purpose, because almost all are for discussion. The "std"
is frequently missinterpreted as standing for "students", therefore
mentioning the word "standard" in the short description would be a very
good idea for all new additions under comp.std.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Mean Green Dancing Machine
Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
>
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.cli
Consider this a repeat of what I just posted about comp.std.csharp:
where's the traffic for this group? Perhaps you should create
comp.lang.cli first.
--
--- Aahz <*> (Copyright 2003 by aa...@pobox.com)
Hugs and backrubs -- I break Rule 6 http://rule6.info/
Androgynous poly kinky vanilla queer het Pythonista
blog blog blog GINGER blog blog blog GINGER
Eric Gunnerson
like to have this newsgroup, please reply to this message, making sure to
leave news.groups in the list of newsgroups.
"Nigel Perry" <ni...@cosc.canterbury.ac.nz> wrote in message
news:10576239...@isc.org...
Jon Skeet
> In article <10576243...@isc.org>,
> Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
> >
> > REQUEST FOR DISCUSSION (RFD)
> > unmoderated group comp.std.cli
>
> Consider this a repeat of what I just posted about comp.std.csharp:
> where's the traffic for this group? Perhaps you should create
> comp.lang.cli first.
I don't believe that would be appropriate. The CLI is a platform rather
than a language. Having had a quick look down the groups available on
my server, I've no idea where it would fit in. Possibly just comp.cli,
or comp.arch.cli, I guess - unless a whole new tree (comp.platform.*)
were to be started.
--
Jon Skeet - <sk...@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too
Thomas Plum
Mean Green Dancing Machine
Jon Skeet <sk...@pobox.com> wrote:
>Mean Green Dancing Machine <aa...@pobox.com> wrote:
>> In article <10576243...@isc.org>,
>> Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
>>>
>>> REQUEST FOR DISCUSSION (RFD)
>>> unmoderated group comp.std.cli
>>
>> Consider this a repeat of what I just posted about comp.std.csharp:
>> where's the traffic for this group? Perhaps you should create
>> comp.lang.cli first.
>
>I don't believe that would be appropriate. The CLI is a platform rather
>than a language. Having had a quick look down the groups available on
>my server, I've no idea where it would fit in. Possibly just comp.cli,
>or comp.arch.cli, I guess - unless a whole new tree (comp.platform.*)
>were to be started.
The way I see it, if Parrot were to get its own newsgroup, it'd be in
comp.lang.*; in what way is CLI different? If comp.lang.* really isn't
appropriate, my next suggestion would be comp.software, but
comp.arch.cli would work well enough.
Russ Allbery
> The way I see it, if Parrot were to get its own newsgroup, it'd be in
> comp.lang.*; in what way is CLI different?
It's actually a standard?
> If comp.lang.* really isn't appropriate, my next suggestion would be
> comp.software, but comp.arch.cli would work well enough.
If they want to discuss the standardization aspects of CLI, why not call
the group what it's actually for? No one is working to standardize Parrot
so far as I know.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Mean Green Dancing Machine
Russ Allbery <r...@stanford.edu> wrote:
>Mean Green Dancing Machine <aa...@pobox.com> writes:
>>
>> The way I see it, if Parrot were to get its own newsgroup, it'd be in
>> comp.lang.*; in what way is CLI different?
>
>It's actually a standard?
>
>> If comp.lang.* really isn't appropriate, my next suggestion would be
>> comp.software, but comp.arch.cli would work well enough.
>
>If they want to discuss the standardization aspects of CLI, why
>not call the group what it's actually for? No one is working to
>standardize Parrot so far as I know.
You trimmed too much of the context: I was suggesting that a group
somewhere other than comp.std.* would be appropriate to establish Usenet
traffic. The question then becomes where it would go. Note carefully
that I'm not objecting to comp.std.cli, but it's somewhat unusual to
create such a group in the absence of existing traffic.
Russ Allbery
> I was suggesting that a group somewhere other than comp.std.* would be
> appropriate to establish Usenet traffic.
And I was disagreeing and pointing out that your Parrot example was a poor
one because it's not actually a standard, so obviously one wouldn't create
a group for it first in comp.std.*.
I didn't back up the thread to follow up specifically to your original
message. I instead combined my disagreement to both it and the message to
which I responded in a single message. I'm sorry if that was confusing.
Mean Green Dancing Machine
Russ Allbery <r...@stanford.edu> wrote:
>Mean Green Dancing Machine <aa...@pobox.com> writes:
>>
>> I was suggesting that a group somewhere other than comp.std.* would be
>> appropriate to establish Usenet traffic.
>
>And I was disagreeing and pointing out that your Parrot example was a poor
>one because it's not actually a standard, so obviously one wouldn't create
>a group for it first in comp.std.*.
Why do you disagree? Can you name a group in comp.std.* that wasn't
preceded by substantial Usent traffic outside of comp.std.*?
ru.ig...@usask.ca
I'm a news.groups regular. Like most of the regulars here, I usually
don't vote on proposals. However, I've got some comments and questions
for you (the proponent) which you might want to consider incorporating
your responses to in the next draft of your RFD ("2nd RFD:...").
In news.groups Nigel Perry <ni...@cosc.canterbury.ac.nz> wrote:
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.cli
[snip]
>Newsgroup line:
>comp.std.cli Discussions on the ECMA/ISO Common Language.
"Discussions on" is redundant, or at least a waste of space that
could be used to elaborate on the description (e.g. adding the
words "infrastructure" and "standard" somewhere in that line).
I think ECMA and ISO should also be removed.
>RATIONALE: comp.std.cli
The RATIONALE is basically intended to show reasons that READERS
want the new group. Your rationale is quite weak in that respect.
>There are no newsgroups to discuss the ECMA/ISO Standard for the Common
>Language Infrastructure (CLI).
Are there no other groups that include CLI as part of a broader
topic? How about non-Big-8 newsgroups (i.e. the M$ newsgroups?)?
If these are not applicable, please explain why not (e.g. the
discussions are more focussed on a less related topic). If these
are applicable, do you expect to take traffic from them. Is that
a good thing for those groups? Conversely, will creating this
group actually make things worse for those groups, e.g. creating
a situation where crossposting becomes significant?
If they exist and are applicable, why can't the discussion continue
there? If there is no reason, then there's no real motive for the
readers to move to a new group. On the other hand, if the readers
there are dissatified with the existing (broader) groups, you should
point those reasons out, and point out how the new group solves
their problems.
The real point is that you need enough readers to succeed in
creating the proposed group. Generally, these readers come from
other newsgroups (often related newsgroups). Where are your readers
going to come from? There's absolutely no indication of this here.
Do you have enough willing to vote? "Enough" in this case is more
than about 120 YES, which is not easy to attain because MOST readers
do NOT vote.
Do you expect the readers to come from outside of usenet? Why do
they want to? Often, folks reading mailing lists or web boards
are happier with that than usenet (e.g. usenet is too vulgar or
impolite). That being the case, it is a good idea to actually
survey those forums to get some idea of support, of how many
are willing to vote. Find out why they would prefer a usenet
forum rather than their current forum. If there is significant
support, try to ensure they have some experience with usenet by
the time they vote.
>There are multiple implementations of
>this standard; including the Microsoft product C#, Mono, Rotor and
^ use "-" instead of ";"
>DotGNU; and a forum for the discussion of the Standard and possible
^ use "-" instead of ";"
>future directions would be of benefit to the community.
"benefit" how? What's wrong with the way things are now that readers
feel inclined to flock to the new group?
>The ECMA
>Technical Groups for the CLI and C# are proposing this newsgroup and
>will monitor the postings.
This group is being created as an unmoderated forum. The above
statement almost sound as if moderation is desired. I am assuming
by "monitor" you mean they will simply be participants in discussions
and respond as such. A rephrase may be in order.
>CHARTER: comp.std.cli
Use PRESENT TENSE. Unfortunately, the CHARTER often is refered to
as a definitive document long after the group is created (unfortunate
because there's currently no mean "official" means of maintaining
charters). So you should try to make the CHARTER fairly future-proof.
>The purpose of this newsgroup shall be to establish and maintain a forum
>for the open discussion of issues related to the ECMA/ISO CLI Standard.
Thus, "shall be to establish and maintain a forum" is superfluous,
and you might as well use something like "comp.std.cli is an
unmoderated newsgroup for the discussion of the <whatever CLI stands
for> (CLI) standard".
Expand and explain "CLI" in one or two sentences.
Is it possible that CLI will cease to be associated with ECMA or ISO
in the future (at least by name)?
>Topics may include but are not limted to matters such as the following:
spelling: "limited"
commas: "... may include, but are not limted to, matters such ..."
>- Meaning of the Standard
>- Impementation of the Standard
spelling: Implementation
>- Issues arising from implementing the Standard on different hosts
>- Possible errors/omissions in the Standard
>- Possible future directions of the Standard
>ECMA and ISO have formal procedures for input to, and reporting errors in,
>Standards. This group will in no way replace those procedures. The group
>is intended as a forum for the community. However the ECMA Technical
>Group for the Standard will monitor and take note of discussions on the
>newsgroup.
I'm a bit (just a bit) worried about the explicit mention of
ECMA and ISO regarding my "future-proof" concern. Is there a
possibility that the standard maintainance will change hands
or reconfigure or be renamed?
Are there any concerns regarding binaries (either ascii encoded
executables or images)?
Are commercial postings going to be allowed. If so, I recommend
a "no more than once a month" limit.
>END CHARTER.
[snip]
>DISTRIBUTION:
>This RFD has been posted to the following newsgroups:
> news.announce.newgroups
> news.groups
Surely, there are other Big-8 or even alt.* groups that would
be concerned with the topic. If there are more than 3 groups
you come up with, you should discuss how to deal with the
extras with the Russ and company. This is because there are
(bonehead) ISPs out there that filter out any postings that
have more than 5 groups being crossposted to. You will probably
be given the option of posting pointers to the RFD/CFV in
n.a.n. or getting Russ and company to multipost your submissions.
ru
--
My standard proposals rant:
Quality, usefulness, merit, or non-newsgroups popularity of a topic
is more or less irrelevant in creating a new Big-8 newsgroup.
Usenet popularity is the primary consideration.
Russ Allbery
>> And I was disagreeing and pointing out that your Parrot example was a
>> poor one because it's not actually a standard, so obviously one
>> wouldn't create a group for it first in comp.std.*.
> Why do you disagree?
That's a question without a meaningful answer. You made an assertion that
a group probably should not be created in comp.std.* without creating a
group on that topic somewhere else first. I don't agree with that
assertion. You're the one making it and I don't consider it to be an
obvious argument, so I believe it falls on you to defend it.
> Can you name a group in comp.std.* that wasn't preceded by substantial
> Usent traffic outside of comp.std.*?
I don't believe this question is relevant. We don't name groups based on
where previous groups on completely different topics were created. We
name groups based on what people want to talk about.
If people are more interested in talking about the standardization of CLI
than about using it, or if people are already talking about using it
elsewhere, then it makes perfect sense to create the comp.std.* group
first. This seems quite plausible to me based on what I know of CLI. I
expect most of the discussion about using it is in the microsoft.*
hierarchy and largely uninterested in moving, which does not in any way
rule out the viability or usefulness of a comp.* group on the
standardization effort.
Nigel Perry
> In article <87n0fo7...@windlord.stanford.edu>,
> Russ Allbery <r...@stanford.edu> wrote:
> >Mean Green Dancing Machine <aa...@pobox.com> writes:
> >>
> >> The way I see it, if Parrot were to get its own newsgroup, it'd be in
> >> comp.lang.*; in what way is CLI different?
> >
> >It's actually a standard?
> >
> >> If comp.lang.* really isn't appropriate, my next suggestion would be
> >> comp.software, but comp.arch.cli would work well enough.
> >
> >If they want to discuss the standardization aspects of CLI, why
> >not call the group what it's actually for? No one is working to
> >standardize Parrot so far as I know.
>
> You trimmed too much of the context: I was suggesting that a group
> somewhere other than comp.std.* would be appropriate to establish Usenet
> traffic. The question then becomes where it would go. Note carefully
> that I'm not objecting to comp.std.cli, but it's somewhat unusual to
> create such a group in the absence of existing traffic.
The ECMA Standards process is ongoing and people have raised the issue
of a the lack of a place to discuss the Standard, report issues,
suggest enhancements, etc. with members of the Standards Committee.
Hence this RFD to provide a place for such traffic.
Nigel Perry
> RFD sounds promising, but needs a bit more proofreading and fine
> tuning:
>
> For example:
>
> > - Impementation of the Standard
> ^^l
:-( I take the blame for that one, but it's minor, unlike...
>
> > comp.std.cli Discussions on the ECMA/ISO Common Language.
> Better: ECMA/ISO Common Language Infrastructure standard
>
> > comp.std.csharp Discussions on the ECMA/ISO Common Language.
How did that one get past? It of course should be "...ISO C# ..." RFD
rules require a typo in a title to be fixed in a new RFD, so I'll get
this done ASAP, but before I do...
> No: ECMA/ISO C# programming language standard
>
> The words "Discussions on the" are redundant for describing a USENET
> group purpose, because almost all are for discussion. The "std"
> is frequently missinterpreted as standing for "students", therefore
> mentioning the word "standard" in the short description would be a very
> good idea for all new additions under comp.std.
I see no objection to the changed titles and see Markus' logic.
Anybody else before I resend the RFD (as per the Rules)?
Russ Allbery
> How did that one get past? It of course should be "...ISO C# ..." RFD
> rules require a typo in a title to be fixed in a new RFD, so I'll get
> this done ASAP, but before I do...
Not for this sort of thing; it's fine to fix an obvious mistake in the
short description at the time of the CFV.
Jon Skeet
> I see no objection to the changed titles and see Markus' logic.
> Anybody else before I resend the RFD (as per the Rules)?
I would wait for a few more days - there's significant discussion about
the RFD itself going on in various ways, so it's probably worth seeing
how that pans out a bit further before sending out the next one.
Jon Skeet
> >I don't believe that would be appropriate. The CLI is a platform rather
> >than a language. Having had a quick look down the groups available on
> >my server, I've no idea where it would fit in. Possibly just comp.cli,
> >or comp.arch.cli, I guess - unless a whole new tree (comp.platform.*)
> >were to be started.
>
> The way I see it, if Parrot were to get its own newsgroup, it'd be in
> comp.lang.*; in what way is CLI different? If comp.lang.* really isn't
> appropriate, my next suggestion would be comp.software, but
> comp.arch.cli would work well enough.
Is this Parrot as in the Perl interpreter core? (Going on a very quick
Google search.)
Going by http://www.parrotcode.org/ Parrot *is* a language as well as a
platform; the CLI happens to define an assembly language as well (CIL),
but I would imagine very few of the posts would be about that actual
language, they'd be about other features of the platform.
Given the many such platforms around these days (Parrot, CLI, Java-the-
platform) perhaps it's worth considering a new comp.xxx hierarchy - I'm
sure this won't be the last time this needs to be considered. Maybe
comp.arch is good enough - I certainly think it would be more
appropriate than comp.lang.cli though.
(On the other hand, no-one is currently proposing either of these... :)
Nigel Perry
> Nigel Perry <ni...@cosc.canterbury.ac.nz> writes:
>
> > How did that one get past? It of course should be "...ISO C# ..." RFD
> > rules require a typo in a title to be fixed in a new RFD, so I'll get
> > this done ASAP, but before I do...
>
> Not for this sort of thing; it's fine to fix an obvious mistake in the
> short description at the time of the CFV.
It transpires it was a cut'n'paste error when the RFD was split
(comp.std.cli & comp.std.csharp were sent in as one). The intended
title was:
ECMA/ISO Common Language Infrastructure Standard
I've checked with the moderator and this will be fixed in the CFV (or
a second RFD if that is needed for other reasons).
Joel Marcey
thread]
Hello,
Possible minor changes to the RFD notwithstanding, I believe the content of
this RFD is *valid* and the creation of such a group would be *quite
beneficial*. In short, such a group could help ensure a more quality
standard, and a quality standard is a large key to acceptance and widespread
use.
Now, I agree that the group will probably not break any traffic records. But
I don't think that is the overall goal for the creation of this group.
Currently, any broadly public discussion of the standard occurs on public
mailing lists (the most popular being the DevelopMentor DOTNET-XXXX lists).
However, the discussions on these lists are primarily focused upon actual
implementations of the standard (and consists of many how-to type questions,
etc). There is also quite a bit of noise as well. And while some efforts are
made by many in the ECMA task group responsible for the creation and
updating of the standard to monitor these lists, it can become quite
cumbersome to filter through the information to pick out legitimate
standards related inquiries.
The ECMA task group understands that the standard is not perfect. And while
the best and formal way to make provide input is to join ECMA and engage
within the task group, the task group understands this is not always
feasible. This group would serve as a public forum for comments re: the
standard, where the task group will monitor these comments and may even
discuss some relevant ones within the task group. This group will also serve
as a forum for input into possible future directions in the standard as
well. Of course, the task group cannot guarantee all or even any comments
will be discussed/incorporated into the standard (there is a formal process
for that), but the task group does have the intention to monitor this group
and act accordingly.
On the topic of "why isn't another mailing list dedicated to the standard
just created", my response to that is that, in my mind, mailing lists are
usually controlled by a specific entity (e.g. DevelopMentor) while usenet is
a more general, "public domain" type of discussion area.
The reason why this should be put under the heading of comp.std.cli is that
it should be made clear that this a group focused on the CLI standard and
its content, and not on specific implementations.
This seems to be a very legitimate request for a discussion group on a very
legitimate topic and technology. I am all for it.
Regards,
- Joel
* The views expressed here do not necessarily reflect those of Intel
Corporation, its subsidiaries, or its employees
Jim Riley
<ni...@cosc.canterbury.ac.nz> wrote:
> REQUEST FOR DISCUSSION (RFD)
> unmoderated group comp.std.cli
>Newsgroup line:
>comp.std.cli Discussions on the ECMA/ISO Common Language.
I recognize CLI as standing for Command Line Interface
Why not?
|comp.std.common-lang-infra Common Language Infrastructure standardization.
--
Jim Riley
Russ Allbery
> I recognize CLI as standing for Command Line Interface
> Why not?
> |comp.std.common-lang-infra Common Language Infrastructure standardization.
Because CLI is what everyone calls it. I think this would be much more
confusing and make it harder for people to find the group.
Erik Warmelink
"Eric Gunnerson" <eri...@microsoft.com> writes:
Did you get permission from the owner of nospam.com to use their
domain name?
[snip: 3 lines of drivel followed by a full quote]
--
begin dash-dash-space.exe
er...@selwerd.nl
David Harmon
Russ Allbery <r...@stanford.edu> wrote:
>> |comp.std.common-lang-infra Common Language Infrastructure standardization.
>
>Because CLI is what everyone calls it. I think this would be much more
>confusing and make it harder for people to find the group.
Oh nonsense.
http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=CLI
lists 21 meanings, and "Command Line Interface" is first (most
common meaning listed first.) "Common Language Infrastructure" is
number 15, and is identified as proprietary to Microsoft. I demand
that you cease this attempt to hijack the CLI TLA and further
jargonize the language, you Microsoft shill.
CLI is "Command Line Interface". Never heard of "Common Language
Infrastructure". Something in the name needs to be changed.
Maybe .ecma-cli, or you tell me what.
"no" vote anticipated.
Mean Green Dancing Machine
David Harmon <6x7l...@sneakemail.com> wrote:
>On Wed, 09 Jul 2003 14:04:48 -0700 in news.groups,
>Russ Allbery <r...@stanford.edu> wrote:
>
>>> |comp.std.common-lang-infra Common Language Infrastructure standardization.
>>
>>Because CLI is what everyone calls it. I think this would be much more
>>confusing and make it harder for people to find the group.
>
>Oh nonsense.
>http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=CLI
>lists 21 meanings, and "Command Line Interface" is first (most
>common meaning listed first.) "Common Language Infrastructure" is
>number 15, and is identified as proprietary to Microsoft. I demand
>that you cease this attempt to hijack the CLI TLA and further
>jargonize the language, you Microsoft shill.
<cough> While I'm in some agreement with you on your point, it's both
rude and false to characterize Russ as a Microsoft shill. (You might do
some research to find out what Russ has contributed to Open Source.)
Arch D. Robison
CLI is a platform. The ECMA standard calls it CLI; most of Microsoft's
documentation calls it CLR. Inspection of Google groups reveals the groups
comp.std.unix and comp.std.wireless, so this is not the first time
comp.std.* would be used for a platform. Microsoft is not the only CLI
vendor. See http://www.go-mono.com for a Linux implementation. Remember
that Fortran, C, and C++ were originated by commercial vendors too..
The newsgroup comp.std.cli would serve as the obvious place for CLI
implementers and users to go to comment on or discuss the ECMA/ISO standard.
Indeed, when I first found I wanted to comment on the standard, it was not
obvious where to do so. I solved the problem by joining the ECMA committee
for CLI, though this is an extreme solution.
Arch D. Robison Intel Corporation
arch.robison(at)intel.com 1906 Fox Drive
(217) 356-2288 Champaign IL 61820
Russ Allbery
>> Because CLI is what everyone calls it. I think this would be much more
>> confusing and make it harder for people to find the group.
> Oh nonsense.
> http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=CLI
> lists 21 meanings, and "Command Line Interface" is first (most
> common meaning listed first.) "Common Language Infrastructure" is
> number 15, and is identified as proprietary to Microsoft.
I didn't say that no one used CLI to mean anything else. I said that CLI
is the only meaningful name that has been given to the topic for which
this group is being created. It's not an ideal name by any stretch, but
any altnerative is going to be quite a bit worse in terms of helping
people find the group.
Standardization of "Command Line Interface" doesn't make a great deal of
sense, so hopefully the off-topic traffic will be relatively light.
> I demand that you cease this attempt to hijack the CLI TLA and further
> jargonize the language, you Microsoft shill.
*heh*.
Nigel Perry
I agree that CLI is command line interface, but it is also common
language infrastruture as used by ECMA. Maybe when coming up with
names we should all pick ones whose TLA's are unique, but that would
be rather hard.
People looking for ECMA CLI will find this group. People looking for a
group discussing the standardisation of command line interfaces may as
well, but I'm sure they'll realise it is not the one they're after.
Is this really a big problem?
Nigel, an AA member yet teetotal (its Automobile Association in the UK
& NZ)
George William Herbert
>David Harmon <sou...@netcom.com> writes:
>> Russ Allbery <r...@stanford.edu> wrote:
>>> Because CLI is what everyone calls it. I think this would be much more
>>> confusing and make it harder for people to find the group.
>
>> Oh nonsense.
>> http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=CLI
>> lists 21 meanings, and "Command Line Interface" is first (most
>> common meaning listed first.) "Common Language Infrastructure" is
>> number 15, and is identified as proprietary to Microsoft.
>
>I didn't say that no one used CLI to mean anything else. I said that CLI
>is the only meaningful name that has been given to the topic for which
>this group is being created. It's not an ideal name by any stretch, but
>any altnerative is going to be quite a bit worse in terms of helping
>people find the group.
>
>Standardization of "Command Line Interface" doesn't make a great deal of
>sense, so hopefully the off-topic traffic will be relatively light.
I have to respectfully disagree, to the degree that I'd vote no.
Using an acronym in group name == bad in general,
and using an acronym which many many more people
will misinterpret than get right == extremely bad.
That standardizing Command Line Interfaces isn't necessarily
a sensible idea doesn't mean that people will seek or
know the other acronyms it could mean. It would just
confuse them.
How about comp.std.commonlanguageinfrastructure_cli or something?
It's time to end the twenty character tyranny in Big 8 anyways.
Long Live the Long Components Revolution!
-george william herbert
gher...@retro.com
Jim Riley
wrote:
>David Harmon <sou...@netcom.com> writes:
>> Russ Allbery <r...@stanford.edu> wrote:
>
>>> Because CLI is what everyone calls it. I think this would be much more
>>> confusing and make it harder for people to find the group.
>
>> Oh nonsense.
>> http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=CLI
>> lists 21 meanings, and "Command Line Interface" is first (most
>> common meaning listed first.) "Common Language Infrastructure" is
>> number 15, and is identified as proprietary to Microsoft.
>
>I didn't say that no one used CLI to mean anything else. I said that CLI
>is the only meaningful name that has been given to the topic for which
>this group is being created. It's not an ideal name by any stretch, but
>any altnerative is going to be quite a bit worse in terms of helping
>people find the group.
How is "CLI" meaningful? It's an abbreviation. Why would a longer
name make it harder to find the group? Wouldn't it also make it
easier for people to avoid the group? If you had looked for such a
group a month ago, and next month it pops up among the new groups in
your newsreader, isn't common-language-infra more likely to attract
your attention than cli.
--
Jim Riley
Russ Allbery
> How is "CLI" meaningful? It's an abbreviation. Why would a longer name
> make it harder to find the group? Wouldn't it also make it easier for
> people to avoid the group? If you had looked for such a group a month
> ago, and next month it pops up among the new groups in your newsreader,
> isn't common-language-infra more likely to attract your attention than
> cli.
So, do you think that comp.lang.common-business-oriented-language is
clear? Do you know what's discussed in that group? Would you be able to
find it if you wished to discuss that topic? Would you locate it with a
keyword search if you had no idea to look in comp.lang.* for such things?
Kai Henningsen
> group purpose, because almost all are for discussion. The "std"
> is frequently missinterpreted as standing for "students", therefore
It is? That's news to me, and I've read comp.std groups for a while now.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
Kai Henningsen
> People looking for ECMA CLI will find this group. People looking for a
So why not call it comp.std.ecma-cli?
Wayne Brown
My answers would be: Yes, yes, probably, maybe. Of course, COBOL is a
well-known acronym that means exactly what your example says. CLI is
a well-known acronym that usually means something entirely different
from the subject of the proposed group, so the two cases aren't strictly
analogous...
--
Wayne Brown | "When your tail's in a crack, you improvise
fwb...@bellsouth.net | if you're good enough. Otherwise you give
| your pelt to the trapper."
"e^(i*pi) = -1" -- Euler | -- John Myers Myers, "Silverlock"
Brian Edmonds
> CLI is a well-known acronym that usually means something entirely
> different from the subject of the proposed group, so the two cases
> aren't strictly analogous...
Amen. Within the context of comp.*, CLI is clearly not what the
proponents want to talk about. Even within the context of comp.std.* or
comp.lang.* I'm very skeptical about using the TLA as the name. There
is a Posix standard for the unix shell, if I recall correctly, and I
could certainly see a group where people would discuss CLI languages
(eg. Bourne shell, C shell, etc).
Unfortunately I can't think of a better name, but comp.std.cli is, IMO,
not a good one.
Brian.
Russ Allbery
> ni...@cosc.canterbury.ac.nz (Nigel Perry) wrote:
>> People looking for ECMA CLI will find this group. People looking for a
> So why not call it comp.std.ecma-cli?
That's a very interesting suggestion.
The only drawback that comes to mind for me is that things occasionally
change standards bodies (so what was ANSI C is now ISO C and what is now
ECMA CLI might become IEEE CLI or ISO CLI or something down the road).
But even if that happens, it would still be pretty clear.
That should take care of the confusion with command-line interfaces pretty
well.
Jim Riley
wrote:
>Jim Riley <jim...@pipeline.com> writes:
>
>> How is "CLI" meaningful? It's an abbreviation. Why would a longer name
>> make it harder to find the group? Wouldn't it also make it easier for
>> people to avoid the group? If you had looked for such a group a month
>> ago, and next month it pops up among the new groups in your newsreader,
>> isn't common-language-infra more likely to attract your attention than
>> cli.
>
>So, do you think that comp.lang.common-business-oriented-language is
>clear?
Is that name even used? Looking at the standards definition pages
they refer to a "Programming Language COBOL". A web search on "cobol"
doesn't find anything not related to the computer language.
>Do you know what's discussed in that group? Would you be able to
>find it if you wished to discuss that topic? Would you locate it with a
>keyword search if you had no idea to look in comp.lang.* for such things?
A web search on cli found:
CLI library (Apache Software Foundation)
CLI Caller Line Identity
Both of which could be subject to standards discussion in the comp.*
hierarchy, and the following unrelated topics.
CCLI SongSelect and Lyric Service interfaces
ComputerLab International
Computational Logic, INC
Clì - Na Gaidheil Ùra (charity representing new Scots Gaelic speakers)
Cyberspace Law Institute
CLI Group (an engineering group)
CLI Magazine: The product magazine for clinical biologists
A search of ISO's site (www.iso.org) on "CLI" returns SQL/CLI
(Call-Level Interface), ISO/IEC 9075-3:1999.
A search on "Common Language" finds ISO/IEC 23271:2003.
--
Jim Riley
ba...@dmcom.net
>
> n03W28...@cl.cam.ac.uk (Markus Kuhn) wrote on 08.07.03 in <beeie1$ohe$2...@pegasus.csx.cam.ac.uk>:
>
> > group purpose, because almost all are for discussion. The "std"
> > is frequently missinterpreted as standing for "students", therefore
>
> It is? That's news to me, and I've read comp.std groups for a while now.
>
When I first saw std what occured to me was (sexual transmitted diease)
and could only relate it to comp as to discussion of viruses of
computers (based on name space alone). The convention of TLA that
generally did not include vowels can have resulted in std neaning
STuDents to some and STaDards to others. In general the common advice
is to avoid abverations because of posible confusion as to what is being
refered to by other users. I get a feel that few (if any) would look to
comp.std.* for viruses, there though remains how much cross over of
users of the two different quickly inferred word intended. In this case
I do not believe that there would be much of a misunderstanding. The
ones that tend to read comp.* are interested in and hopefully learn some
of the older TLA. Prehaps some computer students might be confused for
a short period of time when subscribing to a group, however they should
be in the process of lreaning standards and such a group could aid thier
learning.
The same argument might apply to cli, this "geek talk" ;-) so while it
might look strange to some less involved with computer programing and
standards the problems might not be that great as a rec.std.* proposal
or a soc.std.* proposal, etc.
--
news:alt.pagan FAQ at http://www.dmcom.net/bard/altpag.txt
news:alt.religion.wicca FAQ at http://www.dmcom.net/bard/arwfaq2.txt
news:news.groups FAQ at http://www.dmcom.net/bard/ngfaq.txt
Want a new group FAQs http://web.presby.edu/~nnqadmin/nnq/ncreate.html
Nigel Perry
> Kai Henningsen <kaih=8pfDi...@khms.westfalen.de> writes:
> > ni...@cosc.canterbury.ac.nz (Nigel Perry) wrote:
>
> >> People looking for ECMA CLI will find this group. People looking for a
>
> > So why not call it comp.std.ecma-cli?
The CLI Standard is already both ECMA and ISO. It seems easier to
simply say "comp.std.cli" than "comp.std.ecma-iso-cli". I can't see
there being competing Standards, so naming the Standards
organisation(s) seems redundant.
>
> That's a very interesting suggestion.
>
> The only drawback that comes to mind for me is that things occasionally
> change standards bodies (so what was ANSI C is now ISO C and what is now
> ECMA CLI might become IEEE CLI or ISO CLI or something down the road).
> But even if that happens, it would still be pretty clear.
>
> That should take care of the confusion with command-line interfaces pretty
> well.
Why? If calling it iso-cli or ecma-cli removes the confusion then
there surely isn't one with "std.cli" - unless we assume that if
someone does standardize command line interfaces then it won't be ECMA
or ISO...
Russ Allbery
> Why? If calling it iso-cli or ecma-cli removes the confusion then there
> surely isn't one with "std.cli" - unless we assume that if someone does
> standardize command line interfaces then it won't be ECMA or ISO...
The existing standard for a command-line interface is POSIX, which is
IEEE, not ECMA or ISO. Although I think the latest round was actually
getting ISO approval, so that may not help that much.
Arthur L. Rubin
> A web search on cli found:
>
> CLI library (Apache Software Foundation)
> CLI Caller Line Identity
>
> Both of which could be subject to standards discussion in the comp.*
> hierarchy, and the following unrelated topics.
Thanks for the research, (some of which I <snipped>). If the
group is just called comp.std.cli, I'll vote NO.
Kai Henningsen
> comp.lang.* I'm very skeptical about using the TLA as the name. There
> is a Posix standard for the unix shell, if I recall correctly, and I
... and actually that *was* my first idea when I saw that name.
Of course, the group that standard currently is discussed in (not much) is
... comp.std.unix.
Kai Henningsen
> Why? If calling it iso-cli or ecma-cli removes the confusion then
> there surely isn't one with "std.cli" - unless we assume that if
That argument is false.
I myself confused it with POSIX.2 (the IEEE/ISO/OpenGroup standard for the
(Unix-style) portable shell environment, see comp.std.unix) when I first
saw the name.
> someone does standardize command line interfaces then it won't be ECMA
> or ISO...
Well, not ECMA anyway. Thus, iso-cli would *not* disambiguate.
Markus Kuhn
>
>> A web search on cli found:
>>
>> CLI library (Apache Software Foundation)
>> CLI Caller Line Identity
>>
>> Both of which could be subject to standards discussion in the comp.*
>> hierarchy, and the following unrelated topics.
None of the above are acronyms related to standards, therefore these
clashes aren't a problem under comp.std.*.
Far more significantly perhaps: Entering CLI into the International
Standards Organization catalogue search engine on
http://www.iso.org/iso/en/CatalogueListPage.CatalogueList
retrieves only one completely unrelated document
ISO/IEC 9075-3:1999 Information technology -- Database languages --
SQL -- Part 3: Call-Level Interface (SQL/CLI)
whereas the title of the standard
ISO/IEC 23271:2003 Information technology -- Common Language Infrastructure
does not even include the acronym CLI (even though the ECMA catalogue on
http://www.ecma-international.org/publications/standards/standard.htm
does).
The ECMA/ISO Common Language Infrastructure is at present colloquially far
more widely known under the corresponding Microsoft brand name, namely
".NET Platform". Just like the ISO 10646 Universal Character Set (UCS)
is far more commonly known under the "Unicode" brandname of the Unicode
Consortium.
If we called the thing comp.std.dotnet, on one hand, everyone whould
instantly know what is meant, one the other hand, we are also replacing
the politically and technically correct name of the international standard
with the Microsoft brand name for their implementation of the CLI
(and lots of other things).
In that respect, I don't know, what better name than comp.std.cli
could be proposed. It remains to be seen, whether CLI will
become common parlance besides ".NET Platform", or whether it will
remain as obscure as for example UCS is today in comparison with
Unicode.
In any case, it is rather promising technology and I certainly see
a compelling need for a group to discuss the evolution of its
standardization. I'd like to see lots of widely used reimplementations
of the standard that are independent of the Microsoft .NET product
family. Therefore, better let's stick with comp.std.cli.
Markus
--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Kai Henningsen
> If we called the thing comp.std.dotnet, on one hand, everyone whould
> instantly know what is meant, one the other hand, we are also replacing
> the politically and technically correct name of the international standard
> with the Microsoft brand name for their implementation of the CLI
> (and lots of other things).
On the other hand, there's precedent. The POSIX group is called
comp.std.unix.
Kai Henningsen
> Kai Henningsen wrote:
> >
> > n03W28...@cl.cam.ac.uk (Markus Kuhn) wrote on 08.07.03 in
> > <beeie1$ohe$2...@pegasus.csx.cam.ac.uk>:
> >
> > > group purpose, because almost all are for discussion. The "std"
> > > is frequently missinterpreted as standing for "students", therefore
> >
> > It is? That's news to me, and I've read comp.std groups for a while now.
> >
>
> When I first saw std what occured to me was (sexual transmitted diease)
Well, the claim was that it is 'frequently misinterpreted as standing for
"students"'.
Can *anyone* support that specific claim (specifically including the
"frequently" part), or was it specious?
I certainly don't remember "do my homework for me" posts being any more
frequent than in other groups.
Nigel Perry
> On Tue, 08 Jul 2003 00:25:53 +0000, Nigel Perry
> <ni...@cosc.canterbury.ac.nz> wrote:
>
> > REQUEST FOR DISCUSSION (RFD)
> > unmoderated group comp.std.cli
>
> >Newsgroup line:
> >comp.std.cli Discussions on the ECMA/ISO Common Language.
>
> I recognize CLI as standing for Command Line Interface
>
> Why not?
>
Considering the concerns expressed by some over the use of "cli" we
proposed a 2nd RFD changing the name to
"common-language-infrastructure". However we have been told that this
is not possible due to a 20 character limit and the 2nd RFD has thus
not gone out.
We have failed to come up with a meaningful abbreviation (just random
trunction would make the group harder to find/be meaningless). Also
some posters are happy with just "cli". Therefore, having made efforts
to address the concerns, we will leave the name is. Well will request
the CFV on the original RFD at the appropriate time.
Cheers,
Nigel for ECMA WG-3
Arthur L. Rubin
>
> Jim Riley <jim...@pipeline.com> wrote in message news:<behvju$hi8$1...@slb4.atl.mindspring.net>...
> > On Tue, 08 Jul 2003 00:25:53 +0000, Nigel Perry
> > <ni...@cosc.canterbury.ac.nz> wrote:
> >
> > > REQUEST FOR DISCUSSION (RFD)
> > > unmoderated group comp.std.cli
> >
> > >Newsgroup line:
> > >comp.std.cli Discussions on the ECMA/ISO Common Language.
> >
> > I recognize CLI as standing for Command Line Interface
> >
> > Why not?
> >
> > |comp.std.common-lang-infra Common Language Infrastructure standardization.
>
> Considering the concerns expressed by some over the use of "cli" we
> proposed a 2nd RFD changing the name to
> "common-language-infrastructure". However we have been told that this
> is not possible due to a 20 character limit and the 2nd RFD has thus
Unless someone can explain to me WHY cli would not be interpreted by
rational people as one of the other abbreviations of something with
a standard, I'll still vote no for comp.std.cli. I don't see what's
wrong with comp.std.common-lang-infra or comp.std.comm-lang-infra.