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

[Doug Royer <[e-mail]>]

On 6/27/19 9:27 AM, Michael Douglass wrote:

>>>>
>>>> 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.

That is inconsistent with the ABNF. And over time, the ABNF wins. Except, it will be ignored making it another -bis debate.

>>
>> 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.
And, they can't, because there are already a lot of undocumented values that vendors are not going to just toss out of their implementation just because this makes it into an RFC. So, automate what? Is your implementation going be able to handle "CAR"? "Laptop"? ... I'll bet exactly zero implementations will come out that only handle IANA values.

They are used and in existing implementations. They are treated as user values, not keywords. I will bet there will be zero implementations that fail when they get currently used and undefined values.

So, your not documenting the world as it exists. And your not documenting the way the world wants things to exist. You seem to be documenting a way to make some code easier to implement, except I will bet you do not restrict your implementation to these. I say open them up, because there is not a definitive list, and can not be a definitive list.

Same with x-prop. When google, apple, FB, or someone big makes a new one up. Are you going to be the implementation that breaks? Or are you in version one of your implementation accept them?

>> 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.
>>


-- 

Doug Royer - (http://DougRoyer.US)
[e-mail]
714-989-6135