Re: [VCARDDAV] Signed vCards

DataPacRat <> Mon, 15 July 2013 17:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48C3411E811B for <>; Mon, 15 Jul 2013 10:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a3S3qQVFHyhK for <>; Mon, 15 Jul 2013 10:01:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::232]) by (Postfix) with ESMTP id 40A1111E8194 for <>; Mon, 15 Jul 2013 10:00:55 -0700 (PDT)
Received: by with SMTP id k14so10357593wgh.17 for <>; Mon, 15 Jul 2013 10:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dvffDAioc0fbkwYQxilpHbCPCaCKsovr7rplySr2dCk=; b=SYw4UBNXplZHXfFU7zqxch26shUQXtHULCEQ5sdLAmSh/ofubHLhFCSvbwKI+Isv+B i/i3B+l0ypuXnfthJNxMyCtMqwxV9scSCPrMu2uUU/b/0au/BBvFVHT+8pfCWLrt6XAB hTxy9Tljofs3c9e4/3SYne1F83POJsQ3cDJei7PHaKAJvOhFRUywXXM1yuCcZi53Ibao mXn8E0g3Vk2he/5SlrjQ1DXHQXvEIEDB6Dl9UB0ABLfEsdAwIjUUahAYgR6ar0CnOmjW ng4i3OPZ0nNBD1NpVrZ6gQM99rjsYNtpC2a+VbhFYUP1p3mfaBsTB/gLK7RtL1c2hWP3 MuPQ==
MIME-Version: 1.0
X-Received: by with SMTP id iy10mr8421362wic.29.1373907651348; Mon, 15 Jul 2013 10:00:51 -0700 (PDT)
Received: by with HTTP; Mon, 15 Jul 2013 10:00:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Mon, 15 Jul 2013 13:00:51 -0400
Message-ID: <>
From: DataPacRat <>
To: Eliot Lear <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>
Subject: Re: [VCARDDAV] Signed vCards
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Jul 2013 17:01:34 -0000

On Sun, Jul 14, 2013 at 12:28 AM, DataPacRat <> wrote:
> After some thought, there does seem to be at least one use case where having
> CONFIDENCE fields for any vCard property may be troublesome: when the
> confidence level is below 50%, and when the software reading the card isn't
> specifically design for vCards.
> One of the handiest things about vCards is that no matter which version is
> being used, it's fairly safe for a piece of reader software to simply ignore
> any tags or fields that it doesn't understand. However, a signed vCard
> written to revoke an association with an ID string, such as by using a DATE
> field with a low CONFIDENCE field, could break this; as the card is
> expressing the opposite of a piece of identity, but ignoring the unknown
> fields could lead a piece of software to conclude the opposite.
> I'm not sure that it's possible to easily resolve this issue, since dealing
> with such complicated identities is the whole point of my proposal. As a
> first thought - would it help to adjust the version number for signed
> vCards, such as from "4.0" to "4.0s"?

In case anyone's interested, my current working draft reads:

A vCard which is compatible with the signed vCard extensions MAY add
an 's' to the version number.
A vCard which uses any of the signed vCard extensions SHOULD add an
's' to the version number.
A vCard which uses a negative number in the CONFIDENCE property (ie,
has a confidence of under 50%) MUST add an 's' to the version number.

Thank you for your time,
"Then again, I could be wrong."