Re: [Imap-protocol] Seeking clarity on Gmail "Access for less secure apps" setting for non XOAuth2 access

El mar, 02-09-2014 a las 14:09 -0700, Brandon Long escribió:
> 
> 
> 
On Sat, Aug 30, 2014 at 2:02 PM, Arnt Gulbrandsen:
>         The point of 5530 and that registry was that clients should
>         not need to do such things. IMO Google screws up by not
>         defininig response codes, not you.
>
> 
> Extending the available codes via RFC seems heavy weight, especially
> if its for things that are more specific to our server.  Maybe a list
> of "generic but more specific" ones could be made, but would we really
> have one for "Your domain administrator has disabled IMAP for your
> domain from this IP"?

Instead of a RFC listing each error, that's more suited for creating a
registry of error codes. Although the idea of using a wiki seems better
than placing it at IANA.



> 
> As for the WEBALERT case, its expected that the correct thing to do is
> to send the user to the url specified, but it has to be the user,
> they're likely to have to authenticate the session.
> 
> 
> Half of the above would be UNAVAILABLE or maybe CONTACTADMIN, some
> would be LIMIT/OVERQUOTA... but its unclear how much "clearer" these
> would be if they're translated to the user's language via a "generic"
> category.
> 
> 
> We have debated having a per-message unique identifier, also useful
> when people contact us about which error they're seeing, but haven't
> exposed it.  I'd say we could translate these with our upcoming
> support for UTF8, 

I'm not too keen about providing translated messages unrequested.


> but these are almost assuredly seen prior to any ENABLE that would
> help.

Specially given that you can only use ENABLE in the authenticated state.

<random ideas>
It may be worth taking into account SMAP 'LANG' capability announcing if
creating an extension for handling that. A extension for supporting
translated messages might be:

The server exposes the capability by announcing a series of
LANG=<langtag> tokens on its CAPABILITY. <langtag> is a language tag as
defined by RFC 1766. Providing just LANG means the server supports some
translations but is not providing the full list.

The client requests internationalization of the messages with <tag> LANG
<langcode>. An untagged response is provided with the actual language
chosen by the server (eg. the user requested EN-COCKNEY but the server
provided EN-GB)

'<tag> LANG ?' could be used for requesting a list of languages
supported by the server.

And '<tag> LANG' for declaring support for the extension but stating no
preference. The server may choose a language based on an account
setting, a default for its domain, ip geolocation, etc. Note that the
server may decide to send an untagged LANG after login.


1- http://www.courier-mta.org/cone/smap1.html

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol