Denis (using Winpoint) hasn't been seen lately. Maybe something
got buggered up badly?
That's telling him!
It's not really a problem. Because collisions in the MSGID
seldom happen...
How would you know? If you are only referring to your software of choice then the above might be true, especially if it is a single user application
which is common these days.
It doesn't conform to the standard.
Understood. Not a big deal as it could easily become redundant and unneeded once a real standard is in place that doesn't require ANY kludges.
It doesn't conform to the standard either...
I believe you are wrong about that but then again you're spin on it might have validity simply because of obsolesence. So far the only issue I have seen is on one particular point software that buggers up the REPLY kludge but has no effect on what really matters.
Speaking of nonconformity and obsolesence what is the deal with your
bogus CHRS kludge? -> "CHRS: UTF-8 2"
It might make someone question your credibilty on mattters of
conformance to "standards". Not me of course but then I am not that
anal when it comes to conformance to phoney-baloney kludges.
@MSGID: 1:153/7001 tmCYOYVw
Please note the MSGID of this reply.
Besides not conforming to the standard, and maybe cosing
problems in software down the line...
It seems to be a problem for WinPoint when building a reply
message. The REPLYID seems to result in 00000000.
Because it doesn't conform to the standard (not strictly
hex chars),
You are adding words to the spec. "strictly" does not appear.
;) However, "may" is very clear. :D
my tosser uses a different method for calculating a hash
for this message (for dupe detection), which uses more cpu
cycles. And thus heating up the planet more than a
standard conforming MSGID. :-(
They're all just a bunch of 1's and 0's in the end. It's all
the same stuff. :D
If you want a better unique identifier in ftn messages,
create a new kludge (see my suggestion for the @UUID one,
which needs a @RUID btw for replies), so you can do what
you want, and make it as good as possible without having
to consider existing software. Then write a proposal and
convince software developers to implement it in their
software.
So, are kludges like the wild wild west where anything goes?
That *is* a handy way to extend functionality and features.
It seems to be a problem for WinPoint when building a
reply message. The REPLYID seems to result in 00000000.
So that is the first discovered problem. There are
probably more. And probably harder to discover...
Because it doesn't conform to the standard (not strictly
hex chars),
You are adding words to the spec. "strictly" does not appear.
;) However, "may" is very clear. :D
I beg to differ...
They're all just a bunch of 1's and 0's in the end. It's
all the same stuff. :D
But how we get there isn't...
;) However, "may" is very clear. :D
I beg to differ...
According to fta-1006, the definitions are clear. But
interestingly, the doc expired 20 years ago. Why a definition
doc needs to expire (and not be replaced by something else)
alludes me.
They're all just a bunch of 1's and 0's in the end. It's
all the same stuff. :D
But how we get there isn't...
Oh.. that's true enough. But I've made my point. Assuming that
the serialno must be implemenet in hex is just that, an
assumption.
I think I red somewhere that every ftsc document needs to be
reviewed every 2 years
Well if most software expects a hex number, maybe the standard
needs to be reviewed, and worded more strict. ;)
Well if most software expects a hex number, maybe the standard
needs to be reviewed, and worded more strict. ;)
Or not. As is I think it is clear enough but a review of all standards is a good idea including MSGID/REPLY.
To review if they still describe current practice,
or could be worded better, not to change them to something
incompatible with current practice. ;)
..as well as the only user of an
official point system,...
official point system,...
What system is that?
Yet you viciously mention it...
Yet you viciously mention it...
I call that therapy.
I call that therapy.
For whom? You, or Wilfred? :D
The ftsc write-ups could serve as a guidebook for
solutions and examples and help remove ambiguity and false
interpretations.
FTA-1006 might be of interest to you wrt the subject at hand.
But even that one "expired" twenty years ago. :( So.. is it
valid today or not? :/
As valid as any of the other ones. I think if
there is a bone to pick with any document the
FTSC_PUBLIC echo would be the place to start.
Speaking for myself (all three of me) this
conversation in this particular echoarea was a
very good warmup for what could transpire if
anyone were seriously considering a needed
change. I still believe it could happen.
I have highlighted a few clerical flubs in the recent past in
there.
and 10 people at the helm
The nodal me thinks we have bigger fish to fry.^^^^^^^^^^^^^^^^^^
and 10 people at the helm
There's a helm?!?!?!?!
^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
^^^^^ ^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
I think rice goes better with fish.
Ok. The menu of savoury delights exists: FTS-XXXX, FTP-XXXX
..now get er done! <g>
I've been rethinking the rfc-3339 idea. Also spring
cleaning (the weather has been fantastic the last week) and
the second in the series of three x86_64-motorshed-linux-
gnu upgrades. Maybe by the end of the week.
Is there any item of interest to you?
This is my view as I take a glance above the laptop.
Not sure. It seems that you have some fine priority ideas.
This is my view as I take a glance above the laptop.
That is a nice view, other than the window that is. ;-)
(YYYY-MM-DD hh:mm:ss(+|-)utc_offset). If the
(+|-)utc_offset is dropped then the remainder fits in
EXACTLY in the field specified..
My personal favorite is the hex output of unixtime seconds-
nanoseconds but moreso as a unique serialno such as used in
MSGID/REPLY kludges. However I personally don't want to
screw with that particular document especially considering
how embedded it has become in fidonet MSGing.
But I might tackle the one in the picture - before the
blackflies emerge.
Whatever direction you take, feel free to announce any advances
and progress in FUTURE4FIDO (F4F).
-={ 2021-04-18 14:03:26.305578442+00:00 }=-
Hey August!
^^^^^^^^^^^^^^^^^^The nodal me thinks we have bigger fish to fry.
and 10 people at the helm
There's a helm?!?!?!?!
Ok.. kitchen. Cooks in the kitchen. And only because you
mentioned nodals (sic), noodles.
I think rice goes better with fish.
Life is good,
Maurice
... Wel mon sceal wine healdan on wega gehwylcum.
One does well to keep a friend on every road.
If fish is the primary item, then yes.
If it is secondary, it may be added to a noodle bowl.
-={ 2021-04-25 14:21:39.573006446+00:00 }=-
Hey Carol!
If fish is the primary item, then yes.
It is a very big fish which in itself makes it primary.
If it is secondary, it may be added to a noodle bowl.
Speaking for myself, I think pork goes best with noodles.
Life is good,
Maurice
... Heald hordlocan, hyge fæste bind mid modsefan.
Hold close the treasure-chest, bind your thoughts fast within the heart.
Both go well with noodle bowls!
It seems to be a problem for WinPoint when building a
reply message. The REPLYID seems to result in 00000000.
So that is the first discovered problem. There are probably more. And
probably harder to discover...
I may have to spin up my Winpoint to see for myself. But apparently Winpoint is getting new life in development and the
uber msgid could be accomodated. :D
AREA:ASIAN_LINK
@RESCANNED 2:240/1120
@REPLY: 2:221/1.58@fidonet ef616eac
@MSGID: 1:153/7001 sTW6u3OA
@CHRS: UTF-8 4
-={ 2021-04-13 21:15:41.032014984+00:00 }=-
Test reply to see if WP now handles those invalid MSGID values
nicer ;)
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 119:09:31 |
| Calls: | 12,958 |
| Files: | 186,574 |
| Messages: | 3,265,631 |
