Re: [calsify] Fwd: New Version Notification for draft-douglass-link-extension-00
"Tim Hare" <TimHare@comcast.net> Sat, 10 July 2010 02:22 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 5BF563A6984; Fri, 9 Jul 2010 19:22:32 -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 81F0D3A6984 for <calsify@core3.amsl.com>; Fri, 9 Jul 2010 19:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 TWHvf8IVPPdY for <calsify@core3.amsl.com>; Fri, 9 Jul 2010 19:22:30 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 20A623A6989 for <calsify@ietf.org>; Fri, 9 Jul 2010 19:22:30 -0700 (PDT)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta07.westchester.pa.mail.comcast.net with comcast id g22V1e0040QuhwU572Ncbs; Sat, 10 Jul 2010 02:22:36 +0000
Received: from THARE ([71.203.98.77]) by omta02.westchester.pa.mail.comcast.net with comcast id g2Nb1e00M1gAkVz3N2Nc3P; Sat, 10 Jul 2010 02:22:36 +0000
From: Tim Hare <TimHare@comcast.net>
To: 'Mike Douglass' <douglm@rpi.edu>, calsify@ietf.org
References: <4C373FF6.30407@rpi.edu>
In-Reply-To: <4C373FF6.30407@rpi.edu>
Date: Fri, 09 Jul 2010 22:22:28 -0400
Message-ID: <019601cb1fd6$beac0cc0$3c042640$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acsfe0/FI195n34lTfOwq/xIutjS4gAWaKRg
Content-Language: en-us
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: calsify-bounces@ietf.org
Errors-To: calsify-bounces@ietf.org
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. _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify