Subject: [calsify] Fwd: New Version Notification for draft-douglass-link-extension-00

From: Mike Douglass <[email-masked]>
Date: Fri, 09 Jul 2010 11:27:50 -0400

Last week I submitted the first draft of a proposed extension to 
iCalendar - a LINK property, closely aligned to the proposed link header -

http://tools.ietf.org/html/draft-nottingham-http-link-header-10

-------- Original Message --------
Subject: 	New Version Notification for draft-douglass-link-extension-00
Date: 	Wed, 30 Jun 2010 12:51:48 -0700 (PDT)
From: 	IETF I-D Submission Tool <[email-masked]>
To: 	[email-masked]

A new version of I-D, draft-douglass-link-extension-00.txt has been successfully submitted by Mike Douglass and posted to the IETF repository.

Filename:	 draft-douglass-link-extension
Revision:	 00
Title:		 Link Extension to Icalendar
Creation_date:	 2010-06-30
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
This specification introduces a new iCalendar property LINK to
provide ancillary information for iCalendar components.

The IETF Secretariat.

_______________________________________________
calsify mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/calsify

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 9 Jul 2010 22:22:28 -0400

Questions:  

1. Why LINK REL=CAL_(ACTIVE/INACTIVE)_PARTICIPANT  rather than proposing ACTIVE / INACTIVE as possible values for the PARTSTAT parameter on an ATTENDEE property of a component?
2.  Several, if not all, properties allow URIs as values or URIs can be specified in the ALTREP= parameter (for example, LOCATION).  What advantage would the LINK property have over these schemes?

I'm not criticizing the proposal per se, but I'd like to understand what it's advantages are and what problems it solves that don't have a solution in RFC 5545.

Tim Hare
Interested Bystander, Non-Inc.

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 9 Jul 2010 22:22:28 -0400

Questions:  

Tim Hare

---

From: Mike Douglass <[email-masked]>
Date: Sat, 10 Jul 2010 00:13:15 -0400

Attendees and Organizers are not valid on non-group scheduling events. 
One common invalid event we see when importing events are attempts to 
set those properties.

As event publishers we have a strong need to indicate who is organizing 
the event and who are participants, for example a baseball team or their 
parents.

Even for real group scheduling, the altrep parameter doesn't allow us to 
specify the type, e.g vcard, html etc nor does it allow us to specify 
multiple variants of the same information.

Locations are a typical case and indeed where this all started. altrep 
is allowed but only once. In event publishing especially, it is 
important to have rich location information in a form clients can 
download and display or use to guide people to their destination. Vcard 
seems a good choice for this but clients need to be able to determine 
that the reference is indeed for location information and is in a form 
they can process.

We also have a need to link to other information that is not covered by 
current rfc5545 properties but is vital to event publishers, sponsors 
for example. Event organizers also have a need for a standard way to 
link back to pages that provide access to media, for example video feeds 
or directly to that video feed.

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Mike Douglass <[email-masked]>
Date: Sat, 10 Jul 2010 00:13:15 -0400

--

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 10 Jul 2010 09:40:09 -0400

Thanks that clears it up somewhat. For your first point - I believe 'large attendance' events like concerts, theater, etc. are, technically, group scheduling events and could be scheduled as such but I see the advantages to your method now, when I didn't before.  I think, coming from my particular background, I can get hung up on the appointment / meeting view of calendaring and forget things like events and conferences.

Now after reading this a second time, a couple of other things:

1. You require 'fmttypeparam' on a LINK property, but it's not described in the document.  TYPE= is used in examples, but TYPE isn't defined like TITLE is.
2. Personal opinion, maybe, but I think NAME= is a more generic, and therefore more generally applicable, thing than TITLE= 
3. IF TYPE= uses MIME types, then I would think for your media feeds it would be better to have REL="MEDIA" (or something like it) and allow TYPE= to determine the type. MIME types are already used in many places to determine what will process a file, and I think most clients would already have functions to do so. I don't think it an undue burden on things to search for REL=MEDIA AND TYPE="whatever".

As always these are one man's opinions, offered in the spirit of "let's get calendaring to where everyone can use it".

Tim Hare

---

From: "Tim Hare" <[email-masked]>
Date: Sat, 10 Jul 2010 09:40:09 -0400

Tim Hare