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

Дилян Палаузов <dilyan.palauzov@aegee.org> Tue, 11 June 2019 19:51 UTC

Return-Path: <dilyan.palauzov@aegee.org>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3327112006A for <calsify@ietfa.amsl.com>; Tue, 11 Jun 2019 12:51:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzUg-vW7cOMe for <calsify@ietfa.amsl.com>; Tue, 11 Jun 2019 12:50:59 -0700 (PDT)
Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14212120176 for <calsify@ietf.org>; Tue, 11 Jun 2019 12:50:58 -0700 (PDT)
Authentication-Results: mail.aegee.org/x5BJotNm016786; auth=pass (LOGIN) smtp.auth=didopalauzov
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1560282656; i=dkim+MSA-tls@aegee.org; r=y; bh=WJoolw2ebrzlPGP9uYRM3XKfzd+UeY1Gh2WUxNNftMk=; h=Subject:From:To:Date:In-Reply-To:References; b=WM63i7dZ+MGXFF+BqRKxgOmN1a6t5MGo9BlsARd/egF+SKEWFZ5UpnarNb6R6k+B5 BV9mIWKkMU6W3LUcPMW7VszOZksthj6NZeBCw4om4wDH1m901CvS+FJQtswXfcgfBw kn/QQOFrbNIF3Fj08QsE+Z/BEepM7z9uJwu2r+a16hllgJZmsYFgQ1O63PvU2T7DCd UuBE6yuSq77YqyI4zEvbZ45vmcU6AtM1JGBrnFbgQ1zgUIhm5qmI/nTH+QlL+PJNVD e64nAHw9ZeX3bBVqNDvu5F0v8zfwm++aPS0Otb+nMl9I+NlGiJRJsUT9jKogOMh2Iq O+3/sdM1otrKH+ceFYwtBhuXf5qrZLHPOdRnxvUUFQbKU57rYF9d8Rj+To+AHbI+vT 4CICkiqayeU1UYz2mEikiCHMIDevhW5yNLbvulr6Tru8tVBWSCsk3wWIEd+9SDda3q 7xYXXpPKYJmhc/VYFHttrt+FVTaeJ4LIFnUOYykbp0nXm269ESaN5cZ+ejNNl4cggh KLpQpIfnIO5B1moUyDFORFi0f2xWosjtzRFVsYX9GXp67GpNxCw8JBUyxVRgzI25Co coYRzZQE+gdFJklcf4d+gfE1xxKXd6YQ7DjpnkDwcBbZVVpgZ9a8k11SZ545Ju2DRC VQ/52hlTwbiXL+Vr+dXoflzU=
Authentication-Results: mail.aegee.org/x5BJotNm016786; dkim=none
Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x5BJotNm016786 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for <calsify@ietf.org>; Tue, 11 Jun 2019 19:50:56 GMT
Message-ID: <d9c743552f1d93827694aceb66db5b2eefca850b.camel@aegee.org>
From: Дилян Палаузов <dilyan.palauzov@aegee.org>
To: calsify@ietf.org
Date: Tue, 11 Jun 2019 19:50:55 +0000
In-Reply-To: <155992219411.20220.15511434849780424587@ietfa.amsl.com>
References: <155992219411.20220.15511434849780424587@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.33.3
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/xz9wPb4zQbpeNfkCFAX6J7V7RFw>
Subject: Re: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-00.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2019 19:51:02 -0000

Hello,

this document does not talk about where the CUAs get the calendar feeds from, or how the CUAs can know, to which feeds a
user is subscribed.

One possible approach is to get the feeds from diverse web pages and keep then only on the client, while some servers
support the approach described at http://sabre.io/dav/clients/ical/#subscriptions .

My big question is:

A user gets a webcal URL, let’s say secured webcals://A/B .  Why doesn’t the client just do:

OPTIONS /B HTTP/1.1
Host: A

If the answer contains DAV: calendar-access, then apply the mechanisms from Calendaring Extensions to WebDAV (CalDAV)
RFC4791 and Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV) to get all data; get the
changes since the last synchronization; get only events after certain date…?

Otherwise call from time to time GET on the URL to get all the data.

Why there needs to be a different protocol for calendar subscription feeds, different from the regular calendar
transport protocols?

On another note, about VJOURNAL, https://tools.ietf.org/html/rfc5545#section-3.8.1.11 says for STATUS:

   Description:  In a group-scheduled calendar component, the property
      is used by the "Organizer" to provide a confirmation of the event
      to the "Attendees".  For example in a "VEVENT" calendar component,
      the "Organizer" can indicate that a meeting is tentative,
      confirmed, or cancelled.  In a "VTODO" calendar component, the
      "Organizer" can indicate that an action item needs action, is
      completed, is in process or being worked on, or has been
      cancelled.  In a "VJOURNAL" calendar component, the "Organizer"
      can indicate that a journal entry is draft, final, or has been
      cancelled or removed.

Possible value for VJOURNAL's STATUS: are DRAFT, FINAL and CANCELLED.

So the “cancelled or removed” stati above are both mapped to STATUS:CANCELLED.

However, the description above in the RFC does not say, that there is a status for removed in VTASK or VEVENT.

https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00#section-4.1 Redefined Status property contains
another:

   Description
      In a group-scheduled calendar component, the property is used by
      the "Organizer" to provide a confirmation of the event to the
      "Attendees".  For example in a "VEVENT" calendar component, the
      "Organizer" can indicate that a meeting is tentative, confirmed,
      or cancelled.  In a "VTODO" calendar component, the "Organizer"
      can indicate that an action item needs action, is completed, is in
      process or being worked on, or has been cancelled.  In a
      "VJOURNAL" calendar component, the "Organizer" can indicate that a
      journal entry is draft, final, or has been cancelled or removed.

There is no extra text to accomodate, that VEVENT and VTODO can also be “removed” ⇔ deleted.  “For example”
is not correct, as the text in the original RFC does try to describe all possible cases.  This shall be the intention of
the redefinition.

Regards
  Дилян


On Fri, 2019-06-07 at 08:43 -0700, internet-drafts@ietf.org 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-00.txt
> 	Pages           : 15
> 	Date            : 2019-06-07
> 
> Abstract:
>    This specification introduces an approach to allow subscribers to
>    calendar feeds to upgrade to a more performant protocol.
> 
>    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 are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-00
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-00
> 
> 
> 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
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify