Re: [calsify] AD review of draft-ietf-calext-jscalendar-23

["Neil Jenkins" <[e-mail]>]

Many thanks Barry for your detailed review and excellent suggestions. I have updated the document with your suggested edits and published a new version <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-24>. Remaining points discussed below.

> — Section 4.4.1 —
> 
>  The priority is specified as an integer in the range 0 to 9. A value
>  of 0 specifies an undefined priority. A value of 1 is the highest
>  priority. A value of 2 is the second highest priority. Subsequent
>  numbers specify a decreasing ordinal priority. A value of 9 is the
>  lowest priority.
> 
> What happens when priority 0 is mixed with other priority values?

VAVAILABILITY (RFC7953) treats it the same as lowest priority (9), but I could imagine in other systems you might treat it the same as highest priority. The current definition is to match with iCalendar as it did not seem worth deviating here.

> — Section 4.5.2 —
> 
>  o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger"
>  (mandatory)
> 
> This is a manner of specifying this sort of thing that has not been
> used before. You’ve always been using a defined type. Here (and in
> other items below) you appear to be using specific strings with no
> explanation about what the “|” means. There’s an inconsistency here
> that I’d like to see fixed or clearly explained.

I'm not sure exactly what you find inconsistent here. These *are* types, not strings. The definitions of the OffsetTrigger, AbsoluteTrigger and UnknownTrigger types are immediately below. As per the Type Signatures conventions specified in Section 1.3 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-24#section-1.3>, the “|” means alternation: the value can be any one of these types.

> — Section 8.2.3 —
> 
>  This preferably takes the form of an RFC, but for simple definitions
>  a description in the registry may be sufficient.
> 
> I’ve had a conversation with IANA about this. The operative bit here
> is whether "a description in the registry" could serve as the
> "specification". I don't think we'd accept that. It's supposed to
> be, according to BCP 26, a "permanent and readily available public
> specification, in sufficient detail so that interoperability between
> independent implementations is possible." While what you put in the
> registry can be considered permanent, and it's certainly readily
> available and public, it's a bit of a stretch. And it's hard to
> imagine that a sentence or two in a registry could be "sufficient
> detail". I'd say that some document, however brief, that's external
> to IANA is required.

The intention here was to reduce friction for people that want to add simple properties, to encourage registration rather than use of vendor-specific values which tend to lead to less interoperability. I do think there are many simple properties where the entire description could trivially fit in the registry and a document is overkill. Consider the title property for example, the entire definition is:

*
4.2.1 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-23#section-4.2.1>.  title

*

   Type: "String" (optional, default: empty String).

   A short summary of the object.

Pretending for a moment this wasn't in the initial spec, this would be registered like so:

*Property Name*: title
*Property Type*: String
*Property Context*: JSEvent, JSTask, JSGroup, Link
*Reference or Description*: A short summary of the object.
*Intended Use*: Common
*Change Controller*: IETF

Requiring a whole document for something like this just seems overkill to me, but I defer to IANA and your judgement on this; what would you suggest we do?

> — Section 8.4.1 —
> 
>  o Experts: The initial list of experts for Expert Review of updates
>  to the subregistry.
> 
> Hm, are you actually proposing that registrations provide their own
> lists of experts, rather than having them appointed by the IESG? I
> don’t think that’s going to work. We probably need to have a
> discussion about the intent here, so please initiate that by
> explaining to me what you’re looking for.

Suppose a new enum-type property is registered that is not IETF controlled, then a new enum subregistry will be created and the designated experts need to be given for that subregistry, hence its inclusion in the template. Does that make sense?

Cheers,
Neil.