On 6/14/2014 4:01 PM, Phillip Hallam-Baker wrote: > On Sat, Jun 14, 2014 at 3:14 AM, Dave Crocker <dcrocker@xxxxxxxx > > In a word - WebMail. > > This is a classic confusion between software implementation and > operation, vesus networking architecture. > > Webmail is nothing more than a particular style of user interface, > integrated into the operations of a particular service. > > It is the mode used by the majority of mail users today. Which makes it > rather more than just technology from a deployment point of view. This appears to be claiming that popularity alters whether something is 'technology' or 'architecture' or the like. For the point I was making, market penetration statistics are irrelevant. (There seems to be some confusion in the meaning of the term webmail. I have a guess about it's basis later in this note.) What makes a difference to architecture is architecture. Webmail is merely a classic centralized time-sharing server approach to email service, the same as we had from the 1960s (for standalone email service) and early 1970s (for networked email). It's prettier and faster, and perhaps a bit more functional, but architecturally it is identical. At base, the term is for marketing siloed email operations that are accessed through a browser. Marketing terms can be useful, as can the services they reference, of course, but they don't have much to do with technical architecture. > Of course WebMail is simple, I implemented a version of Webmail in 1993. I made no comment about technical complexity or its absence. Siloed operation certainly permits simpler decision-making for the operator and often permits simpler development for the software folk, and especially faster cycling of enhancements -- though one would be hard-pressed to call any of the current, major providers' internal systems simple... Change requiring multi-administration coordination is inherently slow and expensive, but it's the only choice when a service truly is global and, therefore, subject to the consensus (or lack of it) by many independent organizations. > It's a useful operating mode, within its limits, which typically > includes requiring full-time connectivity. ... > But if you are looking to change the mail system those limits are > irrelevant as they don't stop people using it. The changes are limited to that operator. Sometimes operators do wonderful things within their siloed environments. However if you are creating an interoperable change, it no longer has anything to do with the term 'webmail', since it has to do with open protocol standards, whereas 'webmail' has to do with accessing a centralized service, and either with a raw browser or with a proprietary active agent downloaded as session start. See RFC 5598, Figure 5. If there are architectural/technical characteristics about 'webmail' that are different from an implementation approach to the MUA then please provide a technical description. > More importantly, it isn't interoperable, in the sense we use the term > in the IETF, since it locks the user into the service provider for > literally everything. > > Umm, how do you work this one out? I am using gmail right now with my > phill@xxxxxxxxxxxxxxx <mailto:phill@xxxxxxxxxxxxxxx> address. The protocol between the user-side and server-side of the MUA is proprietary. The mechanisms for access the message store are (or can be) proprietary. Same for local access to the MTA. And best of all: The user is locked into the operators MUA (as I said before and you missed responding to.) My point was not that a proprietary webmail service is unable to exchange mail with other Internet Mail users, but that the environment /within/ the webmail service is entirely siloed. The world of email evolved to permit quite a bit of choice of operational components, and webmail services essentially eliminate those choices. That a user's world is made simpler by having a fully-integrated operator that downloads the MUA to the browser in real-time is an obvious and significant benefit for some/many users. But again, that's irrelevant to a discussion about email architecture. > There's no user ability to have a different MUA, different email > storage, different address book, different anything. > > Perhaps you should look at something before you speak about it. You are > completely wrong about all of those. In fact most MUA these days have > specific handling to integrate with gmail, yahoo, etc. After 40 years of doing email software, servers and standards, its richness as a playground for technical innovation and human use remain impressive to me. I still find some wonder at what there is to learn about it. Or perhaps... What your note confuses is the difference between being an email operator that might offer web-based access, versus accessing such a service through other means. That is, from what I can tell the confusion here is between "webmail" as a term referring to an access method for service -- where that term does have some technical merit, given the split UA -- versus use of the term to cover all aspects of an operator that offers such web-based access, which moves the use into purely marketing purposes. Hence it would imply that all gmail users are webmail users, which of course they aren't. Restated: It's possible that you are using the term to refer to any tightly-integrated operation of MUA, MS, MSA/MDA, and at least one MTA, where some users gain access through a web browser. That's certainly popular way to use the term amongst non-technical folk. I'm assuming rather more knowledge and care for technical discussion on an IETF list. Here, the term webmail only makes sense when referring to the web-related portion of some users' access, namely through a browser. Yes, gmail offers web-based access. And yes, I access my gmail account through IMAP and Thunderbird. But the first fact is irrelevant to the second. There is nothing about my access that is "webmail" anymore than it is webmail when I use a different setting in Thunderbird to access my bbiw.net account -- which I've been lazy about and haven't added web-based access to -- and get exactly the same type of service as I get from gmail. IMAP defines the service semantics and the nature of the window into the remote email store. > By having things > locked into the recipient's own email service provider, there is no way > to distribute out enhancements. > > So, for example, there is no way for the /author/ to declare an > attachment as being located somewhere else. > > Software authors have been declaring IETF approved features junk and > refusing to implement them for years. 'author' was used in juxtaposition with 'recipient'. I was/am referring to message authors, not programmers. > Consider the issue, the next time you want to send someone an instant > message. Do you send it via SMS, google, facebook, yahoo, skype or -- > oh yeah -- aol? That's a really prime example of the derivative effects > of excessive integration witha provider: combinatorial explosion rather > than seamless Internet integration. > > Well maybe the reason that problem hasn't been addressed is that too > many people take notice of the people whose only function is to tell > them that something can't be done, won't work, etc. Fascinating. It would be educational to see the documentation supporting that claim, especially since I thought the driving forces were customer capture by the operator and a lack of user demand for integration. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net