Re: [calsify] Murray Kucherawy's No Objection on draft-ietf-calext-eventpub-extensions-17: (with COMMENT)

[Michael Douglass <[e-mail]>]

On 1/13/21 12:13, Barry Leiba wrote:
>> 5545 says in section 2 "enumerated property values, and property parameter values are case-insensitive."
>> - thus ACTIVE and aCtIvE are intended to be the same.
>>
>> However, jscalendar - which we need to be able to map to and from says:(Section 3) "Property names and
>> values are case-sensitive."
> I don't see a problem here: clearly, mapping from iCalendar to
> jsCalendar will fold to lower case, and mapping from jsCalendar to
> iCalendar will preserve lower case.  Do you see a problem (as opposed
> to a "Gee, why did we make them different?" question)?

I think it was an uncompleted thought. The relations draft uses link 
relations and it turns out they are specified to be case-insensitive 
(https://tools.ietf.org/html/rfc8288 section 2.1.1) so we have values 
like (from 
https://www.iana.org/assignments/link-relations/link-relations.xhtml) 
"convertedFrom".

It just feels like we have no consistency across standards in how values 
like these should be matched. I'm inclined to think case-insensitivity 
is the only safe option.


>
>> Section 11.2: The rules for making registrations into both the existing
>> registries and these new ones are striking.  RFC 8126 doesn't even create a
>> category that is a combination of Expert Review and Standards Action, but
>> that's what this spells out.  And I wonder what would happen if we were to
>> publish a Standards Track RFC (which has IETF consensus) with which the
>> Designated Expert disagreed.  I'm not asking for anything to change here given
>> that consistency with the existing registries is probably desirable, but it
>> does set an unusually high bar for registrations.
>>
>> I'm inclined to agree - with all the points. If the general feeling is I should come up with more manageable
>> constraints I can do that.
> As I've said to Murray off list, I think this is a broader issue that
> we should fix in an update of 5545, rather than trying to fix it here.
> You aren't actually specifying registration policies in this document,
> but are instead using the registration policies in the base iCalendar
> by reference.  I think that's the right way to go for now.
Good.
>
> Barry