headers
Andrea Campi | 1 Aug 2002 18:30
Picon

Another dubious example


Hi all,

in 9.1.1 there's an example:

 In this example the initiator asks for the listeners capabilities.

   I: Content-Type: text/calendar
   I:
   I: BEGIN:VCALENDAR
   I: VERSION:2.0
   I: PRODID:The CUA's PRODID
   I: CMD;ID=xyz12346:GET-CAPABILITY
   I: END:VCALENDAR

   # After 3 seconds

   L: Content-Type: text/calendar
   L:
   L: BEGIN:VCALENDAR
   L: VERSION:2.0
   L: CMD;ID=xyz12346:TIMEOUT
   L: END:VCALENDAR

This should probably be:

   I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY

Bye,
	Andrea
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrea Campi | 1 Aug 2002 18:41
Picon

Question


Hi all,

I'm reading section 2.2 and I need confirmation I'm reading this
correctly. This might also be a hint that this might be stated in
a more explicit way...

[...]
If existing "UNPROCESSED" objects exist in the CS for the same UID then a CUA may wish to consolidate the
objects in to one "BOOKED" object. The CUA would fetch the "UNPROCESSED" objects for that UID and process
them in the CUA as described in [iTIP]. Then if the CUA wished to book the UID, then the CUA would issue a
"CREATE" command to create the new "BOOKED" object in the CS, followed by a "DELETE" command to remove any
related old [iTIP] objects from the CS. And it might also involve having the CUA send some [iMIP] objects or
contacting other CS's and performing CAP operations on those CSs. 
[...]
 Several "UNPROCESSED" entries can be in the CS for the same UID. However once consolidated, then only one
entry exists in the CS and that is the booked object. The others MUST BE removed, or have their state changed
to "DELETED".

There MUST NOT BE more than one "BOOKED" entry in a calendar for the same "UID". 

So I should first CREATE the BOOKED object and then delete the
UNPROCESSED ones, ok.
What puzzles me is the statement that "others MUST BE removed": how
can a server possibly enforce this? This is in fact saying that BOOKED
and UNPROCESSED entries MAY exist at the same time, however short
that can be.

By the way, this would be solved by doing it the other way around
(first delete then create) IFF we had some way of doing atomic
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stracke | 2 Aug 2002 20:44

Re: Question


Andrea Campi wrote:

>So I should first CREATE the BOOKED object and then delete the
>UNPROCESSED ones, ok.
>What puzzles me is the statement that "others MUST BE removed": how
>can a server possibly enforce this?
>  
>
By deleting the UNPROCESSED ones once the BOOKED one has been created, 
without waiting for the client to tell it to.

--

-- 
/===========================================================\
|John Stracke      |jstracke <at> centivinc.com                  |
|Principal Engineer|http://www.centivinc.com                |
|Centiv            |My opinions are my own.                 |
|===========================================================|
|Stupid, adj.: Losing $25 on the game and $50 on the instant|
|replay.                                                    |
\===========================================================/
Permalink | Reply | 0 comments |
headers
Doug Royer | 2 Aug 2002 21:22

Re: Another dubious example

Andrea Campi wrote:
> 
> Hi all,
> 
> in 9.1.1 there's an example:
> 
>  In this example the initiator asks for the listeners capabilities.
> ...
> 
> This should probably be:
> 
>    I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY

[this may be a resend - Netscape crashed just as I hit the send
 button]

If you are ever in Idaho - I'll take your fishing
on the Snake or Salmon river. *Thanks* for this help
with proof reading and checking the draft!

-Doug
Attachment (Doug.vcf): text/x-vcard, 378 bytes
Permalink | Reply | 0 comments |
headers
Doug Royer | 2 Aug 2002 21:30

Re: Question


> What puzzles me is the statement that "others MUST BE removed": how
> can a server possibly enforce this?

Your right. And John's post:

> By deleting the UNPROCESSED ones once the BOOKED one has been created, 
> without waiting for the client to tell it to.

I really had not thought of having the CS do it, we could.

Do we want to make the CS delete all unprocessed entries
for the same UID when a UID is booked? The the CS could
do its best to transaction lock (as you point out below).

> This is in fact saying that BOOKED
> and UNPROCESSED entries MAY exist at the same time, however short
> that can be.

You can have booked and UNPROCESSED entries for the same UID
in the CS. I meant to say that the CUA should do the removal
once the unprocessed entries are processed.

Are there any down sides to having the CS do the removal
automatically?

> By the way, this would be solved by doing it the other way around
> (first delete then create) IFF we had some way of doing atomic
> transactions...
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stracke | 2 Aug 2002 21:47

Re: Question


Doug Royer wrote:

>Yes. And if we did require the CS to do that (removal), then for
>implementations that have transaction enabled databases
>behind them - it would work safer.
>
Right.  And, for those that don't, it can't be made safer (unless they 
want to implement transactions themselves, which, ah, will give them 
some time-to-market problems ;-).

It might be clearer to add a new command to consolidate the entries, 
rather than having a DELETE happen as a side effect of CREATE.  In that 
case, we'd add the restriction that CREATing a BOOKED entry will fail if 
there's an UNPROCESSED entry with the same UID.

Alternatively, what are the implications of requiring the CUA to cope 
with BOOKED and UNPROCESSED existing together? That might be better--by 
removing a restriction on the CS, it'd promote scalability.

--

-- 
/===========================================================\
|John Stracke      |jstracke <at> centivinc.com                  |
|Principal Engineer|http://www.centivinc.com                |
|Centiv            |My opinions are my own.                 |
|===========================================================|
|Stupid, adj.: Losing $25 on the game and $50 on the instant|
|replay.                                                    |
\===========================================================/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrea Campi | 2 Aug 2002 22:29
Picon

Re: Question


On Venerdì, agosto 2, 2002, at 09:47 , John Stracke wrote:
>
> Doug Royer wrote:
>
>> Yes. And if we did require the CS to do that (removal), then for
>> implementations that have transaction enabled databases
>> behind them - it would work safer.
>>
> Right.  And, for those that don't, it can't be made safer (unless they 
> want to implement transactions themselves, which, ah, will give them 
> some time-to-market problems ;-).

Well, it wouldn't be hard to support an atomic command to do this. You 
just need to make sure you don't delete UNPROCESSED entries which might 
arrive while you are deleting them - I can think of at least 2 ways to 
do this [*].

> It might be clearer to add a new command to consolidate the entries, 
> rather than having a DELETE happen as a side effect of CREATE.  In that 
> case, we'd add the restriction that CREATing a BOOKED entry will fail 
> if there's an UNPROCESSED entry with the same UID.

I was about to agree with Doug (having the server delete the UNPROCESSED 
entries), but you do have a point here.
I guess it would be better if we had a command to consolidates entries. 
A server might not implement it; in that case, the client should 
fallback to deleting the entries by itself, and take the hint that it 
might not be safe to do that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Stracke | 2 Aug 2002 22:31

Re: Question


Andrea Campi wrote:

> I guess it would be better if we had a command to consolidates 
> entries. A server might not implement it;

Very bad idea--that would mean every client has to have code to do it 
both ways.

However, a server might not implement it *atomically*.

--

-- 
/=============================================================\
|John Stracke      |jstracke <at> centivinc.com                    |
|Principal Engineer|http://www.centivinc.com                  |
|Centiv            |My opinions are my own.                   |
|=============================================================|
|Q: What goes "Pieces of 7! Pieces of 7!"? A: A parroty error.|
\=============================================================/
Permalink | Reply | 0 comments |
headers
Andrea Campi | 2 Aug 2002 22:39
Picon

No comments on my proposals?


Hi all,

I received no answer to the proposals I made in my email of Jul 17 
(http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were they 
missed or do you feel they are not interesting?

Bye,
	Andrea
Permalink | Reply | 0 comments |
headers
Doug Royer | 2 Aug 2002 23:00

Re: No comments on my proposals?

Andrea Campi wrote:
> 
> Hi all,
> 
> I received no answer to the proposals I made in my email of Jul 17
> (http://www.imc.org/ietf-calendar/mail-archive/msg05880.html). Were they
> missed or do you feel they are not interesting?

See:

	http://www.imc.org/ietf-calendar/mail-archive/msg05975.html
Attachment (Doug.vcf): text/x-vcard, 378 bytes
Permalink | Reply | 0 comments |

Gmane