List-Header Digest Archive: February 1997 http://www.nisto.com/list-spec/mail/ X-List-Help: , X-List-Unsubscribe: X-List-Subscribe: X-List-Archive: X-List-Post: X-List-Owner: Contents: -> New list-header draft needs review before submission by Grant Neufeld <(suppressed)@nisto.com> -> List-ID review by Grant Neufeld <(suppressed)@nisto.com> -> Fwd: I-D ACTION:draft-leach-uuids-guids-01.txt by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID review by Rob Chandhok <(suppressed)@within.com> -> draft-hoffman-mailto-url status by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID review by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: New list-header draft needs review before submission by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID review by Grant Neufeld <(suppressed)@nisto.com> -> Re: List-ID review by "D. J. Bernstein" <(suppressed)@cr.yp.to> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID review by "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de> -> Re: List-ID review by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> -> Duplicate supression and List-headers by Jacob Palme <(suppressed)@dsv.su.se> -> Re: Duplicate supression and List-headers by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID review by "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de> -> Re: List-ID review by "Kent S. Larsen II" <(suppressed)@panix.com> -> Re: List-ID review by "Kent S. Larsen II" <(suppressed)@panix.com> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> -> Re: Duplicate supression and List-headers by Jacob Palme <(suppressed)@dsv.su.se> -> Re: List-ID review by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID review by Stan Ryckman <(suppressed)@sunspot.tiac.net> -> Re: List-ID review by Rob Chandhok <(suppressed)@within.com> -> Re: List-ID review by Jacob Palme <(suppressed)@dsv.su.se> ---------------------------------------------------------------------- Date: 6 Feb 1998 14:22:56 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: New list-header draft needs review before submission I've finally completed all the suggested changes to the list-header draft. http://www.nisto.com/listspec/ietf/draft-baer-listspec-02.txt I've put change bars ("|") in for most sections that are new or changed since the last draft. Please review it and let me know if you see any problems with it. Thanks. - -- The quickest path to enlightenment: Spend your whole life asking questions and listening to the answers http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 6 Feb 1998 15:08:17 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: List-ID review A new message header field to be included in messages originating from mailing lists is being discussed. There has been no opposition, and no alternatives suggested (that I can recall - please correct me if wrong), to the proposed label "List-ID" for the field. Possible elements that have been suggested for the List-ID field (in no particular order): 1) an angle-bracket enclosed URN: List-ID: 2) a quote enclosed non-unique name: List-ID: "List Specification Working Group" 3) a unique ID string consisting of one or more elements from: A) a unique ID string derived in part from a domain name: List-ID: list-header#nisto.com (I use the # as separator instead of '.' to avoid confusing the id with an actual domain name) B) an "experimental" domain root (x.listid) for non-domain name based IDs: List-ID: list-header#grant.x.listid C) a random number: List-ID: 123456 D) the year (or similar temporal identifier) (only as an element, not the entire string) List-ID: list-header#1998#grant.x.listid 4) RFC822 comments - bracket enclosed: List-ID: (the unique ID for the List-Header list) Elements 1 and 3 would be mutually exclusive, but 2 and 4 could be present in the same field as either 1 or 3 (but do not provide sufficient information to stand on their own). My Comments: If we are going to use the non-URN string [3], then I suggest we provide some way of marking it as such (like the angle-brackets for URNs, quotes for names, etc.). Perhaps square brackets? I entirely oppose the use of random numbers [3:C] on their own, and also oppose the use of random numbers even if in conjunction with another element such as a domain name. I also oppose the use of numbers as identifiers in general. Regardless of what we do, humans will be entering or modifying their list IDs. Numbers have virtually no meaning to humans in this context, where a textual identifier can hold meaning. My reluctance to use domain names [3:A] stems from the idea that lists should stand as entities/objects on their own - apart from where they may happen to reside. Which domain would you use for a list that is distributed across hosts? What of a list that originates as a newsgroup? What about my case where I finally got my own domain (nisto.com) and transferred all my hosting from my old domain (arpp.carleton.ca) to the new (it's all still on the same machine, just a different name). What if a company changes its name, or is bought by a larger company? And so on... And then there's the whole issue of linking with networks outside the internet's domain naming scheme. I accept that we'll probably have to allow domain name based IDs, but I think we really need to focus on methods that are not in any way tied to the location of a resource (list). - -- http://www.nisto.com/ O- <*> It is precisely now, when we have discovered that there is no future for the human race, that we must create a future. ---------------------------------------------------------------------- Date: 6 Feb 1998 20:09:14 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Fwd: I-D ACTION:draft-leach-uuids-guids-01.txt This may be of interest for the List-ID discussion. I haven't read it yet myself, though. - --- begin forwarded text A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : UUIDs and GUIDs Author(s) : P. Leach, R. Salz Filename : draft-leach-uuids-guids-01.txt Pages : 26 Date : 05-Feb-98 This specification defines the format of UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and if generated according to the one of the mechanisms in this document, is either guaranteed to be different from all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to be different (depending on the mechanism chosen). UUIDs were originally used in the Network Computing System (NCS) [1] and later in the Open Software Foundation's (OSF) Distributed Computing Environment [2]. This specification is derived from the latter specification with the kind permission of the OSF. 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-leach-uuids-guids-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-leach-uuids-guids-01.txt - --- end forwarded text ---------------------------------------------------------------------- Date: 6 Feb 1998 20:42:46 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID review Grant, Thanks for the summary. you wrote: >I accept that we'll probably have to allow domain name based IDs, but I >think we really need to focus on methods that are not in any way tied to >the location of a resource (list). Please, I never implied any relationship between the LOCATION of the list server and the use of a domain name as part of the list-id. My point was (and is) that the DNS is an existing method for obtaining globally unique NAME SPACES for a relatively small (or free) cost. So even though you were serving your lists from , you could have been using as your name space for all I care. You are right that companies are bought and sold. People move and shift their loyalties. But this is a bit too philosophical for the List-ID standard to deal with. I just want to use a namespace where: a) the rules are already defined b) once you get a part of the namespace (a domain or zone), you can ADMINISTER IT YOURSELF. My current preference? Something like: List-ID: "Within's Internal List" List-ID: "Rob's Joke List" Quoted string for humans. Everything in the <> for string comparison, no interpretation. The "x.list" domain is a free for all namespace. Why prefix with "listid:"? Future flexibility, plus a listid: URL might be handled intelligently at some point. Rob ---------------------------------------------------------------------- Date: 7 Feb 1998 11:48:27 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: draft-hoffman-mailto-url status Just an update on the mailto draft (which the list- header draft is dependant upon). According to Paul Hoffman, the draft is with the IESG and is waiting for them to do something with it. Keith: any idea when this will go through? (I expect to submit the list- header draft, version 02, early next week unless someone raises a problem about it) - -- http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 7 Feb 1998 15:35:06 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-ID review Grant Neufeld writes: > List-ID: 123456 [ ... ] > I entirely oppose the use of random numbers [3:C] on their own, Perhaps it would help if you understood the difference between a 6-digit random number and a 50-digit random number. > humans will be entering or modifying their list IDs. When's the last time you made up your own Message-ID? Anyway, the MUA really doesn't care how you obtain a unique ID. > Numbers have virtually no meaning to humans in this context, So what? Why should the List-ID be human-comprehensible? Do you also insist that cryptographic signatures be human-comprehensible? - ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html ---------------------------------------------------------------------- Date: 7 Feb 1998 16:24:02 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: New list-header draft needs review before submission [I sent this message earlier. The idiotic list manager threw away the message and sent out a subscription confirmation, presumably because it saw the word ``subscribe'' at the beginning of a line.] Grant Neufeld writes: > Please review it and let me know if you see any problems with it. It doesn't provide enough information. The MUA should be able to automatically manage the user's subscriptions. It should (1) keep track of which mailing lists the user is subscribed to, (2) figure out which list each message belongs to, and (3) keep track of the latest instructions for each list. Then it can handle ``unsubscribe'' or ``change my address'' properly. The implementation suggested in the list-header draft is _not_ what an MUA should do. It is missing a level of indirection. This matters when the user is looking at a message with obsolete or missing instructions. - ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html ---------------------------------------------------------------------- Date: 7 Feb 1998 18:17:42 -0700 From: Grant Neufeld <(suppressed)@nisto.com> Subject: Re: List-ID review At 3:33 PM -0700 1998/2/7, D. J. Bernstein wrote: >Grant Neufeld writes: >> I entirely oppose the use of random numbers [3:C] on their own, > >Perhaps it would help if you understood the difference between a 6-digit >random number and a 50-digit random number. Whether it is anywhere from one digit to 50000, I still see no benefit in using numbers as opposed to using textual IDs with some meaning to them. What do numbers offer for IDs that meaningful text doesn't? >> humans will be entering or modifying their list IDs. > >When's the last time you made up your own Message-ID? Irrelevant. List-IDs apply accross a wide set of objects, and will be used in many instances. Message-IDs apply only to a single object. How often do you refer to a Message-ID? For me the answer is never. How often will people rely on List-IDs? They will likely be widely used for filtering and grouping of data. >Anyway, the MUA >really doesn't care how you obtain a unique ID. Which is why it will be equally (if not more, in the case of URNs) happy with a textual ID. >> Numbers have virtually no meaning to humans in this context, > >So what? Why should the List-ID be human-comprehensible? Let me turn that question around on you: Why should the List-ID be incomprehensible to humans when it can just as easily be made at least partially human-comprehensible? >Do you also >insist that cryptographic signatures be human-comprehensible? The analogy you suggest here does not apply. Making cryptographic signatures human-comprehensible would hinder the effectiveness of the cryptographic systems, creating an undue burden. Using text, as opposed to numbers, for List IDs places no additional burden on the humans and software involved. - -- "Driving Drunk? Don't wear a seat-belt!" http://www.nisto.com/ O- <*> ---------------------------------------------------------------------- Date: 7 Feb 1998 20:06:09 -0700 From: "D. J. Bernstein" <(suppressed)@cr.yp.to> Subject: Re: List-ID review Grant Neufeld writes: > What do numbers offer for IDs that meaningful text doesn't? No need to waste the time for preapproval from a global registry. No risk of lawsuits if the list moves and keeps its ID. > > Do you also > > insist that cryptographic signatures be human-comprehensible? > The analogy you suggest here does not apply. Wrong. The most obvious way to generate a _secure_ List-ID, not usable by forgers, is to make it a hash of the mailing list's public key, and sign all messages under that public key. > How often do you refer to a Message-ID? For me the answer is never. > How often will people rely on List-IDs? They will likely be widely used > for filtering and grouping of data. This is your dumbest argument yet. _MUAs_ use Message-ID all the time to group messages into threads, just as they'll use List-ID to sort messages into lists. _People_ rarely look at Message-ID, and will rarely look at List-ID if it's competently engineered. - ---Dan Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html ---------------------------------------------------------------------- Date: 8 Feb 1998 03:11:00 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 18.20 -0700 98-02-07, Grant Neufeld wrote: >Whether it is anywhere from one digit to 50000, I still see no benefit in >using numbers as opposed to using textual IDs with some meaning to them. > >What do numbers offer for IDs that meaningful text doesn't? The disadvantage with meaningful text is that if a list changes its goals, topics or owners, the text will not any more apply. There will then be a wish to change the ID, but the idea of an ID is that it should not change even if circumstances around a list changes. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 8 Feb 1998 03:11:10 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 18.20 -0700 98-02-07, Grant Neufeld wrote: >How often do you refer to a Message-ID? For me the answer is never. That is because e-mail software hides the Message-ID from the user. They provide commands like "find the message which this message is a reply to" or "find all replies to this message", and a good piece of e-mail software will be able to perform these commands without the user having to be aware that there even is a Message-ID. The same might apply to well-designed software using List-ID-s. However, when URLs were invented, the idea was that people need never see them. You click on a hyperlink, need not know what is behind it. And experience shows that this was not true. People are forced to handle URLs, even to copy them character-by-character from printed text in newspapers and magazines. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 9 Feb 1998 09:10:32 -0700 From: "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de> Subject: Re: List-ID review Grant Neufeld <(suppressed)@nisto.com> schrieb: > A new message header field to be included in messages originating from > mailing lists is being discussed. > > There has been no opposition, and no alternatives suggested (that I can > recall - please correct me if wrong), to the proposed label "List-ID" for > the field. > > Possible elements that have been suggested for the List-ID field (in no > particular order): > > 1) an angle-bracket enclosed URN: > List-ID: This has another advantage: With mailing lists that come from gates, we could allow other namespaces, such as . > 2) a quote enclosed non-unique name: > List-ID: "List Specification Working Group" > > 3) a unique ID string consisting of one or more elements from: Why not (1)+(2) List-ID: "Foo List" (The "URN:" string is not necessary; the header would be defined in a way that interpretation as a URN/URL/URI would be implied.) > Elements 1 and 3 would be mutually exclusive, but 2 and 4 could be present > in the same field as either 1 or 3 (but do not provide sufficient > information to stand on their own). [copied from below - cf] No, (1) and (3) are not mutally exclusive, but (3) is a way how to determine the listid for (1). URNs do not require that there be a special registry. > A) a unique ID string derived in part from a domain name: Fine. > List-ID: list-header#nisto.com > (I use the # as separator instead of '.' to avoid confusing the id with > an actual domain name) s/domain name/submission address/ However, I do not think that's necessary, List-IDs shall be always written with the listid namespace identifier. > B) an "experimental" domain root (x.listid) for non-domain name based IDs: > List-ID: list-header#grant.x.listid No "@". E.g. (domain-based) (not d.-based) > C) a random number: > List-ID: 123456 C2) a GUID / UUID, maybe encoded. > D) the year (or similar temporal identifier) (only as an element, not the > entire string) > List-ID: list-header#1998#grant.x.listid OK. > 4) RFC822 comments - bracket enclosed: > List-ID: (the unique ID for the List-Header list) Should be allowed as a comment and nothing more. > My Comments: > > If we are going to use the non-URN string [3], then I suggest we provide > some way of marking it as such (like the angle-brackets for URNs, quotes > for names, etc.). Perhaps square brackets? As I said above, (3) is the way to build the URN. The marking would be the same as for any URN/URL/URI: angle brackets, with the "listid" namespace identifier, e.g. . > My reluctance to use domain names [3:A] stems from the idea that lists > should stand as entities/objects on their own - apart from where they may > happen to reside. The domains can be used as a source of unique identifiers. Together with a date specifier (s.below), listids can be completly independent from the domain after they have been created. > Which domain would you use for a list that is distributed > across hosts? Choose an arbitrary domain of one of the hosts. > What of a list that originates as a newsgroup? Then we can use the URN of the newsgroup instead of a listid URN, e.g. . > What about my > case where I finally got my own domain (nisto.com) and transferred all my > hosting from my old domain (arpp.carleton.ca) to the new (it's all still on > the same machine, just a different name). Continue using the old listid; this is one of the cases where the listid has no relation to the submission address (such a relation SHOULD never be assumed). > What if a company changes its > name, or is bought by a larger company? Continue using the old name. There will be no name clashes unless the new owner of the domain wants to set up a list with the same name, and none at all if one owner followed the RECOMMENDATION to append a date- based string. We could allow not only the year but a full time specification as defined by ISO 8601, with reduced precision explicitly allowed. Examples: 1998-02-08T17:18:19 (full time) 1998-02-08T17:18 (reduced: no seconds) ... 1998-02-08 (reduced: no time) ... 1998-W12 (reduced/alternate: week 12 instead of month-date) 1998-02 (reduced: month only) 1998 (reduced: year only) --02-08 (not allowed for listid: no year specified) This would allow specifying the time based on the expectation of how long the domain remains owned by the mailing list manager. My suggestion: (a) List-ID header list-id-header := "List-ID:" CFWS list-id-name CFWS list-id-name := [ phrase CFWS ] "<" list-id / other-urn ">" Examples: List-ID: (This is not a submission address!) List-ID: The IETF Lists Header Discussion List List-ID: "The comp.foo.bar newsgroup" (b) listid URN namespace list-id := "listid:" list-id-domain / list-id-unique [ "#" date-time ] list-id-domain := local-part "@" domain local-part domain list-id-unique := atom [ "-" list-id-random ] list-id-random := guid / ... (other random number algorithms) date-time Examples

(better ) > And then there's the whole issue of linking with networks outside the > internet's domain naming scheme. Such networks usually have a domain. We could mandate it to the writers of gating standards to use that domain and an appropriate mapping for ids. Further, if this "other network" already assigns UR?s to its discussion forums, we could just use that UR?s. > I accept that we'll probably have to allow domain name based IDs, but I > think we really need to focus on methods that are not in any way tied to > the location of a resource (list). [BTW: The processor of this list has a bug, it rejected my message although the Sender line as well as the envelope sender was set to the address I subscribed with (but not the From line, which I set to my primary address).] - -- Claus "3247" Andre Faerber fax: +49-8061-3361 PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC ---------------------------------------------------------------------- Date: 9 Feb 1998 10:43:35 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID review I like Claus's proposal (excerpted below) - it pulls together the various options in a better form than my earlier post. I especially think using news:xxx as a listid for gateway'd newsgroups is an elegant solution. Thanks Claus! BTW, I suspect GUIDs based on will never be used. The people who might actually implement the process described in the protocol will proably use a domain name based ID instead. The GUIDs in that document are meant for objects that are created/destroyed in mass quantities over (sometimes) very short periods of time. ListIDs are almost constant as compared to those identifiers. So, you may not want to reference that document or GUIDs in any draft RFC. Rob - ------------ At 11:58 AM +0100 2/9/98, Claus AndrŽ FŠrber wrote: >My suggestion: > >(a) List-ID header > >list-id-header := "List-ID:" CFWS list-id-name CFWS >list-id-name := [ phrase CFWS ] "<" list-id / other-urn ">" > >Examples: > > List-ID: (This is not a submission address!) > List-ID: The IETF Lists Header Discussion List > > List-ID: "The comp.foo.bar newsgroup" > >(b) listid URN namespace > >list-id := "listid:" list-id-domain / list-id-unique [ "#" date-time ] > >list-id-domain := local-part "@" domain > >local-part identical to the local part of mailing addresses > or message ids> >domain

authorized to use at the time of set-up> > >list-id-unique := atom [ "-" list-id-random ] >list-id-random := guid > / ... (other random number algorithms) > >date-time reasonable with respect to the expectaion of how long > the domain used for the listid remains under the > authorization of the person who set up the list> > >Examples > > > > > > (better ) > ---------------------------------------------------------------------- Date: 9 Feb 1998 17:17:39 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 12.38 -0500 98-02-09, Rob Chandhok wrote: >I especially think using news:xxx as a listid for gateway'd newsgroups is >an elegant solution. Well, that depends on your definition of a list. There may be several different lists which gateways to the same newsgroup. They all have the same message content, but they have different members. Some of them may only accept subscriptions from people in a certain local environment. If by "list" you mean both a set of messages and a set of members and a certain facility for adding and removing members, then it might be problematic having the samme List-ID for all lists which gateway to the same newsgroup. Am I wrong? Does there in practice not exist several lists gatewaying to the same newsgroup? I have no practical knowledge of this, what I wrote above is just an assumption of a potential problem. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 10 Feb 1998 03:28:57 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Duplicate supression and List-headers I know that this is not common, but I know that there exists mailing list software which works in the following way: If a user is subscribed to two lists, and a message is sent to both lists, the user will only get one copy of the message. The present list-header proposal will not work in this case, since only one of each list-header is allowed. I therefore suggest a change in the list-header standard, as follows: Chapter 3, text "There MUST be no more than one of each field present in any given message", change this to: There MUST be no more than one of each field present in any given message and for any given mailing list or its sublists. More than one of each field is permitted in only one particular case: If a message is sent by its originator to more than one mailing list, and if a recipient is a member of more than one of the lists, and if a recipient gets only one copy of the message as a member of several lists, then there may be one set of the list headers for each of these mailing lists. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 10 Feb 1998 07:47:57 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: Duplicate supression and List-headers At 10:45 AM +0100 2/10/98, Jacob Palme wrote: >I know that this is not common, but I know that there exists >mailing list software which works in the following way: > >If a user is subscribed to two lists, and a message is sent >to both lists, the user will only get one copy of the message. > >The present list-header proposal will not work in this case, >since only one of each list-header is allowed. Hmmm. I think I disagree that we should shove more than one list-header set in each message. How do you tell which goes with what? How do you enumerate them? Solutions to these problems would confuse the standard at a time where we need implementations, not complications. If you are going to have this kind of origination optimization, you might have to wait for a MIME part, since it would be fine to have more than one list-info mime part attached to a message. Rob ---------------------------------------------------------------------- Date: 10 Feb 1998 18:19:48 -0700 From: "Claus_AndrŽ_FŠrber" <(suppressed)@faerber.muc.de> Subject: Re: List-ID review Jacob Palme <(suppressed)@dsv.su.se> schrieb: > At 12.38 -0500 98-02-09, Rob Chandhok wrote: > >I especially think using news:xxx as a listid for gateway'd newsgroups is > >an elegant solution. > > Well, that depends on your definition of a list. There may be several > different lists which gateways to the same newsgroup. They all have the > same message content, but they have different members. Some of them may > only accept subscriptions from people in a certain local environment. > > If by "list" you mean both a set of messages and a set of members > and a certain facility for adding and removing members, then it > might be problematic having the same List-ID for all lists which > gateway to the same newsgroup. > > Am I wrong? Does there in practice not exist several lists gatewaying > to the same newsgroup? > I have no practical knowledge of this, what > I wrote above is just an assumption of a potential problem. You can see it as a problem, you can also see it as an advantage: It is possible to associate these lists with the original newsgroup, so if someone gets a 'crossposted' message to from another mailing list, s/he might be able to use the newsgroup directly or another mailing list tied to the same newsgroup for a followup. [The issue here is whether the sending UA should add the List-ID header with all groups where it is crossposted to or the list exploder should add itsself only (it does not know about the other lists). I suggest both with different headers.] The same problem arises with mailing lists that are hosted on multiple hosts: Is is ONE mailing lists because it has the same content or TWO (or more) because there are several hosts that handle subscripitons? The main reason for List-ID is that it allows to detach the list itsself from the host and subscription facility. So, yes, I'd say that different mailing lists gating from and to the same newsgroup are actually THE SAME list with different hosts offering subscriptions. - -- Claus "3247" Andre Faerber fax: +49-8061-3361 PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E 25 56 69 A5 C6 A0 C9 DC ---------------------------------------------------------------------- Date: 11 Feb 1998 16:49:14 -0700 From: "Kent S. Larsen II" <(suppressed)@panix.com> Subject: Re: List-ID review > >You can see it as a problem, you can also see it as an advantage: It is >possible to associate these lists with the original newsgroup, so if >someone gets a 'crossposted' message to from another >mailing list, s/he might be able to use the newsgroup directly or >another mailing list tied to the same newsgroup for a followup. > I agree that this is a fairly clean solution, but I think it needs to be expanded a little. I don't know the relevant rfcs, but don't you need a mechanism for specifying the newsgroup host? I know that there are many newsgroups that are not available beyond one server! Kent Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work). Pass the SPAM ban! Ask your Congressperson to support CAUCE http://www.cauce.org ---------------------------------------------------------------------- Date: 11 Feb 1998 16:49:31 -0700 From: "Kent S. Larsen II" <(suppressed)@panix.com> Subject: Re: List-ID review While I'm not that technically oriented, I tend to side with Jacob at this point. I think those that favor human-readable List-IDs need to adequately answer his objections. It is clear that using meaningful text may make it easier for the human user, if the field is acutally intended for the human to use. Is it? Why? And even if it is, there is still the potential confusion that can come from the List-ID for a list that has moved hosts, which will then imply a different host than is actually in use. We can't assume that the human reader will understand that the list has moved. Also, doesn't using meaningful text open that text up to forgery? Of course, even numbers can be forged, and without a central registry, there isn't any way to determine that the forgery has occurred, so maybe the point is moot . . . Kent At 10:40 AM +0100 2/8/98, Jacob Palme wrote: >At 18.20 -0700 98-02-07, Grant Neufeld wrote: >>Whether it is anywhere from one digit to 50000, I still see no benefit in >>using numbers as opposed to using textual IDs with some meaning to them. >> >>What do numbers offer for IDs that meaningful text doesn't? > >The disadvantage with meaningful text is that if a list changes its >goals, topics or owners, the text will not any more apply. There will >then be a wish to change the ID, but the idea of an ID is that it >should not change even if circumstances around a list changes. > >------------------------------------------------------------------------ >Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) >for more info see URL: http://www.dsv.su.se/~jpalme Kent S. "Kip" Larsen II; KLarsen@panix.com or KLarsen@NorthSouth.com (work). Pass the SPAM ban! Ask your Congressperson to support CAUCE http://www.cauce.org ---------------------------------------------------------------------- Date: 11 Feb 1998 17:20:53 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 22.50 +0100 98-02-10, Claus AndrŽ FŠrber wrote: >So, yes, I'd say that different mailing lists gating from and to the >same newsgroup are actually THE SAME list with different hosts offering >subscriptions. Your arguments are very reasonable. It all depends, of course, on how you intend to use the List-ID. If you want to find out "has this message already been sent to this list" then your arguments are right. If you want to find out information about subscriptions and distribution, your arguments is not right, but for that purpose you might want to use "List-Help" instead of "List-ID". - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 11 Feb 1998 17:21:14 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 18.07 -0500 98-02-11, Kent S. Larsen II wrote: >>You can see it as a problem, you can also see it as an advantage: It is >>possible to associate these lists with the original newsgroup, so if >>someone gets a 'crossposted' message to from another >>mailing list, s/he might be able to use the newsgroup directly or >>another mailing list tied to the same newsgroup for a followup. > >I agree that this is a fairly clean solution, but I think it needs to be >expanded a little. I don't know the relevant rfcs, but don't you need a > mechanism for specifying the newsgroup host? > >I know that there are many newsgroups that are not available beyond one >server! I do not think there is, yet, any standard for a URN space for Usenet News. When someone writes such a standard, then it seems very necessary that this standard handle the problem of local newsgroups. It is conceivable that two local newsgroups in two news hosts have the same name, although usually not, since local newsgroups are usually prefixed in a way which shows the region. For example, all the local Swedish newsgroups have names beginning with "swnet.". - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 11 Feb 1998 17:23:00 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: Duplicate supression and List-headers At 09.39 -0500 98-02-10, Rob Chandhok wrote: >Hmmm. I think I disagree that we should shove more than one list-header >set in each message. How do you tell which goes with what? How do you >enumerate them? Solutions to these problems would confuse the standard at a >time where we need implementations, not complications. It depends on how you intend to use them. If you intend to use them in order to decide: - - How did I get this message - - How can I unsubscribe from the list, through which I got this message then it is better to include all the list headers in the special case I mentioned, as I proposed. In that case you do not need to enumerate them. But allowing more than one list header will make implementation in the client more difficult, and probably many implementors will not handle this special case right, and that might be a valid reason for not allowing it, as you say. - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- Date: 11 Feb 1998 20:52:18 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID review At 6:07 PM -0500 2/11/98, Kent S. Larsen II wrote: >I agree that this is a fairly clean solution, but I think it needs to be >expanded a little. I don't know the relevant rfcs, but don't you need a >mechanism for specifying the newsgroup host? > >I know that there are many newsgroups that are not available beyond one >server! Hold it. These aren't necessarily valid URLs. However, they might be used to provide meaningful information. The *only* operation that is defined for List-ID is EQUALITY COMPARISON. The coincidence that a gateway'd newsgroup might have a list-id that matches it's name in the Usenet namespace is just fortuitous. NO IMPLIED SEMANTICS. If we are going to try and infer other operations based on the content of the List-ID, then I'm going to switch my vote to using random numbers (bleah). Gateway'd usenet groups are a pretty special case, BTW. I'd be fine with having no special support or mention of them in any standard. Rob ---------------------------------------------------------------------- Date: 26 Feb 1998 23:05:22 -0700 From: Stan Ryckman <(suppressed)@sunspot.tiac.net> Subject: Re: List-ID review At 06:14 PM 2/11/98 -0500, Kent S. Larsen II wrote: [re text vs. random numbers] >It is clear that using meaningful text may make it easier for the human >user, if the field is acutally intended for the human to use. Is it? Why? The *MAIN* use for it that I can see is for users to put it in their mail filters... e.g., a Eudora setting might read: "List-ID" IS "manually-typed-string-here" so that I can put them into the correct folder. It's hard to type a 50-digit random number correctly, or even verify it by inspection. (I'm against time strings consisting of more than just year, or maybe year and month, for similar reasons.) >And even if it is, there is still the potential confusion that can come >from the List-ID for a list that has moved hosts, which will then imply a >different host than is actually in use. We can't assume that the human >reader will understand that the list has moved. That's why not to use "@" in the List-ID. >Also, doesn't using meaningful text open that text up to forgery? Of >course, even numbers can be forged, and without a central registry, there >isn't any way to determine that the forgery has occurred, so maybe the >point is moot . . . Huh? A central registry doesn't stop domain name forgery. And no matter what the List-ID, since it is to never change, the forger only needs to get one copy of a list message, ever. Fortunately, the VALUE of forging this header seems negligible. Cheers, Stan ---------------------------------------------------------------------- Date: 27 Feb 1998 08:16:37 -0700 From: Rob Chandhok <(suppressed)@within.com> Subject: Re: List-ID review At 1:01 AM -0500 2/27/98, Stan Ryckman wrote: >The *MAIN* use for it that I can see is for users to put it in their >mail filters... e.g., a Eudora setting might read: > "List-ID" IS "manually-typed-string-here" And to make "agents" be able to build reliable filters also. But many many people will use this! What can we do to push List-ID forward? It's long overdue. I'd be happy to co-author the RFC. Rob ---------------------------------------------------------------------- Date: 27 Feb 1998 19:03:07 -0700 From: Jacob Palme <(suppressed)@dsv.su.se> Subject: Re: List-ID review At 16.10 +0100 98-02-27, Rob Chandhok wrote: > At 1:01 AM -0500 2/27/98, Stan Ryckman wrote: > >The *MAIN* use for it that I can see is for users to put it in their > >mail filters... e.g., a Eudora setting might read: > > "List-ID" IS "manually-typed-string-here" > > And to make "agents" be able to build reliable filters also. But many many > people will use this! > > What can we do to push List-ID forward? It's long overdue. I'd be happy to > co-author the RFC. So, for that usage, what you want is a unique ID for a *set of messages*, not fo a *subscription service*. One conclusion of this is that sublists in nested lists should normally not have any List-ID. What should a mailing list server do if it gets a message which already has a List-ID? Of the server handles a sublist, it should not change or add any List-ID, since the set of messages is defined by the top mailing list in the nested structure. If, however, a user gets a message from list A and manually resends it to list B, then in that case the handler of list B should perhaps replace the List-ID? - ------------------------------------------------------------------------ Jacob Palme <(suppressed)@dsv.su.se> (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme ---------------------------------------------------------------------- End of Digest