Re: [calsify] Barry Leiba's Discuss on draft-ietf-calext-eventpub-extensions-12: (with DISCUSS and COMMENT)

[Michael Douglass <[e-mail]>]

On 6/27/19 10:52, Doug Royer wrote:
> On 5/25/19 8:44 PM, Michael Douglass wrote:
>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> Thanks for the work in this document; I think there’s useful stuff 
>>> here, and I
>>> appreciate what it took to put it together.  Two things at the 
>>> DISCUSS level:
>>>
>>> — Sections 5.2, 7.1, and 8.1 —
>>> Please see BCP 178 (RFC 6648), and then remove x-name and x-prop.  
>>> Thanks.
>> Removed
>
> Your really limiting *ALL* resources to *ONLY* these: "ROOM", 
> "PROJECTOR", "REMOTE-CONFERENCE-AUDIO",
> "REMOTE-CONFERENCE-VIDEO" ? I have seen many more over the years. Such 
> as: Car, Laptop, Cabin, Test-Station, ...

No - as the spec says

       The registered values are described below.  New resource types
       SHOULD be registered in the manner laid down in this
       specification.

>
> At a more global level. I think that resource type is one of the most 
> free-for-all value types in iCalendar. It is not going to be possible 
> to define what vertical market calendar applications need. The removal 
> of x-name will be ignored (as it is now). I have seen many that do not 
> start with "X-" and are not IANA defined. It started off years ago 
> (before 2445) with a suggestion or example. So examples were added, 
> that became IANA defined. However *MANY* non standard values exist in 
> the WWW wild world.
>
> Would it be more realistic to open it up to any name the user or 
> application needs?
> I am guessing that closing it down - will be ignored, as it is now.
There is value in having a 'standard' set of resources - it allows UIs, 
applications etc to handle it in a more automated manner.
>
> Similar with x-prop. Vendors add properties they need in vertical 
> market calendaring applications. They are going to add them. They are 
> going to be seen. So now your going to remove a preferred way and 
> almost invite confusion. Currently an implementation can simply ignore 
> x-whatever. Now it is easy to filter out vendor specific X-PROP 
> properties. It is going to be a mess for an existing implementation to 
> guess if it is vendor specific, or a new IANA defined property that 
> should be preserved. For the most part, they prefix their vendor 
> specific properties with X-, now your removing that restriction?
>
> What was the reasoning for removing them?

>
> Without them, this looks more like a candidate for an FYI-only RFC 
> documentation that describes how a single (or few) vendor does things.
>