Suresh Venkatraman wrote:
Disagree - DIX should work with any HTTP/1.1 UA, not just a browser.
Is there a dependency on processing HTML in DIX?
------------------------------------------------------------------------
No! I think the intended scope of DIX is to work within the existing
HTTP capabilities. In fact, DIX is intended to work in an
HTML/browser environment, rather than in non-HTML applications such as
WEBDAV or even browser-based AJAX schemes.
I also disagree. DIX needs to work with non browser clients. I'll post
my original use cases and restate my claim that core DIX needs to be
able to handle 1-4 and that 5 needs to be a natural extension to the core.
1. Eliot's dad wants to remember one userid and password for the web.
2. Eliot's dad wants to stop retyping his credit card information and
shipping address every time he wants to buy something on the web
3. Eliot's dad wants to share his online pictures with me and Eliot (and
only me and Eliot)
4. I want to subscribe to Eliot's dad's photocast so that as new photos
become available they are automatically downloaded to my machine.
http://www.apple.com/ilife/iphoto/features/photocasting.html
5. I want to print Eliot's dad's photos using a web photo printing
website. The web site that I use to print the photos is different to
the one that stores the photos.
Use cases 4 and 5 imply a non browser based HTTP/1.1 client. In 4 it is
iPhoto, but it could be any Feedreader and in 5 it is a non-SOAP based
api call from the photo printing service to photo storage service to
retrieve the photos.
Rob
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
