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

From: Barry Leiba <[email-masked]>
Date: Wed, 26 Jun 2019 15:41:21 +0100

> >> — Section 10 —
> >> It’s good to refer to RFC 3986 for URI-related security considerations, and all
> >> of them do apply here.
> >>
> >> Something else that comes to mind that comes along with a set of new URIs is
> >> whether they actually point to what they say they do.  I don’t see that there’s
> >> any way to verify that they do, and I’m very skeptical about the effectiveness
> >> of warning an end user about this sort of thing, for many reasons.  I can see
> >> why allowing URIs is convenient and compelling, but I’m very heavily concerned
> >> about tracking and other privacy leaks, malicious and deceptive content, and
> >> other such problems, especially considering the prevalence of abusive calendar
> >> invitations these days.
> >>
> >> I’m not sure what the answer is here, but let’s have a discussion about it and
> >> see where we can go with it.
> >
> > Maybe a brief discussion at CalConect/IETF meeting?
>
> Yes, that sounds like a good idea.  We'll hold this until then.

I see the notes from the meeting, and all I see about this document is:

> Eventpub:
> - https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
> - Discussion about the SOURCE property (drop it)
> - Need to define “social calendaring”.

Was the URI issue I raised discussed?  If not, when can we discuss it
and clear this up?

Barry

---

From: Michael Douglass <[email-masked]>
Date: Wed, 26 Jun 2019 11:07:24 -0400

That would have been a good discussion to have. Somehow it dropped off 
the list.

I'd suggest it's not specifically a problem with this draft - we already 
have that issue with other properties and other drafts but I certainly 
don't mind using it as a starting point.

I think we need more than just a single paragraph: we do have this

Guidelines to protect against calendar abuse 
(https://standards.calconnect.org/csd/cc-18003.html)

It does refer to links as an issue but maybe we need more detail?

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jun 2019 08:52:55 -0600

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

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.

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)
[email-masked]
714-989-6135

---

From: Michael Douglass <[email-masked]>
Date: Thu, 27 Jun 2019 11:27:50 -0400

On 6/27/19 10:52, Doug Royer wrote:
> "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.
>
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?
>

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 Jun 2019 11:54:30 -0600

>        SHOULD be registered in the manner laid down in this

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

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

--