Not sure how message expiry is a standards compliance issue. SMTP, MIME and RFC822 et. al. don't say anything about where, how or if the message gets stored once transmitted.
> Not sure how message expiry is a standards compliance issue.
using market-influence to build massive scale expectation for a feature which can't actually be supported by the underlying protocol in an effort to 'embrace and extend' is exactly a standards compliance issue, and precisely what led to microsoft's internet explorer being labeled as an antitrust violation.
> Well, I think this works differently. The email just includes a link to a Google webpage with the email. It’s still just an email sitting in your inbox. It doesn’t remove itself automatically.
The email standard was built so that you can check your email with a client, and view the contents offline at your convenience, archive, back up, etc.
Google's email proposal kills this functionality.
When was the last time I used this, you may ask? On Saturday. I was in one of the slot canyons in Utah with zero signal, and, while taking a break, I wrote several emails in my Opera email client, in response to some messages I've procrastinated writing a response to.
The trickery is that the sender might think they're sending a message over email to the recipient, whereas they are sending the message to Google's servers over an internal protocol, and are sending a link to the message to the recipient over email.
How do you distinguish between this and, say, e-cards? Blue Mountain has been sending e-mail links to ephemeral content since at least the early 2000s.
I'm not missing anything. There's nothing wrong with placing links in emails. The link is good, presumably in and out of gmail, and is clearly a gmail feature, not an email feature. There's no problem here.
> The link is good, presumably in and out of gmail
The link is clearly not good out of Google ecosystem. You need to have a Google account to view it. Otherwise, there's nothing stopping the e-mail client (or even recipient's email server) from fetching the link upon receipt.
To be clear: Gmail want to be a UI for sending messages via a proprietary protocol which look like emails to the sender and receiver if they are Gmail users.
If your outgoing emails were silently converted into Snapchat messages (more features! why not! everyone's one Snapchat anyway!), would you be similarly unconcerned?
>and is clearly a gmail feature, not an email feature. There's no problem here.
That's precisely the problem: turning Email into Gmail.
Remember how IE added features to HTML which were IE features, not HTML features? Remember how it wasn't at all a problem?