Text 678, 121 rader
Skriven 2012-07-16 12:20:16 av mark lewis (1:3634/12.0)
    Kommentar till text 657 av Nicholas Boel (10662.fidonews)
Ärende: .fidonet
================
 NB> Well, here's an update that I told you I would try to get:

 NB> <RSwindell> ..and Mark Lewis is wrong when he says he complained to
 NB> me and I did nothing about it. Years ago, I chnaged the MSG-ID
 NB> format to be more "conforming" because of his complaints.

"to be more conoforming"... not... sure, down to 2 fields instead of the *5*
fields it was...

 NB> http://cvs.synchro.net/cgi-bin/viewcvs.cgi/src/sbbs3/msg_id.c?view=
 NB> log 

have you looked at that link? my name is not mentioned in it... rev 1.2
indicates there were more than 2 fields being generated and that they changed
it to use only two but KEEP all the same data "to shut-up the idiots on
FidoNet"... but it is still not "more conforming" other than using two
fields... if they need that additional information in messages, they can easily
create a new control line... MSGID and REPLY not being used completely properly
anyway... witness any synchronet reply to one of your messages that has no
MSGID in it and you will see a bogus REPLY line...

 NB> So, the origaddr portion of the FTS-9 MSGID *used* to be just the
 NB> 4D address, but due to bitching, was changed. And it was bitching
 NB> for no good reason, just because it looked different. There was no
 NB> *actual* incompatibility with any software, just like now.

there were more than 2 fields being generated until maurice and paul said
something and yes, i'm pretty sure that i was in there with numerous other
voices too... but the fact is that they were incorrectly formatted, the details
were pointed out and the specification pointed to and the change still didn't
fix the problem...

 NB> They're expecting a MSGID that looks like "1:103/705 89348af" but
 NB> that is simply not enough unique information to create a
 NB> system-wide unique message ID, and it's a well known problem the
 NB> FTS-9 MSGID format, and different folks have worked around it in
 NB> different ways, some have just ignored the problem. 

bullshit... it is enough for a system wide unique format... one only really
needs a sequential serial number routine that starts at 00000000 and counts up
to ffffffff before starting over again and not repeating within three years...

otherwise you are trying to tell us that 4294967295 messages originating on one
system over three years is too small a number?? 4BILLION original messages from
one system in 3 years is not enough?!? only 1431655765 messages per year?
1.4BILLION messages PER YEAR is not enough of a serial number counter??? on the
one hand, i'd like some of that stuff you're smoking plus a few snorts of that
which you are drinking but on the other hand, maybe not... not if is screws up
the mental math like this...

 NB> Nothing in FTS-9 says that you MUST be able to send a netmail to
 NB> the value in the origaddr field. Typically, you see just the 4D FTN
 NB> address in that field, which would *NOT* be an acceptable
 NB> destination address for netmail. 

why is the FTN address not valid for FTN messages? the destination /name/ comes
from the FROM: field in the header... where's the problem??

 NB> What I saw when I analized MSGIDs on fido, was that many programs
 NB> (old long used programs) put user@addr in the origaddr field, even
 NB> though FTS-9 doesn't specifically allow or disallow that syntax. If

that is a normal form for internet style addressing and it is a valid return
address in the originating network... where's the problem??

 NB> any programs support that origaddr syntax (for whatever use they
 NB> might need to parse the MSGID, which I can think of none), then
 NB> they would *also* support the Synchronet format. 

there is no need to parse the MSGID and there should never be a need to do
so... there's no way to machine parse all of the different ways that someone
could come up with for embedding the return address in there... this is one
reason why Message-ID is not used for this on the internet but this isn't the
internet...

 NB> If anyone can cite a specific example of a specific program having
 NB> an issue with the Synchronet FTN MSGID format, I would look into
 NB> that issue, but so far, I have heard of none, and frankly, I think
 NB> having unique MSGIDs is far more important than having MSGIDS that
 NB> *look* like some old fido users/ops expect to see. Here are some
 NB> example FTN MSGIDs taken from Fidonet backbone echos in 2002:

 NB> <9j57nl$r5a$1@linux.chungkuo.org> 737c6519

this one is non-conforming unless there really is a user with that name on that
system...

 NB> 900:104/1@relaynet.org 21c0979e

this one appears fine but more context is needed...

 NB> <ajfsd8$3gs$1@localhost.localdomain> fd787825

this one is non-conforming... i know there is no user with this name on my
system... in this case, at least the domain is incorrect...

 NB> Anyway, I think you get the idea. Obviously, none of those are
 NB> valid netmail addresses.

no one said "netmail addresses"... the second one may be... address the message
to the user in the FROM: field and send it to the gateway for zone 900...

[QUOTE]
  The originating address should be specified in a form that
  constitutes a valid return address for the originating network.
  If the originating address is enclosed in double-quotes,  the
  entire string between the beginning and ending double-quotes is
  considered to be the orginating address.  A double-quote character
  within a quoted address is represented by by two consecutive
  double-quote characters.
[/QUOTE]

"VALID RETURN ADDRESS FOR ORIGNIATING NETWORK" how hard is that to understand??

 NB> </RSwindell>

i didn't realise that all of the above was from rob... oh well... 

)\/(ark

 * Origin:  (1:3634/12)