Re: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-03.txt

[Michael Douglass <[e-mail]>]

Sorry - looks like I missed this...

On 2/22/21 13:03, Дилян Палаузов wrote:
> Hello,
>
> my messages to [e-mail] about draft-ietf-calext-subscription-
> upgrade from 6th October 2020 are not tackled yet.
>
> These were also not addressed in draft-ietf-calext-subscription-
> upgrade-03 .
>
> I am against introducing STATUS:DELETED, as I do not see how it dяffers
> from STATUS:CANCELLED.

They are different:

STATUS;DELETED is equivalent to a 404 status - the event simply doesn't 
exist. In the context of this draft it means it was actually deleted 
from the server since the last time we checked. What a client chooses to 
do at that point is up to the client.

STATUS:CANCELLED is just that - the event is still out there, it's been 
marked as cancelled and should be displayed to the user as such.

A STATUS:CANCELLED event will reappear if it's changed in any way. A 
STATUS;DELETED will (should) never reappear - it's gone.

Certainly a client may choose to display a deleted event as cancelled 
but that's a different issue..

Also the 'client' may not be displaying anything - it may be an 
aggregator passing events along. It needs to know that an event is gone.


>
> About draft-ietf-calext-subscription-upgrade-03:
>
> Section 2 Introduction:
>
>>     The only available option for updating that resource is the usual
> HTTP polling of cached resources using Etags.
>
> Is Last-Modified interchangeable with ETags?
I guess I should just remove the reference to Etags. CalDAV only 
references ETags. Last-Modified might be an options in other protocols.
>
>> The use of subscription upgtafe may help reduce
> typo.
fixed.
>
> 4.2.  Deletions
> What purpose does delivering skeletons, empty deleted items?
To provide a valid parseable component. Stripping out all the possibly 
large properties reduces the size
>
>> The receiving client is free to remove the entity or update it's
> STATUS property.
> It's → Its.
Fixed
>
> 5.1.  Redefined Status property
> This section is not adjusted for the DELETED value: the included
> examples have no added value.

And I'm not sure now if I should have done this as a full redefinition. 
I think the text should have been more along the lines of just defining 
a new value.

I can add an example as well.

>
> 8.2.  subscribe-caldav
>> for example to determine if sync-report is supported.
> Please spell DAV:sync-collection report, as the report is not called
> literally “sync-report”.
Done
>
>> The URL MAY include some form of token to allow write access to the
> targeted collection.  The client must check it's permissions to
> determine whether or not it has been granted write access.
>
> I do not get this “token may be included” part.  Can you provide
> example what this is supposed to mean?
It's entirely up to the server- it may wish to provide a unique token as 
part of the url - given the following section this may not be necessary.
> It's → its.
Done
>
> 8.4.  subscribe-webdav-sync
> Does it require authentication or not?  What is the opposite option?
It only supports DAV:sync-collection but that doesn't preclude a 
challenge for authentication.
>
> I propose:
> - determine using OPTIONS call, whether WebDAV/CalDAV are supported
> - comminucate over GET whether authentication is
> necessary/optional/disabled.

Some services choose to place their subscriptions on a different service 
to their caldav service. An OPTIONS call would not reveal any possible 
alternative. The point of this spec is to allow service providers to 
redirect clients to any other service that provides a better protocol.

For example the subscribed collection may be stored as a static file 
updated periodically by the service.

I'm not sure what you mean by using GET.

Some services only challenge when an operation is attempted that 
REQUIRES authentication - e.g. a PUT. I don't agree with that approach 
but it's out there. The downside of that approach is that queries may 
return different results before and after authentication. This spec 
allows the service to provide the location of an authenticated end-point 
if it differs from the unauthenticated one.

We could provide some sort of capabilities document but that's a whole 
other spec. https://tools.ietf.org/html/draft-douglass-server-info-03

>
> Greetings
>    Дилян
>
> On Mon, 2021-02-01 at 14:12 -0800, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Calendaring Extensions WG of the IETF.
>>
>>          Title           : Calendar subscription upgrades
>>          Author          : Michael Douglass
>>          Filename        : draft-ietf-calext-subscription-upgrade-03.txt
>>          Pages           : 15
>>          Date            : 2021-02-01
>>
>> Abstract:
>>     This specification updates [RFC5545] to add the value DELETED to the
>>     STATUS property.
>>
>>     This specification also updates [RFC7240] to add the subscribe-
>>     enhanced-get and limit preferences.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/
>>
>> There is also an HTML version available at:
>> https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-03.html
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-03
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> calsify mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/calsify
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify