[ih] Some Questions over IPv4 Ownership

[Jack Haverty]

Hi Vint,

HTML5 was born somewhat after my tour of duty in W3C, so I'm not
familiar with the details.  But I think it's intent is primarily to
encode rich multi-media content - "documents" - so that they can be
passed across a wide range of user interfaces (PC screens, phones, etc.)
It's very good for adding structure to documents.

I was referring to XML as a way of conveying email *header* information,
among other things.  Conveying the email metadata in a structured way
isn't a new idea - it was embodied in RFC713 and RFC722 back in 1976,
from the sometimes pounding-head-against-a-wall experience I had in
building one of the MIT email systems. 

Having structured data enables all sorts of new user functionality -
e.g., archiving email and being able to later do very powerful searches.
The email program I wrote did this kind of stuff within its own world,
but the interactions across the net to other email systems and to the
DataComputer were too unwieldy and error-prone to do any fancy stuff in
a distributed way.  Hence the motivation for structured data in the
protocols.

So, yes, HTML5 would be the way to transport email content.   But XML or
something with similar characteristics would handle the metadata of the
headers and events (like delivery, reply, forward, addressees,
distribution lists, etc.).  Couple that with today's hardware and
database technology, and very cool things are possible.

On the other hand, most of the planet now seems enamored with typing
one-liner messages with their thumbs...

/Jack

PS We seem to have wandered pretty far away from "IPV4 Ownership", so
I'll be quiet now...

On Fri, 2010-10-15 at 12:18 -0400, Vint Cerf wrote:
> i hope HTML5 instead :-)
> 
> v
> 
> 
> On Fri, Oct 15, 2010 at 11:38 AM, Jack Haverty <jack at 3kitty.org> wrote:
> > Yep, we're on the same page.  Email portability exists now, if you just
> > get a domain name per recipient.  I suspect the DNS today couldn't
> > handle that if too many people did it.  Yes, yuch.  But a similar
> > mechanism must exist today inside the telephone world so it's proven
> > possible.
> >
> > I think eventually we'll all have portable email addresses.  Not too
> > long either.  Our addresses might just be our cell phone numbers.  Why
> > not...email and voicemail aren't all that different except at the very
> > endpoints of the path.
> >
> > Naah, I'm not mad about the encoding in 733.  But I'm happy that
> > structured data encoding has finally caught on with XML.  If those now
> > ancient mail protocols got a facelift today, I bet they'd be based on
> > XML.
> >
> > /Jack
> >
> >
> > On Fri, 2010-10-15 at 07:40 -0400, Dave CROCKER wrote:
> >>
> >> On 10/15/2010 12:12 AM, Jack Haverty wrote:
> >> > If "jack at 3kitty.org" is the example of forwarding you have in mind,
> >> > that's not how it works.  When I change providers, I move my 3kitty.org
> >> > service from one provider to another,
> >> ...
> >> > I do have a bunch of xxx at 3kitty.org mailboxes, and they all must move
> >> > together.
> >>
> >>
> >> You are emulating a version of exactly the service I described towards the end
> >> of my note, modulo the extra forwarding hop. It's key feature is that it is
> >> independent of ISPs and it does not require their cooperation.
> >>
> >> However, as you note, all of the mailboxes must move together:  granularity is
> >> at the domain name level, not the mailbox level.  To get per-user granularity,
> >> you have to encode it in the domain name, given the way email routing works.
> >>
> >> The reason you can have "direct" routing, without having to go through a
> >> forwarder is that you control the DNS MX record.  In effect that means an MX
> >> record per "customer", if not per "mailbox".  Again, that's doable today and it
> >> is done today.  The challenge is scaling that model up to a mass market.  In
> >> effect, it means an MX per user (or maybe per family).  Yuch.
> >>
> >> d/
> >>
> >> ps.  I figure you're still unhappy we didn't adopt your encoding scheme when we
> >> did RFC 733...
> >>
> >>
> >>
> >
> >
> >