Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Distribution lists

0 views
Skip to first unread message

Steve Kille

unread,
Jul 29, 1986, 4:37:41 AM7/29/86
to

From: Jacob_Palme_QZ@qzcom
Subject: Distribution lists
Date: 26 Jul 86 13:30 +0200


HIER is the method commonly used in INTERNET. The restriction
requiring a hierarchical structure will make message transmission
slower and less efficient in some cases.

In some cases it is
natural to allow every list to be a member of every other list
in a set of linked lists.

I dispute this last sentence. I agree that there is a loss of
generality. However, I would suggest that the convoluted
structures prohibited are undesirable, and that prohibiting them
is an advantage. I can see a few cases where there would be a
need to create an 'invisible' list purely for the purposes of
structuring, but not where this would get out of hand.

I suggest a lemma (I don't have time to figure out a proof),
that ANY list structure can be represented by HIER.

As a challenge, I request REAL examples of list structures for
which HIER is inappropriate. I suggest is is EXACTLY what is
wanted in the majority of cases, and is quite reasonable in
all others. If this suggestion is correct, it makes HIER an
interesting choice of loop control.

Steve

Jacob_Palme_QZ...@mit-multics.arpa

unread,
Aug 4, 1986, 5:13:42 PM8/4/86
to
(a) We wanted something which (i) would work both under RFC822/821
and under X.400, including gateways betwen these protocols (ii)
not requring any change in X.400, so that it could be implemented
and used before changes in X.400 have been adopted and implemented
everywhere. That is why we chose to encode things in the text
bodies.

(b) Loop control:

There are five major methods of loop control:

(HIN) HISTORY-TRACE, CHECK ON RECIEPT: Include with a message a
history trace of lists which the message has passed, do not accept
into a list a message which has already passed that list.

(HOUT) HISTORY-TRACE, CHECK ON SENDING: Include with a message a
history trace of lists which the message has passed, do not send
it out again via list expansion to a list in the history trace.

(ID) MESSAGE-ID CHECK: Include with a message some kind of
message-ID, do not accept into a list a message with an ID which
already has passed the list.

(HIER) HIERARCHICAL ORDER: Enforce an hierarchical order on the
sublists.

(SPOINT) SINGLE EXPANSION POINT: Do all list expansion at a
single point.

Comments on these five methods:

HOUT is more efficient than HIN in network load, and also less
susceptible to problems when mapped onto RFC822.

ID is the method commonly used in USENET. This is the only method
which stops a person from receiving the same message twice, but
it cannot be used as the only loop control mechanisms because
of unreliability of Message-ID-s in certain cases.

HIER is the method commonly used in INTERNET. The restriction
requiring a hierarchical structure will make message transmission
slower and less efficient in some cases. In some cases it is
natural to allow every list to be a member of every other list
in a set of linked lists.

SPOINT is inefficient for large lists, and requires access to
a global directory system, which we do not have today.

We have chosen to suggest the use of HOUT in combination with
ID.

One can note that CCITT is presently considering SPOINT, but
they may change their mind before their new recommendation is
ready.

0 new messages