[standards-jig] ical jep
stpeter at jabber.org
Tue Jun 10 23:14:27 UTC 2003
On Fri, Jun 06, 2003 at 06:12:33AM -0400, Justin Kirby wrote:
> I just submitted a formal ical jep to our friendly neighborhood jep
> editor. But if you want a quick peek before psa gets around to it...
> http://www.openaether.org/wiki/index.php?ical%20jep <-- in wiki form
> http://www.openaether.org/projects/ice.html <-- in html
> http://www.openaether.org/projects/jeps/ice.xml <-- in xml
OK, I'll publish this soon.
> As always please rip it apart and beat it up.
OK. :) Question:
This simply provides a transport for iCal. Why not just use HTTP? Or
file transfer (once *that* is ready) to send .ical files around?
Jim Ray and I were talking about another approach...
What do we want to support? What are our requirements? Is it enough to
just send ical snippets around? Personally, I think it would be really
slick if in my Jabber client (or some Jabber client) I can complete the
1. Create or delete calendar events
2. Accept or decline invitations
3. Receive notifications
#1 and #2 feel x:data-ish to me. #3 gives me that pubsub feeling.
Ideally x:data and pubsub would be Jabber interfaces to a native
calendaring service, which can also be accessed via HTTP (with SMTP
notifications) for those who have not sipped the Jabber Kool-Aid.
I could see something like the following:
Jabber <-- x:data --> | Jab |->| Apache |<-- HTTP --> Web Browser
Client <-- pubsub --> | API |<-| w/mod? |--- SMTP --> Email Client
| WebDAV |
So WebDAV stores .ics and .ifb files (or .xfc and .xfb in the future),
and there is a nice little Jabber API to that functionality, which
enables Jabber clients to perform some limited set of calendaring tasks
(personally I think the 3 tasks listed above cover 80% of what's needed,
but maybe more is required).
I think it's possible to define a protocol for such a subset and make
Jabber users happy. If you want to do more, create or use a dedicated
Jabber Software Foundation
More information about the Standards