Several people have asked that we track the issues relating to the MASS
charter. The list below lists the issues that I have been able to find
from going through the mailing list archives. Each item is listed with
the email address of the first person (I think) who raised the issue,
along with the date/time of the message to enable you to locate it.
Dates/times are US/Pacific. All items are open except for a few marked
(Incorporated) which have been edited into the current version of the
charter at http://mipassoc.org/mass/mass-charter-05dc.txt
Determining what's a new issue isn't always black and white -- sometimes
it's hard to distinguish discussion on a particular point from a new
proposal. So if I have left anything out, please let me know and I'll
add it. Similarly, if you have an item that is listed here that is
really just a comment on some other item, let me know and I'll remove it.
Please use this thread to comment on the list itself (omissions, etc.)
but not charter issues themselves; I'll start individual threads on the
open issues so that we can keep the discussion straight.
1. wayne(_at_)schlitt(_dot_)net 7/14/05 15:40 (Incorporated)
Is the intent of the WG to create standards-track RFCs?
2. wayne(_at_)schlitt(_dot_)net 7/14/05 15:40
Is the intent of the WG to rubber-stamp the DKIM drafts?
3. william(_at_)elan(_dot_)net 7/14/05 16:04
"minimal changes deemed essential to the viability of the service" too
4. ned(_dot_)freed(_at_)mrochek(_dot_)com 7/14/05 17:30 (Incorporated)
"deemed useful to improve the viability of services based on these
5. pbaker(_at_)verisign(_dot_)com 7/14/05 19:05
Allow extensions that improve functionality by building on the existing core
6. nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 7/15/05 7:22
Should an author (Fenton) be co-chair?
7. william(_at_)elan(_dot_)net 7/15/05 8:41
Several core ideas in META Signatures should be in-scope
8. dotis(_at_)mail-abuse(_dot_)net 7/16/05 14:21
Wording excludes checking of message content to address header replay
9. dotis(_at_)mail-abuse(_dot_)net 7/19/05 20:17
Should rendering to users via the MUA be in-scope?
10. ned(_dot_)freed(_at_)mrochek(_dot_)com 7/20/05 7:10 (Incorporated)
"useful, to improve" should read "useful to improve"
11. william(_at_)elan(_dot_)net 7/20/05 8:13
Should not focus exclusively on public key retrieval via DNS
12. nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 7/20/05 20:28
"minimal changes" should read "necessary changes"
13. nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 7/20/05 20:28
Add other I-Ds (Murray's, Phil's, or William's) as input documents
14. nobody(_at_)xyzzy(_dot_)claranet(_dot_)de 7/20/05 20:28
Add "most likely" to "keys will be stored…in DNS…"
15. tlr(_at_)w3(_dot_)org 7/21/05 2:57
Permit key discovery as well as storage
16. pbaker(_at_)verisign(_dot_)com 7/21/05 5:59
Make explicit that interactions with reputation and accreditation
systems are in-scope
17. pbaker(_at_)verisign(_dot_)com 7/21/05 7:27
Support advertising locations of X.509 certificates in key records
18. andy(_at_)hxr(_dot_)us 7/21/05 13:58
Include investigation of security issues described in
draft-housley-mass-sec-review and draft-otis-mass-reputation
19. pbaker(_at_)verisign(_dot_)com 7/22/05 12:36
Should downstream communication of authentication results be out of scope?
20. arvel(_at_)altn(_dot_)com 7/22/05 15:29
"Document" rather than "communicate" authentication results
21. james(_dot_)scott(_at_)liverton(_dot_)com 7/25/05 3:06
Alternative key retrieval mechanisms may be defined by future working