[Jmap] Gunter Van de Velde's No Objection on draft-ietf-jmap-contacts-09: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Thu, 23 May 2024 08:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D154C14F6BC; Thu, 23 May 2024 01:46:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171645398129.23262.2685990357749123472@ietfa.amsl.com>
Date: Thu, 23 May 2024 01:46:21 -0700
Message-ID-Hash: ZKXSCWKLHAQVG63VBYSN7PUWTGZ5R4QF
X-Message-ID-Hash: ZKXSCWKLHAQVG63VBYSN7PUWTGZ5R4QF
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-jmap-contacts@ietf.org, jmap-chairs@ietf.org, jmap@ietf.org, fenton@bluepopcorn.net
X-Mailman-Version: 3.3.9rc4
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [Jmap] Gunter Van de Velde's No Objection on draft-ietf-jmap-contacts-09: (with COMMENT)
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Owner: <mailto:jmap-owner@ietf.org>
List-Post: <mailto:jmap@ietf.org>
List-Subscribe: <mailto:jmap-join@ietf.org>
List-Unsubscribe: <mailto:jmap-leave@ietf.org>

Gunter Van de Velde has entered the following ballot position for
draft-ietf-jmap-contacts-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-contacts/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for draft-ietf-jmap-contacts-09

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/
documenting the handling of ballots.

#GENERIC COMMENTS
#================

191        *  *isDefault*: Boolean (server-set)
192           This SHOULD be true for exactly one AddressBook in any account,
193           and MUST NOT be true for more than one AddressBook within an
194           account.  The default AddressBook should be used by clients
195           whenever they need to choose an AddressBook for the user within
196           this account, and they do not have any other information on which
197           to make a choice.  For example, if the user creates a new contact
198           card, the client may automatically set the card as belonging to
199           the default AddressBook from the user's primary account.

What if none is set true? will there then be a random selected at default?
is there a mechanism or desire to make such selection deterministic?

201        *  *isSubscribed*: Boolean

203           True if the user has indicated they wish to see this AddressBook
204           in their client.  This should default to false for AddressBooks in
205           shared accounts the user has access to and true for any new
206           AddressBooks created by the user themself.

208           If false, the AddressBook and its contents should only be
209           displayed when the user explicitly requests it or to offer it for
210           the user to subscribe to.

is there a reason why this section does not use [RFC2119] [RFC8174] language?