Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09

Randy Bush <> Tue, 13 September 2011 21:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30B4821F8C4E; Tue, 13 Sep 2011 14:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.525
X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oVq78rJgP-bd; Tue, 13 Sep 2011 14:04:56 -0700 (PDT)
Received: from ( [IPv6:2001:418:1::36]) by (Postfix) with ESMTP id BC0AF21F8C4C; Tue, 13 Sep 2011 14:04:56 -0700 (PDT)
Received: from localhost ([] by with esmtp (Exim 4.76 (FreeBSD)) (envelope-from <>) id 1R3aC3-000CqK-8l; Tue, 13 Sep 2011 21:06:59 +0000
Date: Tue, 13 Sep 2011 23:07:00 +0200
Message-ID: <>
From: Randy Bush <>
To: Barry Leiba <>
In-Reply-To: <>
References: <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 14 Sep 2011 08:19:04 -0700
Subject: Re: [apps-discuss] apps-team review of draft-ietf-sidr-ghostbusters-09
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Sep 2011 21:04:57 -0000

>>> NEW
>>>   Per [RFC6350], the BEGIN, VERSION, FN, N, and END properties MUST be
>>>   included in a record.  To be useful, one or more of ADR, TEL, and
>>>   EMAIL MUST be included.  Other properties MUST NOT be included.
>> Actually vcard does not require the N property to be present, only VERSION
>> and FN in addition to BEGIN/END (as per
>> <>).
>> Note: vcard v3 used to require that N was present, but that requirement was
>> dropped in vcard v4.

i will probably drop unless you can explain to me the value it adds.

>> The "Other types MUST NOT be included." is perhaps a little strong. I can
>> certainly see situations where it might be useful to have other properties
>> such as SOURCE, KIND or REV present. Perhaps that can be changed to a
> It seems clear from the SIDR doc that they very much *want* a MUST
> NOT.  For their use case, it's not too strong; it's exactly what they
> want in order to keep this record simple.  They could certainly extend
> this later, allowing additional properties if such turn out to make
> sense for their use case.


we want to be brutally minimalist.