From nobody Thu Apr 27 23:59:51 2023 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FD6C137395; Thu, 27 Apr 2023 23:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTjbBBd7Sb0c; Thu, 27 Apr 2023 23:59:44 -0700 (PDT) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20721.outbound.protection.outlook.com [IPv6:2a01:111:f403:7010::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4490EC1519B5; Thu, 27 Apr 2023 23:59:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KZp/s6iVsy54LYY+qhW9PblRQ0qdPm/8b/xc7YIbD6jzSvA+fWfBox3pe+MmbxZm52JHq5w0KMM/kMmFGNIm0cmrcX68pVoJBOP4ZUUIYyxLEhalmW1ZsepKLXKeJGqU4bVn+zWPc8nBHw2MZZYFDNDcMpLZLsaGDf1/9mheKHsIoaCsM+J92IHqdb/x2VwRAKfiuJN/WAnl22qzQnc5g3CC/+ydN1c/bfYyxNL5NPO5q3dU4l7i+CrzGOOL4shgSBu2ctjOSeuh+7hTqHpj3/H2f8pUxVJZ/IqbncufCjDf2kn+ZlGiHWKFiuXn0LsqOJ4+B2G5MxHrazasvLboGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=sXWcSL3ybl3ppnhhtVnzmhPM/tBsGbkTHwo3Ui1tOcw=; b=HGXKCrY+HlA/WY7nWF8X/ECkrSwxE8Z1xYpQSmEtKppLXebAFq2EqJ0crtcCxPk3BSdjaiRwK1F4O1iAcgqZkM0S6br2JmOMMYyClzNrftL65PmMpFN2763eugyqWR1EYAtElvTZoMK8fcKVWRnlHTojr2+BKMW2ajjknuWn7E6cRWo6ypBrMMSTh63aldZ2OTR6y8B5R1TSu638cPmvh4AyMXJxkHj3PjgUxnoFJiCqOinMtKKNJScyCw1HogQuES+ZbJ7Br+xEX0T1i690FyC/0RwwAChRbP6jNqLk67Zem/P+w7+PeXejcj84f+6ndqLq9kI1YXFc0/oaRt/PvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sXWcSL3ybl3ppnhhtVnzmhPM/tBsGbkTHwo3Ui1tOcw=; b=UT6zCvdhILCpSaCOPFRomfJ3ywJ84HW9PY8YRXiaR+aMdeECf+soZd9tOnfUGJAF+0BzqdXOA6ru5G3SLuiD+rZgcNt8zLA+3TCNZAdiDDGd9g8QHsy0qZmZZbHhIsEENrhtT/aeIeM5Zdb+mkJ3ZAcFHVDMUILSRq8Guyy9d2E= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB9844.jpnprd01.prod.outlook.com (2603:1096:400:20b::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.23; Fri, 28 Apr 2023 06:59:37 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::29a4:16ca:2bec:36d1]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::29a4:16ca:2bec:36d1%6]) with mapi id 15.20.6340.023; Fri, 28 Apr 2023 06:59:37 +0000 Message-ID: <38a0ec96-132c-2f35-f5f2-1080da8f1f17@it.aoyama.ac.jp> Date: Fri, 28 Apr 2023 15:59:35 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: art@ietf.org Cc: calsify@ietf.org, draft-ietf-calext-jscontact.all@ietf.org, last-call@ietf.org References: <168207023641.10169.13335976589846153291@ietfa.amsl.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <168207023641.10169.13335976589846153291@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCP286CA0322.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:3b7::11) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYAPR01MB5689:EE_|TYCPR01MB9844:EE_ X-MS-Office365-Filtering-Correlation-Id: ca689153-00aa-46dc-f134-08db47b6211d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9bXKPpPFtk6No4WQWL171JIwZw0JvJ/RrOOzPtDRholUiLR4bSvYLNnVb9MqdUJJTLyAYx+GD9fYpnauwK7Ks5QzhpN1QCvadIkkeWlOdZykpnHPZPWoSVgR2MRurnXXprUx0pDPxZ8l5sSXo625rD28S0H6UYFIHQuVt2lRNRMAqnhXyCr1KRmCThUeu/QPQ6R4NY+lNJwxQRNK20BVtz7hO879Dofv4RXZFg8f1Z3pKSj7PSmD2ukmUk94JKHntiFWjifyTfv+7N7vFPrLSgPX96fGSUMOLAbO/AxKZiR13BSYK4A9ZY6mKpgTXELtlJAXMDNSrg//hkXhjpaVgJdCwB51uX0ipGMyaLhvOwPSf1+3PGoo7+iYPijBt5EbXnBNloUrSVVxUQ95jG6JWyxTNbH/03B6fqsgfDx+BOQuKWWL+P+zg0NTq6Mg9SwvmT1VPAcWSJgqQjuJyoxAkdCeGTbrfxJ/BOKZggZLLOCdhzcasI4kbf2FsGy5ULgzix2XWwcSVnyn0N8Vm6v+gUHzB03whg98QyJxmASuP0agJoGMvQLobXoW1IPYFLKOOhAQ1cmfcUvhcdLAJEqsgX9VgPmDo+7kcLQdi5S2N7VCOkUQwvbf0fwF4oHJqkj32olzlGqzVi1usAkF8k4+m/ZF27WMxxMl1jyd63712y0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(346002)(396003)(136003)(366004)(39850400004)(376002)(451199021)(8936002)(8676002)(5660300002)(83380400001)(66476007)(66556008)(66946007)(316002)(786003)(4326008)(41300700001)(38100700002)(38350700002)(450100002)(31686004)(2616005)(66574015)(66899021)(36916002)(30864003)(2906002)(6916009)(478600001)(86362001)(53546011)(52116002)(6512007)(31696002)(26005)(186003)(6506007)(41320700001)(6486002)(966005)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SlRLaXVmZnQrcmtxdm9DR3FrNzAyWks1d1J5RjRkQ3pTUWhxczVVTlpab3B0?= =?utf-8?B?STM2OXA1WkFiS0lWRkhXZGVUbEU0M2RINlpkVHNiOGlPbGw3TmVtemdrTzlD?= =?utf-8?B?MjZpSUxRT21uZ1VTNUVWMWZSdjRmUTVsQlQyNFJhc2JPUzNqN2pMSGNYR080?= =?utf-8?B?bXI5UTNJWXVmMFJmS2hCY2dIdE5PLzdVd010YUl5RGhtbitEWEd1blc4TEF4?= =?utf-8?B?TTE3amQ3cFAwRXR1bmFpNmpEd09XWnBtbGQ3bGp1VFhjcVpVaW9RVlllSnlJ?= =?utf-8?B?MWtsTkc0dUhMaEZnQ0p2NGIvRStVNVl6N2N6N3dJR3k5eTVuYlRTWWE1SlR4?= =?utf-8?B?NTJka3RoWC9hMzQ5cnlyMFd2cUI3dDU0Mnk0bXVzZEJJTXNJR2NLRUlHQU5j?= =?utf-8?B?cEI1eDN2VWdpQWRlMmtlUW84UjBzcVozTkZ4MWhNMnZnQkMyVk1CdUdBNUlZ?= =?utf-8?B?WG12cEFCQTZqTlJiYWRWTkgwTk9xVHJ6Um9GbFVNY3I2cUYrdGFqZjdMZGhV?= =?utf-8?B?S3BYSDhHUFpBQkxjQW5sU2luL240dnluTTJXR2lXRy9UaXRQYlNSOVRXY1VP?= =?utf-8?B?TWNjcVNkMElZbnFHeWhQTmpKZFF1QVM3aWwrbExGYldGWnZ5Qm41ekU3bVRB?= =?utf-8?B?cnZaSjVKUTVCWmV0K2hPayszdUsyRm1hZFVDaDNkVVUrY1VmZFhhY2c1T1NR?= =?utf-8?B?OUlTQ21RbjVpdytabDB4OTNoZVU2WUhBaTIvT1Iyais5QlZPVGdUZURFOEFH?= =?utf-8?B?cnpDYVJGMDIzL3BKQW01bHBlZ0t2VmlKQ3V5b2lmYWUwZVY5bjFSS1ZlbE5n?= =?utf-8?B?aHlXeldNNHlDa0lsUDltUHVPbzVxOXAzaXdKM0lPa3N2Ri9IeG9wd0gzUS9W?= =?utf-8?B?VkpSWC8wNVE1SDFWR3RqOWkyWm1aL3h3VHpuZEtmcUlaNXBhM1gxUkNjTHdl?= =?utf-8?B?NUQ5NDFYYjhPd1NpMDNxNGpxOFA2ZWFFeld6U0Q2QzJuWTNHK0EyRXAxUmd0?= =?utf-8?B?QVUxNEErenNCdCtxTDlSQ2k1cWk0RjV1dm4xSXpyVVFVRGh4UWVKMWVwNU5u?= =?utf-8?B?QnJ0bEtjdjlRZUNaeUpRbTEvOWowR0c4RGxzWXlxMkV2SW5hYkVhc3ZRMThs?= =?utf-8?B?ZzIrZ2lBVUZ6R0pOb0ljZDU1b0doWkFXMXlUTU1wQmV6SzFqUGdjU0lwTUx1?= =?utf-8?B?ZUc2ZHpJVnZ6NElGWDRJVUJRbEZtTC9pY2RrM0k4K3N2SlFENXdPajNIdFlJ?= =?utf-8?B?S0laU3VHcUR2OXV0QVFTazd1b0RTYjR3ckpMbGJhdmZZaWR4L3laMG5hZXpJ?= =?utf-8?B?NjAwZEVLSUdwVmdkNGFIVzN1MnprWjVpbFZlUTRyNTRzTU1PdE9Zdk5zT2da?= =?utf-8?B?SWYydzhMWW9WYjU0d2NSUHVEdFArQXdsK3RrVWJ4NTRobi9raG14amJKM0x1?= =?utf-8?B?bW9FbG5haTJFcW1BcmNwUnJTdDBXdi9VUjRxdCtwUGY4VUE1ZTVkZ2FhUFNk?= =?utf-8?B?RFpkNHJuMDRvd2NrY1NrRTRHcUhONkpVRTQvTTJCQnZtRUVTS1JhYWE2ZTNF?= =?utf-8?B?UFlMTlhSVHVZZ1d2Unp4UHVOZEN1L2F4RVFxL1BsbTBGMk5WSjJ1UXFGbStC?= =?utf-8?B?Z21yZU43YzBMZ05vcDg0QVRXYk5VTXMvbEpBUjlOa3RxM0IrQUhlU1JaVnI4?= =?utf-8?B?bS93VmExVWJocFlrNUhDa21kZWRocUdDSW1OSVdBZC9wZzRsM2x3NkdwRHE0?= =?utf-8?B?cGNRUlZFeG5nTDhHZ05hcmUyZHBtV0x6bGtsUWlQWG5wYXROSWJXcW1ueDl6?= =?utf-8?B?REs4eldvRHRLWXFZTVdXRHpKRStSbENVRWxXaHR5VHZlUm1BVEExNHFLV1JO?= =?utf-8?B?dG55R3JOZ3hQTGx2SjljalVOUndUVDhWdWFOUjU1cVRueUQ0RmxWWk8rQ3dU?= =?utf-8?B?cUl2M0w5Y3liUHB2Q1Fib0JwSnJRcEZhQWNnOWNUL0NRTjkveitySGZDSGdD?= =?utf-8?B?dWRCY0o3d0JxeXlqQnNIMjJvamNXN1lrOFVFMDE5Zmxxbjl4bHUvQ3pPR3VL?= =?utf-8?B?Qk53dzY3UnB6R3RXdFBTdFFrTlBtLy9KblJ4cEhZMVdUSDh3cmdQT2pwdmVG?= =?utf-8?Q?Hak4IrAuW2nmKpvoP/7huPeNz?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: ca689153-00aa-46dc-f134-08db47b6211d X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2023 06:59:36.9682 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: WOCeJS+vF8vx8Mhm6aQVvxzD1vhNg3czc0GJkxY8r+yVv0oqwnLT7xUQXXtOch8rHQOqhjwzvd5Lk+wIXKJNgA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB9844 Archived-At: Subject: Re: [calsify] [art] Artart last call review of draft-ietf-calext-jscontact-07 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2023 06:59:48 -0000 Sorry, but there is one additional issue (major) that I forgot to mention in my review: The effort for registration at IANA is considerable. It looks to me as if the larger part of these registrations could be replaced by some kind of schema. I'm not familiar with schemas for JSON, but I have heard about some of them. What should be remaining for IANA registrations are extensions at the predefined extension points. Regards, Martin. On 2023-04-21 18:43, Martin Dürst via Datatracker wrote: > Reviewer: Martin Dürst > Review result: Not Ready > > Summary: The document isn't ready for publication. > > [This is essentially a *really* hard problem (*). If some of the issues > raised below are not addressed, they should at least be clearly > documented. > > (*) I know several people close to the Unicode consortium who have worked on > these issues; they essentially never thought they were done :-(] > > [version reviewed: mostly -07, to some extent checked against -10] > > Major issues: > > - The format uses @type (and probably @version) in a way very similar > to JSON-LD (to the extent that somebody at IETF 116 told me it was > JSON-LD), but at least the fact that @context is missing seems to > strongly indicate that it's not JSON-LD. The idiosyncratic way > data is arranged in the format, often with way more levels than > what a straightforward design might produce, would be much easier > to swallow if the document clearly indicated what kind of general > conventions it used, and how these conventions were similar and > different from more well-known conventions (such as JSON-LD). > Of course, even better that just documentation would be to fix > things so that the format isn't idiosyncratic, but uses well > established and documented conventions. > > - It says (at the start of Section 1) that this is an alternative to > vCard (and xCard and jCard). It should explain more clearly (assuming) > e.g. that the underlying format is JSON in what cases jCard should be > chosen and in what cases JSContact. Just defining "yet another format" > doesn't make sense. > > - I'm not usually doing this, but by chance, I read the Gen-ART review > for this document. I fully support it. In particular with respect to > legal vs. preferred names, there's also the example of researchers > preferring to use their maiden name in an academic context, and there > are cases of people with multiple nationalities that may have > different names in each nationality because of legal requirements > (the last case is orthogonal to the locale/script issue). > > - In Japanese, it is very important to not only have the name itself > (usually in Kanji), but also its pronunciation. Same for addresses. > Some names (e.g. 田中/Tanaka) are read without problems by anybody > in Japan, but there are others which are essentially impossible to > read without separate information. The spec should clearly indicate > how pronunciation for names and addresses is indicated to cover this. > Such information is given on most forms, and exists in most databases. > (English has a similar problem, but ignores it, because you can always > get somewhat close to the real pronunciation; in Japanese, that's > different.) > > - Some (names or) addresses in the Near East (Arabic/Hebrew/... script) > may contain data of mixed directionality (right-to-left as well as > left-to-right). The document contains absolutely no information about > how to deal with such issues. > > - The way a name (and some other information) can be composed of > components, together with extensibility, provides a lot of mileage > to deal with the very wide variety of name components and formats. > However, there are several issues: > 1) Reuse where it's only halfway appropriate. > In an example in Figure 31, the document uses "type": "middle" > for a Russian patronymic. This seems to be based on the > interpretation that the patronymic is "kind of like a > middle name". But it's only "kind of". A patronymic wouldn't > be initialized, whereas a middle name e.g. in the US is extremely > frequently only given as an initial. > 2) Definition by example: Figure 31 is only an example. Does it > mean Russian patronymics should be labeled as "type": "middle", > or what else? > 3) Extensibility will be needed for many countries and cultures, > but most of these are not used to proactively register things > with IANA, because they may assume they have to fit into the > base scheme, or because they do not understand the value of > such registrations. > 4) Depending on culture and language, there are many different > ways to address or refer to a person. > > - When names,... are composed, the default is to use a space as > a separator. There are many scripts (Chinese/Japanese/Korean/ > Thai/...) where words, and therefore (at least in running text) > name components are not separated. In the current design (as I > understand it), that would mean to add separator fields > between every pair of field. It would be good to have something > like a "default separator" to not have to repeat one and the > same separator several times. > > - There are many examples for parts of the specification, but no > overall example. > > Details: > > Introduction: > "The attributes of the card data represented must be described as a simple > key-value pair, reducing complexity of its representation." -> "The attributes > of the card data represented must be described as simple key-value pairs, > reducing complexity of their representation." > > 1.9.1: What about case sensitivity? ABNF is case insensitive, but > as far as I understand, JSON object keys are case sensitive. > > Figure 1: Why does the ABNF syntax just above not need a figure number, > but then all the examples need one? Labeling text as "Figure" looks > weird, "Example" would be better, but is probably also not needed. > > 2. Card: This starts without any introductory sentence whatever. > Such a sentence should be added. It's also unclear to me why this > specification uses the term "card" when the title uses the word > "contact" twice, but never card. It might be better to change this > to "contact". > > The mime type says "application/jscontact+json;type=card". > It's unclear why "type=card" is needed. The only thing contained > in the jscontact spec are cards, so application/jscontact+json > should be enough. > > 2.1.5 locale, and 2.7.1: It may often be the case that a single > set of data could be suited for more than one locale, but this > cannot be expressed currently. > > The spec forces one of the locales to be the 'main' locale, the others to be > localizations. This is quite in contrast to most other parts, where > alternatives are treated on an equal footing, maybe with some preference > indication. Why this inbalance? It may be inappropriate for some applications > or users. (what if there's a requirement to treat different localizations as > equivalent?) > > 2.1.6: Using 'true' values rather than simply an array of UUIDs > seems somewhat abstruse. Where does this kind of stuff come from? > > 2.1.7: Why does this use SGML syntax? Is that mandatory? Say what > values are allowed here and what not. > > 2.2.1: Probably due to xml2rfc or some other software, this has > double spaces after periods where very clearly, there should be > only one period ("Mr. John Q. Public, Esq."). > > 2.2.4, organizations: The example in Figure 15 has two units. > Is the order of the units outside in or inside out? Or is this > an example for a matrix organization? > > 2.3.2: Why do 'impp' and 'uri' have to be distinguished? This > should be clear from the URI scheme in the "user" field. > > 2.3.3: "cell": Please change this to "mobile", which is way more > popular according to Google ("cell" really sounds antiquated to > me, but your mileage may vary). > > 2.3.4: "preferredContactChannels" and "ContactChannelPreference" > seem to be a waste of bytes (but only the most egregious out of > many). > > 2.5.1: "street": There are countries (in particular Japan) that > do not use street addresses, but a more hierarchical block-based > system. The spec should say that the "street" field includes such > cases, or should explain how to denote them. > > Why are separators ignoreable in "street"? > > In Figure 25, why are numbers given before names in the fullAddress > field, but after in the StreetComponents? > > 2.6.3: Why are there no "kind"s for blogs, web pages,...? > > 2.6.4: "The resource is a photograph or avatar." -> > "The resource is a photograph of the person or picture of their (one of their) > avatar(s).": In my understanding, a jpeg file isn't an avatar, but just a > rendition of an avatar. An avatar may be 3-dimensional, or have various > different renderings,... > > "graphic image or logo associated with entity" -> > "graphic image or logo associated with the entity" > > 2.7.1: "a localized Card SHOULD NOT contain more information than its > non-localized variant": Also say that the information shouldn't be different. > On top of that the "localizations" structure is part of the card, so the term > "localized Card" doesn't seem appropriate here. (It would be appropriate for a > separate card that is a localized version.) > > Figure 31: What is the notation used in "addresses/addr1/locality"? > I assume a path indicating what to patch. But then, Figure 32 doesn't > use this syntax. Why not? > > 2.8.1, kind: "This RFC defines a small set of common anniversary types, > additional types MAY be registered at IANA (Section 4.6.2)": Don't talk about > types when you label them "kind". Also, the language for extension by RFC or > registration or private use is not consistent throughout the spec. If there's > one single way of doing extensions (i.e. all extension points allow definition > by additional RFCs and IANA registrations and private stuff), then clearly say > so somewhere, and define a short term for this kind of extensibility. If there > are two or three different ways to do this (e.g. some places, private > extensions are allowed, but others not), then again define the various > categories in a single place and then use the defined terms. > > "Note that for calendar systems with leap months, the year property might be > required to convert between the Gregorian calendar date and the respective > calendar system." This is not limited to calendar systems with leap months. It > would be the case for a calendar with 12 months of 30 days each, too. > > 2.8.2, keywords: See above at 2.1.6. > > 2.8.4: "This is free-text, but future specifications MAY restrict allowed > values depending on the type of this PersonalInfo.": It should be made clear > that such restrictions will not be applied to the currently defined kinds > (expertise, hobby, interest). Otherwise, we have a compatibility problem. > > 3. "status of known implementations of the protocol": This is not a > protocol, but a format. The fact that only one implementation seems to exist, > and only in alpha, doesn't necessarily support moving this spec forward quickly. > > 4.1: See above at 2. The "type" parameter seems unnecessary. > > For fields that say "this document", replace with "RFC XXXX". > > Shortly before 4.3.1: "check it is coherent" -> "check whether it is coherent" > > Both Table 3 and table 4 have the same title, but totally different content. > Please check. > > Security Considerations: > > Probably worth mentioning that data should only be collected and distributed on > a need-to-know basis. > > "JSON uses opening and closing tags for several types and structures" > It's the first time I have seen {, }, [, and ] being called "tags". > > " Since JSON does not use explicit string lengths, the risk of denial of > service due to resource exhaustion is small": Not sure about this. It all > depends on the implementation. An implementation may believe a large string > length, or it may allocate a large buffer just in case because it doesn't have > any information about string length. > > > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan