ietf-mailsig
[Top] [All Lists]

Charter issues list, 7/27/2005

2005-07-27 23:10:59

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.

-Jim


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 restrictive
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 specifications"
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 group process



















































<Prev in Thread] Current Thread [Next in Thread>