[VCARDDAV] XML extensions

Joe Hildebrand <joe.hildebrand@webex.com> Wed, 29 July 2009 10:02 UTC

Return-Path: <Joe.Hildebrand@webex.com>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0DD3A6EFA for <vcarddav@core3.amsl.com>; Wed, 29 Jul 2009 03:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 o0GrZZgy3VvM for <vcarddav@core3.amsl.com>; Wed, 29 Jul 2009 03:02:36 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id F161B3A6DB8 for <vcarddav@ietf.org>; Wed, 29 Jul 2009 03:02:35 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.198]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 03:02:36 -0700
Received: from 10.21.72.151 ([10.21.72.151]) by SRV-EXSC03.webex.local ([192.168.252.200]) with Microsoft Exchange Server HTTP-DAV ; Wed, 29 Jul 2009 10:01:43 +0000
User-Agent: Microsoft-Entourage/12.20.0.090605
Date: Wed, 29 Jul 2009 12:01:42 +0200
From: Joe Hildebrand <joe.hildebrand@webex.com>
To: vcarddav@ietf.org
Message-ID: <C695EAA6.10833%joe.hildebrand@webex.com>
Thread-Topic: XML extensions
Thread-Index: AcoQM5J1RP+uvlfOckqW4OcXgd5cAA==
IM-ID: xmpp:jhildebrand@corp.jabber.com
Presence-ID: xmpp:jhildebrand@corp.jabber.com
Jabber-ID: jhildebrand@corp.jabber.com
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 29 Jul 2009 10:02:36.0784 (UTC) FILETIME=[B31C6700:01CA1033]
Subject: [VCARDDAV] XML extensions
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2009 10:02:36 -0000

We talked about this on the bus last night after the WG meeting.

I'm fine with Pete's approach of a single extension point.  The winning
argument for me was that you would have to start a separate XML parser
instance for each field to go down the path I was thinking of.  The
suggestion would be:

EXTENSIONS;ENCODING=b;TYPE=text/xml:base64(xml)

(on the bus, we said "X-TENSIONS", but that was overly-cute)

Which would then turn into a single XML element <extensions/> that contains
all extended XML properties.  When the extensions element is encoded, it
must be turned into a full document, with an encoding processing instruction
(particularly if you're not encoding in UTF-8), and a namespace declaration:

<?xml version="1.0" encoding="UTF-8"?>
<extensions xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <my-extension xmlns='urn:example:foo'>
  </my-extension>
</extensions>

When the extensions element is decoded, the resulting infoset is inserted
into the vcardxml; this will have the side-effect of removing the processing
instruction and namespace declaration:

<?xml version="1.0" encoding="UTF-8"?>
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
  <fn><text>Simon Perreault</text></fn>
...
  <extensions>
    <my-extension xmlns='urn:example:foo'>
    </my-extension>
  </extensions>
</vcard>

The PI for encoding is important, but (as always in XML) it's odd that
really only the first two code points ("<?") are used to guess the encoding,
then the guess is double-checked with the encoding declaration is reached.

The extensibility language in vcardrev and vcardxml will need to be updated
to ensure round-tripability.  XML extensions will not solve the problem of
existing X- or VND- fields in the old format, and their mechanical
translation into the XML format.

-- 
Joe Hildebrand