Holger Metzger wrote:
>
> On 6/9/01 2:55 PM, Chuck Simmons wrote:
>
> > I have thought about this and there is no perfect solution. Server
> > generated ID's are not guaranteed to be unique even for one day. It
> > depends on how the ID is generated and what sort of upheavals the server
> > goes through. The only guarantee you have is that a server will not
> > duplicate an ID that is currently unexpired on that server.Since many
> > clients generate ID's, uniqueness cannot be guaranteed anyway. I note
> > that you deleted the message ID before sending the above message to test
> > what I said. Your earlier message had the usual Netscape type of ID with
> > <time in hex>.<32 bit pseudo random number>@<domain>. This gives a high
> > probability of uniqueness.
>
> de.all.* usenet rules prohibit Netscape type message-ids. It either has
> to be a FQDN after the @ or a server generated id.
>
> It's interesting that http://bugzilla.mozilla.org/show_bug.cgi?id=80819
> has been reported by a de.all.* user :)
>
> IMHO message-id creation should be left to the news server to avoid
> dupes. Maybe best way would be if Mozilla would allow the user to
> specify a FQDN via the UI or a user_pref, something like:
>
> [] server-side m-id creation (recommended)
> [] Mozilla/4 behavior
> [] Use the the following FQDN for m-id:_________
> (for users with their own domains)
>
> Holger
RFC2111 indicates that mid (message-ID) and cid should be generated as a
pair forming a unique qualifier for content. Generating mid and cid as a
pair at the client makes known at the client what the mid/cid pair are
prior to sending. This has advantages in some circumstances. RFC2111
does not say whether the message-ID should be generated by the client or
the server but a consistent mid/cid pair make a case for the client. In
security considerations, RFC2111 indicates that steps may be taken in
generating message-ID's to avoid disclosing information that one may not
desire to be disclosed.
RFC1036 states that to conform to RFC822, a message-ID must contain the
host domain where the message entered the network. This does not suggest
server generation but rather client generation. RFC1036 otherwise does
not state whether message-ID's should be client or server generated.
RFC822 clearly makes message-ID an optional header for the client but
only states that the string following the "@" must be a domain. It does
not state what domain.
Server generated ID's may be ambiguous to the client user. For example,
many news servers providing leased access for customers of ISP's may
have many aliases. However, the alias is defined at the ISP's DNS and
not at the local DNS for the server. Thus the server will provide
message ID's having nothing to do with the domain or network of origin.
This is because the server simply does not know what alias was used to
contact it since it is likely unaware that the aliases exist. Remember,
the aliases are arbitrarily defined on the ISP's network. For example,
when I used futureone.com, news.futureone.com was aliased to one of many
*.supernews.com servers. The question here is whether messages I sent to
news.futureone.com should have had <unique>@futureone.com for ID's (as
indicated by RFC1036 or <unique>@supernews.com message-ID's?
Take your pick on that one.
Chuck
--
... The times have been,
That, when the brains were out,
the man would die. ... Macbeth
Chuck Simmons [EMAIL PROTECTED]
