View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001998 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2026-09-02 09:40 | 2026-09-03 05:21 |
| Reporter | kre | Assigned To | msbrown | ||
| Priority | none | Severity | Objection | Type | Error |
| Status | Under Review | Resolution | Open | ||
| Name | Robert Elz | ||||
| Organization | |||||
| User Reference | |||||
| Section | XBD, XSH, XCU, XRAT | ||||
| Page Number | 1 | ||||
| Line Number | 1-100000 | ||||
| Interp Status | |||||
| Final Accepted Text | |||||
| Summary | 0001998: Where should MANTIS issues be submitted? | ||||
| Description | I just spent an hour or two filling in an issue report (a long one) only for when I submitted it to be told there was an invalid security token, either I had submitted twice (no) or the session had timed out (possible, given it had taken a LONG time to get all the details page numbers, line numbers, ... inserted properly. And to decide what exactly I needed to report. It told me to press the back button on my browser. I did. All the text I had entered was gone (in previous interfaces that didn't happen, I could create a new report, and cut and paste everything from the old to the new, which would take much less time, and no timeout would occur - it has been ages since my last interaction with this, I had forgotten this issue. | ||||
| Desired Action | Fix MANTIS - make the session timeout at least 4 hours (or none at all). And while you're doing that, someone please can you put me back on the mailing list - a couple of years ago, I had the (apparent) impertinence to attempt running my MTA with only v6 addresses as an experiment for a few weeks. Most sites I deal with didn't care (IETF, NetBSD, ...) but apparently the Austin Group demands (or did 2 years ago approx) that all participants have working IPv4. That's prehistoric. If it hasn't been fixed in the interim, fix that as well. | ||||
| Tags | No tags attached. | ||||
|
|
There is a Project "Aardvark Bugs" for this kind of report. I have created 0001999 (https://www.austingroupbugs.net/view.php?id=1999) to cover this issue. Please email Andrew Josey (ajosey@opengroup.org ) for the mailing list issue. |
|
|
I'm not saying this shouldn't be fixed but it's terrible practice to write a huge body of text directly inside the browser be it on this bug tracker or elsewhere because there are a million things that can go wrong ranging from timeouts to browser crashes to your connectivity going down to accidentally submitting the form prematurely, etc. |
|
|
Thanks for the change, 8 hours is definitely plenty. You can close this bug report now, and if you like, make it simply vanish completely. Thanks. I did see "Aardvark Bugs", and had a suspicion that would have been the right area to put this, and what's more, even started to fill in the form under that project - but the form for that wanted me to make choices I had no idea how to make (Aardvark 2025, Aardvark Mk III, Aardvark Mark V ...) and as I wasn't at all sure that Aardvark was in any way related to Mantis (beyond both being of zoological origin I assume) so I just decided not to proceed there. Adding "Mantis" as one of the choices for the Category would have changed everything. I do agree that writing long messages in a browser is not always wise, though none of the reasons given really apply - my browser simply does not crash (never seen that happen) though I do need to kill it from time to time - it has both memory & thread leaks, and eventually its UI gets too slow to tolerate because of that, but that killing is done at a time of my choosing, which would not be in the middle of filling in a form. Connectivity issues are irrelevant, or should be, browser/server interactions only last as long as is needed to transfer whatever needs transferring, and in the case of most IPv4 transactions at least, they're not even likely to (appear to) the server as coming from the same place, as there are certainly multiple layers of NAT involved (NAT between my LAN and the ISP, more NAT between the ISP and the world at large) and after just a few minutes of dead time between transactions, the chances of being assigned the same identification for future connections as past ones is minuscule. Accidental submission is a potential problem, I have done that, but it is almost always because I thought I was finished, when I really wasn't ... the preparation method for the data won't affect that kind of error. This time however, when I started, I didn't know just how long the message would be, I started out with just one simple issue to report, then when I looked at the page while collecting line number details, etc, I just kept finding more and more to report, so the message just kept getting longer and longer, and taking more and more time. Another thing I forgot, a technique I have used before, is that these notes have no similar timeout - I could spend days composing this note, and when I am done, submit it ("Add Note") and it will be accepted. What's more, I can (or could in the previous interface, haven't used this one this way yet [edited in later: I see I still can, good!]) edit notes to fix typos, formatting, or to add or remove actual text - none of that is possible with the original report text. So, in the past I have created an issue with nothing much more than the summary, etc, and then "A note will be attached with the description, and a later note with the proposed changed", and then add all the real text that way. wrt the e-mail list, I'm afraid there's no point attempting to join that after all - the servers for opengroup.org will no longer accept e-mail from me (from munnari.oz.au) and I simply refuse to bow down to the current e-mail tyranny and alter the way I do things - some of which is out of my control anyway (munnari currently has no PTR records - I no longer care, as those things have become a useless joke - but I can't do anything about it anyway, the owners of the address space control that DNS zone (those zones) and they decide what goes there, I don't - getting public static IPv4 addresses in some parts of the world (including where I am) is difficult, so I am keeping what I have, as long as I can, regardless of the issues it causes. And last, (since gmail is one of the destinations that refuses mail from munnari) - re being a poor volunteer standards org, I fully understand. But running an e-mail server is not a very onerous task, particularly if one ignores the mandates of the almost monopolies and doesn't keep trying to keep up with their ever changing demands. But as (effectively anyway) an IEEE or ISO working group, those orgs should be providing some support, at least as much as is needed to run an e-mail & web server - they should be doing that for everyone who provides content for them. If they won't, you might want to consider contacting the IETF (or ICANN) and proposing joining them (with or without remaining with IEEE etc). After all, part of what the POSIX standard involves are interfaces to all of their networking systems, so the match would be plausible. That would mean a whole new set of bureaucracy to get used to, but they do run e-mail servers (including v6!) and web servers, which all work. |
|
|
Oh, and I will resubmit (something similar to) the original failed issue report, in a few days, once I recover the enthusiasm needed to do it all again. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2026-09-02 09:40 | kre | New Issue | |
| 2026-09-02 15:35 | msbrown | Assigned To | => msbrown |
| 2026-09-02 15:35 | msbrown | Status | New => Under Review |
| 2026-09-02 15:47 | msbrown | Note Added: 0007487 | |
| 2026-09-03 00:28 | Love4Boobies | Note Added: 0007489 | |
| 2026-09-03 05:14 | kre | Note Added: 0007490 | |
| 2026-09-03 05:17 | kre | Note Edited: 0007490 | |
| 2026-09-03 05:21 | kre | Note Added: 0007491 |
