[Ietf-carddav] charter comments

Marc Blanchet <marc.blanchet@viagenie.ca> Thu, 26 July 2007 22:20 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: ietf-carddav@osafoundation.org
Delivered-To: ietf-carddav@osafoundation.org
Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by leilani.osafoundation.org (Postfix) with ESMTP id 5F91380614 for <ietf-carddav@osafoundation.org>; Thu, 26 Jul 2007 15:20:01 -0700 (PDT)
Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 6CF82142203 for <ietf-carddav@osafoundation.org>; Thu, 26 Jul 2007 15:19:06 -0700 (PDT)
X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org
X-Spam-Score: -2.503
X-Spam-Level:
X-Spam-Status: No, score=-2.503 tagged_above=-50 required=4 tests=[AWL=0.096, BAYES_00=-2.599]
Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GdtxfecG6cV for <ietf-carddav@osafoundation.org>; Thu, 26 Jul 2007 15:19:04 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [206.123.31.2]) by laweleka.osafoundation.org (Postfix) with ESMTP id B861F142201 for <ietf-carddav@osafoundation.org>; Thu, 26 Jul 2007 15:19:04 -0700 (PDT)
Received: from [130.129.20.201] (dhcp-14c9.ietf69.org [130.129.20.201]) by jazz.viagenie.ca (Postfix) with ESMTP id 0376829E1360; Thu, 26 Jul 2007 18:19:03 -0400 (EDT)
In-Reply-To: <D97FBA56-19CB-439F-A78B-A9F41898AA04@wsanchez.net>
References: <4699F52B.10101@gmx.de> <DA70918551A4706E579F3829@caldav.corp.apple.com> <469B8745.7030805@gmx.de> <79F2A71D-2D97-4EE2-8900-B095A16DB935@greenbytes.de> <469B960C.7080905@gmx.de> <D97FBA56-19CB-439F-A78B-A9F41898AA04@wsanchez.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <64029A6F-FACF-479A-85BB-930CDFF4D626@viagenie.ca>
Content-Transfer-Encoding: 7bit
From: Marc Blanchet <marc.blanchet@viagenie.ca>
Date: Thu, 26 Jul 2007 17:18:59 -0500
To: ietf-carddav@osafoundation.org
X-Mailer: Apple Mail (2.752.3)
Cc: Chris Newman <chris.newman@sun.com>
Subject: [Ietf-carddav] charter comments
X-BeenThere: ietf-carddav@osafoundation.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-carddav.osafoundation.org
List-Unsubscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=unsubscribe>
List-Archive: <http://lists.osafoundation.org/pipermail/ietf-carddav>
List-Post: <mailto:ietf-carddav@osafoundation.org>
List-Help: <mailto:ietf-carddav-request@osafoundation.org?subject=help>
List-Subscribe: <http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-carddav>, <mailto:ietf-carddav-request@osafoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jul 2007 22:20:01 -0000

my comments on charter sent by Chris (http://www1.ietf.org/mail- 
archive/web/discuss/current/msg00600.html)

...
This includes:
<MB>
An example from a customer of ours, if this may be useful to the  
charter.
* A contact database service used for sales management, where  
multiple users may access and change contacts in the database
</MB>
...

This WG will produce the following two primary outputs:

* A revision of the vCard spec (RFC 2426) likely at proposed standard
  status.  The WG will attempt to avoid adding new features, with two
  exceptions: 1. The WG may consider including other proposed  
standard vCard
  extensions (e.g., RFC 4770, RFC 2739).  2. The WG may evaluate  
extensions
  that would assist synchronization technologies (for example, a per- 
entry
  UUID or per-attribute sequence number).
<MB>
3. The WG should define a way to properly handle extensions with a  
possible central registry in an extension name space.
</MB>

* An address book access protocol leveraging the vCard data format.  The
  Internet-draft draft-daboo-carddav will be the starting point.
  The WG is explicitly cautioned to keep the base specification  
feature set
  small with an adequate extension mechanism, as failure to do so was a
  problem for previous PAB efforts (ACAP).  The WG will consider  
arguments
  of the form "feature X must be in the base feature set because ..."
  with great skepticism.


These documents will consider security implications carefully.
<MB>s/carefully//</MB>

...

<MB>
Should we have a requirement document to start with?
</MB>