Subject: iTIP REPLY question

From: "Preston Stephenson" <[email-masked]>
Date: Thu, 24 Apr 2003 12:50:48 -0600

I need a clarification on where the iTIP REPLY object is created in a
reply to an iTIP REQUEST in CAP.

Given CUA1 with CS1 and CUA2 with CS2.

CUA1 creates a METHOD:REQUEST object for CUA2 in CS2.
CUA2 reads the METHOD:REQUEST object in CS2.
CUA2 creates the METHOD:REPLY object for CUA1.

In which CS is the METHOD:REPLY object created, CS1 or CS2?

The iMIP logic says it gets sent back to CS1. There is no way for iMIP
to get the reply back from CUA2 in any other way than for CUA2 to send
the REPLY back in an email message.

In CAP there is a CARID:REQUESTONLY VCAR to deposit METHOD:REQUEST
objects in another CUA's CS.
There is also the CARID:UPDATEPARTSTATUS VCAR to update PARTSTAT
information.

How do I get the rights to place METHOD:REPLY objects in another CUA's
CS?
How do I access the other CS?

If I have to create METHOD:REPLY objects in my own CS and have other
people query for METHOD:REPLY objects then that breaks the functionality
with iMIP. iTIP is suppose to be transport independent, so I would
expect the METHOD:REPLY to back in CS1.

Thanks.
Preston

---

From: John Stracke <[email-masked]>
Date: Thu, 24 Apr 2003 15:11:04 -0400

>In which CS is the METHOD:REPLY object created, CS1 or CS2?
And the other question is, why would anyone bother? Why is doing 
store-and-forward iTIP over CAP better than doing it over email? Why do 
we expect it to be compelling enough to get people to put yet another 
address on their business cards?

-- 
/=============================================================\
|John Stracke      [email-masked]                      |
|Principal Engineer|http://www.centive.com                    |
|Centive           |My opinions are my own.                   |
|=============================================================|
|Seen in computer peripheral ad: "User-friendly dip switches!"|
\=============================================================/

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Apr 2003 13:32:32 -0600

> In which CS is the METHOD:REPLY object created, CS1 or CS2?

Nether, it is created in CUA2.

> the REPLY back in an email message.

If the ORGANIZER property in the REQUEST is a CAP uri, then CUA2 deposits
the REPLY into CS1. If the ORGANIZER property is a mailto uri,
then CUA2 e-mail's the REPLY to that e-mail address.

> How do I get the rights to place METHOD:REPLY objects in another CUA's

They must give it to you in advance. If they have not given you the
rights to deposit a REPLY into their CS, then they broke iTIP - ignore them
and throw away the REQUEST.

It is possible that they want you to connect anonymously.

> How do I access the other CS?

If the ORGANIZER property is a CAP uri, then open a connection
to that uri.

> expect the METHOD:REPLY to back in CS1.

No query needed from CUA1 into CS2. It is a push model.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Apr 2003 14:05:39 -0600

John Stracke wrote:
> store-and-forward iTIP over CAP better than doing it over email?

Remember iRIP? - that's why == real time. Really needed for
multi calendar synchronization. I agree it seems a waist of
time for only interpersonal calendaring.

> Why do 

Not needed, see the calendar locate RFC. Is all you need is their
e-mail address or the ORGANIZER property value.

--

---

From: John Stracke <[email-masked]>
Date: Thu, 24 Apr 2003 17:17:13 -0400

> time for only interpersonal calendaring.

Um...OK, how do you do sync with iTIP?

Or are you talking about doing a freebusy request? Because that's the 
only kind of iTIP request that CAP can make real-time; everything else 
has to wait for the CUA.  (You could have a bot acting as a CUA, but you 
could put a bot on your mailbox, too.)

>> Why do we expect it to be compelling enough to get people to put yet 
>> another address on their business cards?
>

Um...OK, right.

-- 
/================================================\
|John Stracke      [email-masked]         |
|Principal Engineer|http://www.centive.com       |
|Centive           |My opinions are my own.      |
|================================================|
|World domination should never be left to chance.|
\================================================/

---

From: John Stracke <[email-masked]>
Date: Thu, 24 Apr 2003 17:28:31 -0400

>> e-mail address or the ORGANIZER property value.

No, wait a minute--are you talking about RFC-2739, "Calendar Attributes 
for vCard and LDAP"? That doesn't solve anything unless you have 
someone's vCard (rare) or access to their LDAP server (even rarer, 
unless you're in the same organization).

You can still initiate a conversation with someone with just their email 
address; but, if nobody knows anybody else's cap: address, when is 
iTIP-over-CAP going to get used?

But, for a more fundamental question: Why do we expect it to be 
compelling enough to be worth implementing support for iTIP-over-CAP as 
well as iMIP? If users don't get much extra functionality, and if they 
don't want the hassle of keeping track of people's cap: addresses, why 
should we ask implementers to bother?

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Belief is not relevant to truth.          |
\==========================================/

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Apr 2003 15:47:29 -0600

> Um...OK, how do you do sync with iTIP?

Without a real time connection, how will you ever be able
to do real time synchronization? And we deferred that topic.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Apr 2003 15:56:05 -0600

> should we ask implementers to bother?

(1) Real time calendaring. -to be defined but will require a live connection.

(2) Not subject to e-mail delays across possible hundreds of calendars.
     And you VFREEBUSY example is a good example.

(3) Not bothered by some vendors limited processing of iCalendar
     objects sent via e-mail. Your CUA can work even if vendor-M
     fails to correctly process iCalendar objects.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 24 Apr 2003 15:57:22 -0600

> unless you're in the same organization).

Did you have another proposal?

--