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

[Дилян Палаузов <[e-mail]>]

Hello Michael,

the ENHANCED GET is a way for one-direction synchronization.

I propose decoupling the Enhanced GET from iCalendar: defining an
universal Enhanced GET, that works with any files in directories.

The STATUS:DELETED value opens a can of worms.  Its presense in an RFC
will lead to having iCalendar objects with STATUS:DELETED in the wild,
outside the context of Enhanced GET.  The “STATUS:DELETED in the wild”
will be a result of the anyway voluminous, complicated to understand
iCalendar format with all its extension.  An Enhanced GET, which is not
related to iCalendar will avoid this and could be used also for other
formats.  (E.g. syncing between ftp serves, that serve content over
HTTP).

I think that ETag and Last-Modified are essentially the same and serve
the same purpose.  The only difference is, that the ETag has opaque
meaning and with Last-Modified one can know how stale a cache was.

The 8.4.  subscribe-webdav-sync option should be split into two: with
authentication and without authentication.  I think it is valid for a
server to return on WebDAV synchronization valid results, when the
client has authenticated and when the client has not authenticated, but
the results in both cases can be different.  To account for this, the
client shall know, whether it shall ask the user, if the user wants to
authenticate or not.  Without remembering now the details of the WebDAV
Synchronization protocol, on the URL:

https://mail.aegee.org/dav/calendars/user/cal

when PROFIND or REPORT are invoked, the results are different for
authenticated and not authenticated users.  To make the right request,
the WebDAV client must know a priori, whether it shall authenticate and
the subscribe-webdav-sync hint is insufficient.

If the presence of subscribe-caldav together with subscribe-webdav-sync
means, that the WebDAV-but-no-CalDAV-client does not need to
authenticate, this shall be spelt explicitly.  Likewise, if the
presensc of both subscribe-caldav-auth and subscribe-webdav-sync mean,
that the WebDAV client need to authenticate, this also must be spelled
out.


> > 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.
> 

I mean for the inspected URL, not for other URLs.

Greetings
  Дилян

On Tue, 2021-04-27 at 01:06 -0400, Michael Douglass wrote:
> 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.
> 
> 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 
> 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