wikidata.txt

= RFC List =

Every RFC is the work of someone who felt enough pain from the
lack of something that they would make the effort to write the
document.  These problems need to be solved somehow - maybe
inherently in a different protocol, maybe explicitly.

There's not even an attempt to include address book, calendaring,
etc in this list yet!

||||||'''RFC List'''||
||RFC||Problem Solved||Plan for new Protocol||
||[[http://tools.ietf.org/html/rfc1730|RFC 1730]] Internet Message Access Protocol - Version 4||Replaced by 3501||See 3501||
||[[http://tools.ietf.org/html/rfc1731|RFC 1731]] IMAP4 Authentication Mechanisms||Authentication||We need to support good authentication mechanisms to succeed||
||[[http://tools.ietf.org/html/rfc1734|RFC 1734]] POP3 AUTHentication command||Additional Auth for POP3||Whatever we do with IMAP auth||
||[[http://tools.ietf.org/html/rfc1939|RFC 1939]] Post Office Protocol - Version 3||Simpler access mechanism than IMAP||Less necessary with higher resources available today.  Make sure protocol supports simple access to emails.  Special considerations: UIDL -> GUID mapping, RSET (undo) and "view selection"||
||[[http://tools.ietf.org/html/rfc1957|RFC 1957]] Some Observations on Implementations of the Post Office Protocol (POP3)||Syntax parsing problems||Don't roll-your-own syntax.  Have test process documented in standard||
||[[http://tools.ietf.org/html/rfc2060|RFC 2060]] Internet Message Access Protocol - Version 4rev1||Replaced by 3501||See 3501||
||[[http://tools.ietf.org/html/rfc2086|RFC 2086]] IMAP4 ACL extension||Fine-grained access control||Will need an Access Control mechanism.  Ideally not too different - reuse as much as possible.  May need to consider individual folders vs "entire user" in the context of folder-level ACLs||
||[[http://tools.ietf.org/html/rfc2087|RFC 2087]] IMAP4 QUOTA extension||Enforce resource limits, prevent abuse||Will need some form of Quota.  Expand scope to include other objects (annotations, keywords, num-folders, etc) consistently||
||[[http://tools.ietf.org/html/rfc2088|RFC 2088]] IMAP4 non-synchronizing literals||Extra round trip when uploading mesasges||No synchronising literals - this one becomes the default and only option||
||[[http://tools.ietf.org/html/rfc2177|RFC 2177]] IMAP4 IDLE command||"Real time notification"||Expand scope considerably - IDLE is insufficient for many users, because it only monitors one mailbox||
||[[http://tools.ietf.org/html/rfc2180|RFC 2180]] IMAP4 Multi-Accessed Mailbox Practice||Clarify ways to handle delete and expunge with other clients connected||Not using sequence numbers would render many of these moot.  Mixed responses (a la LMTP) would render many more of them moot.  Also need to handle the case of "partial IO error" - where data exists but can not be returned immediately for some reason||
||[[http://tools.ietf.org/html/rfc2192|RFC 2192]] IMAP URL Scheme||HTTP Mapping of IMAP mailboxes||Need to provide a HTTP mapping (see recent discussion on the imap5 list)||
||[[http://tools.ietf.org/html/rfc2195|RFC 2195]] IMAP/POP AUTHorize Extension for Simple Challenge/Response||More authentication handling||Merge into Auth, possibly by reference||
||[[http://tools.ietf.org/html/rfc2342|RFC 2342]] IMAP4 Namespace||Standardise a way to deal with existing different layouts||Specify one mailbox layout only.  Heirarchy separator will either be forced or not exist (tree data structure on the wire).  Either way fully merged with LIST/LSUB||
||[[http://tools.ietf.org/html/rfc2359|RFC 2359]] IMAP4 UIDPLUS extension||Fix insufficient information being returned from commands to synchronise state||All UIDPLUS returned information retained||
||[[http://tools.ietf.org/html/rfc2449|RFC 2449]] POP3 Extension Mechanism||Allow detection of capabilities of POP3 server||Out of scope||
||[[http://tools.ietf.org/html/rfc2595|RFC 2595]] Using TLS with IMAP, POP3 and ACAP||Encryption support||New protocol must support encryption, preferably as the default||
||[[http://tools.ietf.org/html/rfc2831|RFC 2831]] Using Digest Authentication as a SASL Mechanism||More auth||Merge into Auth||
||[[http://tools.ietf.org/html/rfc2919|RFC 2919]] List-Id: A Structured Field and Namespace for the Identification of Mailing Lists||||Mostly interesting as a searchable/sortable field||
||[[http://tools.ietf.org/html/rfc2971|RFC 2971]] IMAP4 ID extension||Identify the remote client||Very valuable for tracking down buggy implementations.  Require an ID||
||[[http://tools.ietf.org/html/rfc3348|RFC 3348]] The Internet Message Action Protocol (IMAP4) Child Mailbox Extension||Detect if child mailboxes exist for display and null-fetch optimisation||Ensure sufficient information can be queried in new LISTing system||
||[[http://tools.ietf.org/html/rfc3501|RFC 3501]] INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1||The main protocol document||This will need to be addressed in [[ImapRFC3501Sections|individual sections]]||
||[[http://tools.ietf.org/html/rfc3502|RFC 3502]] Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension||Efficiency and round-trip considerations for batch uploading||Ideally part of a more generic "batch operations" - more discussion required||
||[[http://tools.ietf.org/html/rfc3516|RFC 3516]] IMAP4 Binary Content Extension||Get server-side to decode part content||Ideally composible actions - first 1000 characters of decoded value of part "1.2" of message $GUID||
||[[http://tools.ietf.org/html/rfc3691|RFC 3691]] Internet Message Access Protocol (IMAP) UNSELECT command||Close mailbox without implicit expunge||Remove implicit expunge - problem no longer exists||
||[[http://tools.ietf.org/html/rfc4314|RFC 4314]] IMAP4 Access Control List (ACL) Extension||Clarify and expand ACL handling||See also comment on 2086 - need to support ACL handling||
||[[http://tools.ietf.org/html/rfc4315|RFC 4315]] Internet Message Access Protocol (IMAP) - UIDPLUS extension||Expand more on UIDPLUS||See 2359 comment - will be mooted.  GUIDs will be compulsory, even if you just use a hash of the message contents, so UIDNOTSTICKY goes away||
||[[http://tools.ietf.org/html/rfc4466|RFC 4466]] Collected Extensions to IMAP4 ABNF||Tidy up the ballooning synax variations||Avoid having such a complex ABNF - use a structured substrate of some sort.  It will be less human-typing-friendly, but more machine friendly||
||[[http://tools.ietf.org/html/rfc4467|RFC 4467]] Internet Message Access Protocol (IMAP) - URLAUTH Extension||Authentication token||Definitely want token based access so you can authenticate once and then re-connect with the same token, at least during the same "session"||
||[[http://tools.ietf.org/html/rfc4468|RFC 4468]] Message Submission BURL Extension||Send a message by copying content from an IMAP store||Supplement/replace with submit via same protocol.  BURL is too complex from a "interacting systems, firewalls and authentication methods" perspective||
||[[http://tools.ietf.org/html/rfc4469|RFC 4469]] Internet Message Access Protocol (IMAP) CATENATE Extension||Reduce bandwidth use by manipulating partial messages on the server||Definitely want to be able to do this||
||[[http://tools.ietf.org/html/rfc4550|RFC 4550]] Internet Email to Support Diverse Service Environments (Lemonade) Profile||Reduce bandwidth and resource use||Need to support the same use cases||
||[[http://tools.ietf.org/html/rfc4551|RFC 4551]] IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization||Avoid fetching flags for every message in a mailbox to see what's changed||Along with QRESYNC, need to support the same concepts - fast resync without holding a connection open||
||[[http://tools.ietf.org/html/rfc4731|RFC 4731]] IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned||Reduce bandwidth use and parsing requirements for search - also get a seqset to allow reuse without parsing/combining the sequence at the client||Flexible enough search syntax that all the use cases given here are possible||
||[[http://tools.ietf.org/html/rfc4959|RFC 4959]] IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response||Auth mechanisms||Should be supported as part of Auth||
||[[http://tools.ietf.org/html/rfc4978|RFC 4978]] The IMAP COMPRESS Extension||Reduce bandwidth use||Compression should be part of the transport layer||
||[[http://tools.ietf.org/html/rfc5032|RFC 5032]] WITHIN Search Extension to the IMAP Protocol||More search extentions||Flexible enough search syntax that the use cases are possible||
||[[http://tools.ietf.org/html/rfc5092|RFC 5092]] IMAP URL Scheme||URL encoding of IMAP mailboxes||This is almost a replacement protocol in itself - hopefully it will map almost untouched.  The hard bit will be extra things like metadata, condstore, which it doesn't seem to consider - so it's incomplete||
||[[http://tools.ietf.org/html/rfc5161|RFC 5161]] The IMAP ENABLE Extension||Make sure clients don't choke on extra response information||Explicity allow space for extention.  Make test case system add random "rubbish" where it's allowed to make sure clients/servers don't complain||
||[[http://tools.ietf.org/html/rfc5162|RFC 5162]] IMAP4 Extensions for Quick Mailbox Resynchronization||Fix "unaware of expunge" deficiency in CONDSTORE||new protocol will not have this particular deficiency||
||[[http://tools.ietf.org/html/rfc5182|RFC 5182]] IMAP Extension for Referencing the Last SEARCH Result||Avoid sending message set data backwards and forwards||Ideally, part of a more general "compose commands" - but the ability to store a search result for later manipulation will be needed||
||[[http://tools.ietf.org/html/rfc5228|RFC 5228]] Sieve: An Email Filtering Language||(and all the extentions)||Support Sieve - possibly even sieve fragments as "run this filter on this mailbox".  Common use case is "add a rule to filter messages matching X into a folder, and also apply that to the messages in INBOX now so existing ones get copied"||
||[[http://tools.ietf.org/html/rfc5255|RFC 5255]] Internet Message Access Protocol Internationalization||Support multiple languages||Definitely, need to keep this - language negotiation needs to be part of the initial connection||
||[[http://tools.ietf.org/html/rfc5256|RFC 5256]] Internet Message Access Protocol - SORT and THREAD Extensions||Server-side support for message ordering||Doesn't go far enough - particularly across folders.  Also fuzzy searching and partial response is an interesting area||
||[[http://tools.ietf.org/html/rfc5257|RFC 5257]] Internet Message Access Protocol - ANNOTATE Extension||Like metadata for folders, but for messages||Yet another axis of data - need to merge with keywords and regularise.  Specify quota and ACL handling (currently different for keywords and annotations).  Specify shared vs private "same keyword", e.g. shared \Seen and private \Seen ?||
||[[http://tools.ietf.org/html/rfc5258|RFC 5258]] Internet Message Access Protocol version 4 - LIST Command Extensions||Was there really a point? Except making LIST extensible and giving tiny bandwidth improvements and tiny server performance improvements||There are a few cases covering list andling - it's a lot more complex than the small amount of actual data involved justifies.  Massive deadwood cleaning required here||
||[[http://tools.ietf.org/html/rfc5321|RFC 5321]] Simple Mail Transfer Protocol||Submission of email||Need to consider interaction with submission if we support submission||
||[[http://tools.ietf.org/html/rfc5423|RFC 5423]] Internet Message Store Events||More detailed information about changes than IDLE provides||Good notification architecture is essential - absorb all this||
||[[http://tools.ietf.org/html/rfc5464|RFC 5464]] The IMAP METADATA Extension||Annotations for mailboxes||Along with Special-Use, metadata about mailboxes||
||[[http://tools.ietf.org/html/rfc5465|RFC 5465]] The IMAP NOTIFY Extension||Easy way to get new email notifications for all mailboxes||Combine with message store events||
||[[http://tools.ietf.org/html/rfc5530|RFC 5530]] IMAP Response Codes||Better machine-readable status information||Definitely want this, include||
||[[http://tools.ietf.org/html/rfc5550|RFC 5550]] The Internet Email to Support Diverse Service Environments (Lemonade) Profile||Set a baseline of "required supported features" to get a better experience||Exactly what we're planning here - everything you can do with Lemonade should be supported - not necessarily in the same way||
||[[http://tools.ietf.org/html/rfc5593|RFC 5593]] Internet Message Access Protocol (IMAP) - URL Access Identifier Extension||Clarify some bits of URL access, add streaming support||Hopefully URL access can stay almost exactly the same||
||[[http://tools.ietf.org/html/rfc5703|RFC 5703]] Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure||Sieve commands for manipulating messages||Keep, maybe see if it dovetails well with CATENATE for issuing server-side manipulations||
||[[http://tools.ietf.org/html/rfc5738|RFC 5738]] IMAP Support for UTF-8||Multiple charsets and encoding/decoding is annoying||Use UTF-8 everywhere from the beginning||
||[[http://tools.ietf.org/html/rfc5788|RFC 5788]] IMAP4 Keyword Registry||Register particular keywords that are already in common use||Either use them as-is, or map into annotation-space.  In particular, replacing pairs of mutually exclusive options with a "tristate" makes sense.  ($NotReported $ReportedAsSpam $ReportedAsHam) for example||
||[[http://tools.ietf.org/html/rfc5819|RFC 5819]] IMAP4 Extension for Returning STATUS Information in Extended LIST||Get status data on multiple folders more efficiently||Make it easy to not only get status data, but to get a list of which folders have changed since last request||
||[[http://tools.ietf.org/html/rfc5957|RFC 5957]] Display-Based Address Sorting for the IMAP4 SORT Extension||Match the sorting orders being done by clients||Would love to make this more general - sort by a somewhat arbitrary function on the message||
||[[http://tools.ietf.org/html/rfc6154|RFC 6154]] IMAP LIST Extension for Special-Use Mailboxes||A particular type of metadata - basicallly standarising Google's XLIST, near enough||Extend more - allow both private and shared "special uses", because there are contexts where both make sense.  Folder listing is one of the major pain points for client authors||
||[[http://tools.ietf.org/html/rfc6203|RFC 6203]] IMAP4 Extension for Fuzzy Search||Giving a human-friendly search result, sorted by relevancy||Everyone wants this||
||[[http://tools.ietf.org/html/rfc6237|RFC 6237]] IMAP4 Multimailbox SEARCH Extension||Simplifying "search from all mailboxes" for clients||And this!  But this one has a problem, it doesn't let you sort across folders, which makes it only half the solution.  Need to fix the sort as well||

(auto-generated from the list stored at [[http://github.com/brong/New-Mail-Protocol/|Github]])