Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-04.txt

From: [email-masked]
Date: Tue, 10 Oct 2017 15:47:51 -0700

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           : Event Publishing Extensions to iCalendar
        Author          : Michael Douglass
	Filename        : draft-ietf-calext-eventpub-extensions-04.txt
	Pages           : 30
	Date            : 2017-10-10

Abstract:
   This specification introduces a number of new iCalendar properties
   and components which are of particular use for event publishers and
   in social networking.

   This specification also defines a new STRUCTURED-DATA property for
   iCalendar [RFC5545] to allow for data that is directly pertinent to
   an event or task to be included with the calendar data.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-04
https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-04

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/

---

From: Michael Douglass <[email-masked]>
Date: Tue, 10 Oct 2017 19:04:08 -0400

There are 2 issues to be resolved.

Resource type registry.

When this spec was started it was thought that such a registry would 
appear as part of the vcard work. This hasn't happened. So either we 
define one in this spec or find another one (haven't found one so far).

SOURCE property

Turns out this is already defined in RFC 7986. That version is more 
restrictive than the one defined here. So either we have a new property 
or redefine that in 7986 to allow its use in any component. Also this 
spec allows VALUE=TEXT and the fmttype parameter. I've also just 
realized the example is incorrect.

On 10/10/17 18:47, [email-masked] wrote:
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Daniel Migault <[email-masked]>
Date: Tue, 10 Oct 2017 21:52:07 -0400

I have no strong opinion, but maybe redefining one and adding text that
explains why we do not reuse RFC 7986 makes it easier.

On Tue, Oct 10, 2017 at 7:04 PM, Michael Douglass <[email-masked]>
wrote:

> appear as part of the vcard work. This hasn't happened. So either we define
> one in this spec or find another one (haven't found one so far).
>
> SOURCE property
>
> restrictive than the one defined here. So either we have a new property or
> redefine that in 7986 to allow its use in any component. Also this spec
> allows VALUE=TEXT and the fmttype parameter. I've also just realized the
> example is incorrect.
>
>
>