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

Mike Douglass <douglm@rpi.edu> Sat, 10 July 2010 04:13 UTC

Return-Path: <calsify-bounces@ietf.org>
X-Original-To: calsify-archive-feit0ahl@lists.ietf.org
Delivered-To: ietfarch-calsify-archive-Feit0ahl@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FC6D3A68D8; Fri, 9 Jul 2010 21:13:17 -0700 (PDT)
X-Original-To: calsify@core3.amsl.com
Delivered-To: calsify@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59E03A6890 for <calsify@core3.amsl.com>; Fri, 9 Jul 2010 21:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level:
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfK-extY+GMT for <calsify@core3.amsl.com>; Fri, 9 Jul 2010 21:13:14 -0700 (PDT)
Received: from smtp7.server.rpi.edu (smtp7.server.rpi.edu [128.113.2.227]) by core3.amsl.com (Postfix) with ESMTP id B02C43A68D8 for <calsify@ietf.org>; Fri, 9 Jul 2010 21:13:14 -0700 (PDT)
Received: from [192.168.2.12] (cpe-24-92-49-115.nycap.res.rr.com [24.92.49.115]) (authenticated bits=0) by smtp7.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o6A4DFPa027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Jul 2010 00:13:16 -0400
Message-ID: <4C37F35B.2010107@rpi.edu>
Date: Sat, 10 Jul 2010 00:13:15 -0400
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b2pre Thunderbird/3.0.4
MIME-Version: 1.0
To: Tim Hare <TimHare@comcast.net>
References: <4C373FF6.30407@rpi.edu> <019601cb1fd6$beac0cc0$3c042640$@net>
In-Reply-To: <019601cb1fd6$beac0cc0$3c042640$@net>
X-RPI-SA-Score: undef - SENDER Whitelisted (douglm@rpi.edu: Mail from user authenticated via SMTP AUTH allowed always)
X-CanItPRO-Stream: outgoing
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.227
Cc: calsify@ietf.org
Subject: Re: [calsify] Fwd: New Version Notification for draft-douglass-link-extension-00
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: calsify-bounces@ietf.org
Errors-To: calsify-bounces@ietf.org

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.


On 07/09/2010 10:22 PM, Tim Hare wrote:
> 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.
>
>
>    

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify