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