July 15, 2005

via Tim Bray | ATOM 1.0 = BINGO! Sleeves have already been rolled up so now the shirts flat out coming off... Its time to roll out and begin delivering LLUP!

ongoing ? Atom 1.0

It’s cooked and ready to serve. There are a couple of IETF process things to do, but this draft is essentially Atom 1.0. Now would be a good time for implementors to roll up their sleeves and go to work. Here’s a comparison of RSS 2.0 and Atom 1.0, and Sam Ruby is updating the Feed Validator. I’ll update this page regularly with Atom-related news and feeds and pointers, send word if you want yours included. Read on for more.

First. Congratulations to Sam Ruby, Tim Bray, Paul Hoffman, Scott Hollenbeck, Mark Nottingham, Mark Pilgrim, Robert Sayre and the Ongoing list of contributors presented by Tim Bray.

As promised I will be moving forward with the LLUP specification with some of the other team members as well as possibly a few others to begin the road that will hopefully bring this specification into being as soon as time allows it as such. I think that, like many, you will find what LLUP has to offer to the world of XML communications via first, Atom, and then through the two main RSS formats as well as some non XML implementation to allow for a broader range of compatibility across the broad spectrum of devices that would be able to implement this small, but significant extension to the world of subscription based publishing.

For those who have read the draft from last November or at least have heard about some of the things it contains...

While the general idea is there, that is all old, dead, and buried content that has since been greatly simplified with the ability to implement portions of the spec almost immediatelly with very few lines of code. The next released specification (hopefully in less than a week) will be completely integrated into the Atom specification and used as the reference platform until things have settled a bit and time can be spent on RSS. If it turns out we find people willing to volunteer to help with the RSS stuff now, GREAT!!! But for now I am simply counting on having the resources we have now to then worry about what happens if more resources become available, when they become available.

For those of you wondering, LLUP stands for "Limited [Lifetime|Length|Location|List] Ubiquitous Protcol" and is defined as:

A messaging protocol for weblog intercommunication and decentralized messaging of time sensitive and/or geographically specific publications.

If not immediatelly obvious LLUP spells PULL backwards or, if thought of from the opposite side of a glass door the other side of where the PUSH sticker exists which nicely gives LLUP the slogan, "The Other Side of PUSH" which in and of itself suggests that its both a push and pull mechanism and yet from the other side of the metaphor its neither. The idea is to suggest that, much like email, there is a "layover" in which a message [NOTE: Here's where the email comparison is no longer valid] waiting for delivery must wait such that the senders credentials can be verified and validated against those with "open door" access to the recipient "inbox", those which have been label "hold for verification" allowing the recipient to take a peek a the sender, or subject or keywords before deciding if this is something of interest (this process can be automated but in no way is this automation process part of the spec) or junk, "labeled as SPAM" based on an ongoing communication process between servers in whom compare URI's and IP that continue to collect SPAM ratings and, in essence, black list these URI's and/or IP's (if drastic measures become obvious and necessary) and lets the rest of the system know about it.

If there is one key thing to take away from LLUP its that there are no messages that are being sent and instead "blips" that act as simple notification mechanisms that content is available. That content is given an id when the publisher first creates it and then stays within the confines of the sending server until such time as a request is sent from a valid recipient to gain access to the content of this feed. In other words, the ability to flood the internet with unsolicited content no longer exists as its the URI of where that content is located that is then used to access that content if and when the recipeient decides to do so.

What does this mean exactly? For starters the sender of a message becomes responsible for all bandwidth charges incured by its access which pushes the cost of spamming to the spammer instead of the ISP's who then pass those costs down the line to us. If I want to send a message to 10 million of my closests friends I best be prepared to shell out the cash (and have the bandwidth in the first place to handle the load) for the incurred bandwidth costs.

But that doesnt mean that if a message is sent the content is automatically sought after. Its only after the recipient says "yes, I would like a good deal on Viagra", a decision made based on the subject and/or keyword(s)that would then cause a request to be made to the sending server for the rest of the content.

Another immediatte benefit is that content that is usually forwarded to 100s upon 1000's of people along with the entire thread of each forward (WITH EMAIL ADDRESSES INTACT!!!) will instead be forwarded by simply sending a "this is SOOOO funny message" referencing the original URI it was sent from. So, what would normally amount to hundreds of thousands to millions of kilobytes of useless data being sent constantly back and forth across the internet now simply becomes a much smaller "blip" to the recipient who then >>> chooses first "do I really want to see this picture" <<< without simply having the content loaded into the email client without will or desire.

Does this help with viruses? Much like a podcast feed references an mp3 file an LLUP message might contain a link to an mp3 file, a photo, etc... or much worse, a virus. However once viruses have been found, there URI's can be blocked, the MD5HASH signature made public and used to match the MD5HASH signature that is a required (and simple to create and publish the key for) part of downloadable content if an implementation is to specification.

One of the bigger ares in which LLUP places huge potential is the ability to send message to GeoURI which, for example, could mean that local business can keep a certain area notified of their current inventory, the prices, if they suddenly run out of stock on a sale item, the price of a gallon of gas, movie times (and the ability to 'blip' back a purchase request which in turn 'blips' black a receipt in which you simply 'blip' to a 'blip' reader at the movie gates and, walla, your in your seats and watching your movie.) etc... Sounds a lot like text messaging, which in fact, it is... or it could very easily be implemented on such a system and as such little, if anything would have to be done to the mobile communications infrastructure for this to simply work and work right away.

For local residents this means a much more productive way to locate merchandise, to compare prices against local food chains, to be notified when Albertsons puts its doughnuts on sale for 99 cents, etc... by specifying a Geographic region (such as a zip code, area code, or a URI based GeoCode that can be published in the format similar to

> USA.REGION.WESTERNSTATES.WA.PUGETSOUND <

to have the sender, subject, and keywords of that message available to search through and make a decision against as well as a sense for just how long that price will be available based on the stop and start dates specified, allowing for a system in which when content is no longer valid it can be deleted from the system and not require us to trod through just to find the current items.

Travelers to new cities will find this type of information easily accssible unbelievably helpful, even sending a 'blip' to Google Maps for directions to a Chinese Restaraunt who just blipped out a special on something you think you were once told by someone you think knew what he was talking about was really good... you think.

Anyway, this make that kind of scenario possible and really simple.

From a Government standpoint and from a much more sensitive standpoint the ability to send pinpointed messages to a certain region (these analogies assume that cell phone or wifi providers would implement this type system and specify the GeoCode content they are interested in to then send to their subscribers if and when desired) would take a system like the "Amber Alert" system here in the united states and amplify its effectiveness to a level I doubt could be measured if you considered that if something of this nature were to be sent out (this could apply to bad weather such as flash floods, or tornados, or, without meaning to be disrepectful, sunami warnings) to the entire system of cell phone subscribers and people using their laptops at Starbucks or through other means of systems that are in place in our cars or homes such that in an instant an entire area can be notified in ways never before possible of things of the above suggested nature, potentially ending the hunt for a kidnapper within minutes or less with as many people as would be suddenly and instantly keeping an eye out for suspicous activitees or matching descriptions, etc...

In regards to the elements and attributes contained in the spec:

First, to give you a better understanding, the four "L" areas each have elements and attributes that the others dont require as each can server a different purpose, or when used together, a combination of purpose.) This proposed technology brings to the data feed table a combination of possibile extension elements including:

- a start and stop(expiration) date (or "start publishing this date" "stop publishing on that date")

- a single recipient element or a recipients element with additional recipient elements as possible children. These elements contain the intended recipient or recipients and are URI based, focused specificially towards using the existing blog implementations and technologies and the foundation in which LLUP builds up. Mechanisms such as the ping/trackback mechanism already in place can be used with LLUP as a way to notify a potential recipient of the data feeds existence.

- a "referenceID" attribute which is focused on referencing another data feeds id element as a mechanism for suggesting the contained content in the referencing feed is an "response" to the feeds content, should be "integrated" or added into that feeds content (if proper credentials are present), "replace" the refering feeds content (again, with proper credentials, or simply "reference" the content either in its entirety or pieces of the text contained in that feed using standard positioning values at a total character length starting from the beginning, starting character point to the beginning reference point, and, if a third value is present the total number of characters to include in the reference before stopping, otherwise until the end of the charcter sequence.

- and either a "keyword" element or "keywords" element with a combination of keyword elements for specifying the content contained in the spefified feed.

---

Actually, I will leave things here and simply let the next draft of the summary give you a much better feel for what LLUP is all about. As I said, the first actual test implementation will be using Atom, specifically because of the publishing mechanisms introduced as well as other elements that are part of the Atom spec that could be reused and therefore require less overhead for LLUP...

More on this in the near future...

Until then, Congratulations to everyone who helped with the Atom specification development. You all deserve a huge round of applause and a standing ovation!!!

Cheers :)

[UPDATE: A while back I made mention to the fact that it was my belief that in many ways blogs would become the center of our lives. But not because of vain "guess how many people read me everyday!" kind of way but instead as the primary point of communication and content publishing, access, etc... In other words, our blogs will eventually contain the ability to be "programmed" such that they would be able to be told by Delta airlines when a flight is late and notifiy your blog with this information. By acessing your blog remotely and securely you can easily gain access to this information, synch your calendar, quickly read your email (that is now in one central and globaly available place.. even your work items will become a part of this, either using your personal blog directly or integrating a trusted relationship with your work blog server and home blog server such that they can stay in synch.

Actually, if you were to take the Hailstorm project from the early .NET day's and instead of a centralized server focus on individual blog URI's for accessing or updating the necessary content you could probably take that same spec and within a month or two have a pretty sweet blog-based application specication in place an ready to do all the killer stuff it was planned for before the press scared everyone off which caued things to get unplugged. Centralized or Decentralized data is data, right?

Anyway....

There is SOOOOO MUCH MORE with all of this.... But, as much as I hate this phrase, so little time, so I must shut down the mouth and get some work done for a while... Cheers :)]