Re: [MORG] [Technical Errata Reported] RFC6154 (4422)

[Barry Leiba <[e-mail]>]

> [I'm not sure of the procedure for discussing errata, but here's my
> thinking.]

Thanks for that, Jamie -- responding with your thoughts is exactly
what you should do.

Normally, errata should not be used for issue tracking, which is what
Chris did here.  He said up front that he expected this to be "held
for document update", which means that the "error" he raised is too
involved for a simple fix that might be "verified", and that it needs
to be discussed further if the document is ever revised.

In fact, you're right that this wasn't an error in the document: we
never intended to specify how special-use folders are bootstrapped.
The reason I agreed with Chris and marked it HFDU is that I think any
revision of the spec *should* address that issue, and that, while it
wasn't, strictly speaking, an error in the spec, it was an error on
our part not to consider it.  And I think we should consider it if we
ever revise it.

Unfortunately, I think it's likely that we won't ever revise it, so
the point may be moot.  Maybe the best way to handle this is for
someone (Chris?) to write a separate document that updates this one,
which specifies how the special-use mailboxes should be set up in the
first place.

Barry

> Thanks for implementing the spec and providing feedback.
>
> Certainly the spec is vague on the point of who creates special-use folders.
> If the server supports CREATE-SPECIAL-USE (presumably that was the case in
> your example), then either the server or client can create them. In this
> case the client software could have seen that 1) the special-use folders
> were missing but 2) the server supported CREATE-SPECIAL-USE, and then
> decided to create the folders itself. There's nothing in the spec to
> counterindicate this behavior--i.e. nothing that requires the server to
> create the special use folders. What happened next--did the client create
> new folders but not add the special-use attributes?
>
> It seems to me that, even without this spec, someone (client or server)
> would be creating these folders. With the spec, the same entity should
> create the folders with the appropriate special-use tag, but first check to
> see if a folder already exists with that tag and, if so, use it instead. So,
> a client that needs to put Drafts somewhere should 1) look for an existing
> folder with \Drafts and 2) if that doesn't exist, create one and annotate it
> with \Drafts if the server supports CREATE-SPECIAL-USE. Similarly, if the
> server does automatic junk mail classification and needs a folder for junk
> mail, it should 1) look for an existing \Junk folder and 2) if it doesn't
> exist create one. (As a corollary, the server can create any needed
> special-use folders at account initialization, since it knows there will not
> yet be any existing folders.)
>
> Anyway, this seems like a good topic for discussion, but is not (yet) a
> clear error in the specification. Perhaps you should raise it on
> [e-mail]?
>
>
>
> On Mon, Jul 20, 2015 at 12:25 AM, RFC Errata System
> <[e-mail]> wrote:
>>
>> The following errata report has been submitted for RFC6154,
>> "IMAP LIST Extension for Special-Use Mailboxes".
>>
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6154&eid=4422
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Chris Newman <[e-mail]>
>>
>> Section: GLOBAL
>>
>> Original Text
>> -------------
>> N/A
>>
>> Corrected Text
>> --------------
>> N/A
>>
>> Notes
>> -----
>> There is missing information in this RFC that resulted in interoperability
>> problems when we performed an informal interop test of multiple
>> implementations on 2015-07-19. This is assumed to be a "hold for document
>> update" errata.
>>
>> There is no guidance in the document related to how special-use attributes
>> are bootstrapped. Servers may pre-create them but there's no requirement to
>> do so and clients may use the CREATE-SPECIAL-USE or METADATA extensions to
>> bootstrap but there is no requirement to use those mechanisms if the server
>> offers them. This resulted in a server implementation assuming the client
>> would bootstrap these attributes and a client assuming the server would do
>> so, thus interoperability failed.
>>
>> Given this experience, the fastest way to resolve this interop problem
>> over time is for both client and server to take responsibility for
>> bootstrapping special use mailboxes. This means if clients create a mailbox
>> intended for special use (e.g., drafts, sent, junk, trash, etc), and the
>> CREATE-SPECIAL-USE extension is offered, then clients need to provide the
>> USE extension to improve interoperability.  Servers that are provisioned
>> with an end-user's locale or language need to pre-create appropriate
>> special-use mailboxes to improve interoperability of this extension. For
>> existing accounts where the server is upgraded to support this feature, the
>> server can look for mailboxes with names that imply special use and add the
>> attribute to those mailboxes (especially if the server has locale/language
>> awareness provisioned for users). Clients that implement a name-based search
>> if special use attributes are not present and decide to use a mailbox for a
>> special use based on its name can use the
>>  METADATA extension, if offered, to label that mailbox appropriately.
>>
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.
>>
>> --------------------------------------
>> RFC6154 (draft-ietf-morg-list-specialuse-06)
>> --------------------------------------
>> Title               : IMAP LIST Extension for Special-Use Mailboxes
>> Publication Date    : March 2011
>> Author(s)           : B. Leiba, J. Nicolson
>> Category            : PROPOSED STANDARD
>> Source              : Message Organization
>> Area                : Applications
>> Stream              : IETF
>> Verifying Party     : IESG
>>
>