[calsify] Artart last call review of draft-ietf-calext-ical-relations-09
Spencer Dawkins via Datatracker <noreply@ietf.org> Sun, 06 February 2022 21:54 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 979803A0E0A; Sun, 6 Feb 2022 13:54:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: calsify@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164418448737.20648.7264741467656389932@ietfa.amsl.com>
Reply-To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
Date: Sun, 06 Feb 2022 13:54:47 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/H11SPbWoM3si08ZsXzsPqDSTYvQ>
Subject: [calsify] Artart last call review of draft-ietf-calext-ical-relations-09
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Feb 2022 21:54:49 -0000
Reviewer: Spencer Dawkins Review result: Ready with Nits Thank you for doing these new relation types. I can see how they would be very helpful. I also looked at the -09 diffs - thank you for making those changes. They do improve the document. I do have some nits and questions, but none rises to the level of an issue. Please do the right thing. In section 2 and in section 7, "it's" should be "its". In section 6.1, I see In addition to the values defined here any value defined in [RFC8288] may be used. However these uses SHOULD be documented in an RFC updating both [RFC5545] and [RFC8288] I have two questions - why normative language at all for this? it's a requirement for what people should do, not what the protocol should do. and why SHOULD? It seems that if this is something that ought to happen, I don't understand why allowing the possibility that it won't happen makes sense. In section 8.2, I see linkparam = ; the elements herein may appear in any order, ; and the order is not significant. (";" "VALUE" "=" ("REFERENCE" / "URI" / "TEXT")) 1*(";" linkrelparam) (";" fmttypeparam) (";" labelparam) (";" langparam) *(";" other-param) I'm asking this out of ignorance - is it obvious what happens if one or more of these elements appears twice? I'm guessing that it's not obvious, because the order is not significant, so one can't know a priori what an implementation would do. If that's the case, you might want to say MUST NOT appear more than once, to avoid indeterminate behavior. But if this would already be invalid, that's fine.
- [calsify] Artart last call review of draft-ietf-c… Spencer Dawkins via Datatracker
- Re: [calsify] Artart last call review of draft-ie… Michael Douglass
- Re: [calsify] [art] Artart last call review of dr… Francesca Palombini
- Re: [calsify] [art] Artart last call review of dr… Michael Douglass
- Re: [calsify] [art] Artart last call review of dr… Bron Gondwana