Subject: Re: [calsify] Review of draft-ietf-calext-ical-relations-00

From: Michael Douglass <[email-masked]>
Date: Fri, 3 Feb 2017 13:18:39 -0500

Thanks Ken.

Changes made and new version uploaded.

One thought  I'd prefer some other name than STRUCTURED-CATEGORY though 
I could live with it (names are often that hardest part). CATEGORY-REF 
might get the sense across better - even though there may eb a 
structured category entity out there somewhere this is really a 
reference to it - it may be just the path part or it may eb an absolute 
url but I think it's still a reference.

On 1/17/17 17:11, Ken Murchison wrote:
> Overall, this document looks good.  Comments below.
>
> - There are several instances of "Icalendar", which should be changed 
> to "iCalendar"
Done
>
> - Since we update the RELATED-TO property, the boilerplate should 
> state that this document updates RFC 5545
>
Done
> - Sec 1.1, last para, last sent: "These changes allows ..." -> "These 
> changes allow ..."
>
Done
> - Sec 1.4, last para: Should the discussion of ATTACH handling 
> reference draft-ietf-calext-caldav-attachments?
Done
>
> - Sec 4, para 1, last sent: "... a link to an component ..." -> "... a 
> link to a component ..."
Done
>
> - Sec 4, Description, para 2: "It defines ..." -> "This parameter 
> defines ..."
>
Done
> - Sec, 7: For the new non-TEXT properties, should we explicitly state 
> that there is NO default value type to force producers to always 
> include VALUE= so that consumers not familiar with the property don't 
> assume an incorrect type?
>

> - Sec 7.1, Description, last sent: presumably the Bedework reference 
> needs to be changes to something else
Changed to "In addition, a structured URI value allows for hierarchical 
categorization of events." (refactor caused the bedework ref)
>
> - Sec 7.2: Value type is listed as URI, TEXT, or REFERENCE, but the 
> definition only shows URI and REFERENCE
Fixed - I think the abnf was broken as well
>
> - Sec 8.1: Value type UID appears to be missing
Fixed
>
> - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs.  Its not a 
> parameter.
Removed - copy-paste error
>
> - Sec 10.4: I don't think REL belongs
Ditto

---

From: Philipp Kewisch <[email-masked]>
Date: Fri, 3 Feb 2017 19:47:44 +0100

Hi All,

sorry this is just a moment to late for 01, I was actually typing this
up on the plane this morning. Anyway, some comments to consider for -02.

Philipp

--8>--

Hi All,

thanks for making the comments. I've reviewed this document with my
calext co-chair role in mind. The changes Ken has suggested sound

> reference draft-ietf-calext-caldav-attachments?
I would also suggest to reword this paragraph. As the content will be
permanent I believe it would be better not to reference future work.
Therefore we should either publish the caldav attachments document first
and then reference it, or reword it to generally explain why LINK should
not be considered the same as an attachment.
> - Sec 10.2: I don't think STRUCTURED-CATEGORY belongs.  Its not a
I do not feel that STRUCTURED-CATEGORY can be considered a "relation",
which this draft is about. Maybe it makes sense to move this to a
different document?

Also, some further comments:

1) Section 1.2, can you explain this property in a bit more detail? The
introduction sounds very generic and from reading it without the rest of
the document I wouldn't know how to use it.

2) Section 1.3, " Unlike REFID the category imparts some meaning" -- can
you explain or reword "some meaning". This sounds very generic. In the
next sentence I'd also suggest replacing " It is assumed" with something
more concrete.

3) Section 2, the REFERENCE type seems to fulfill a very specific use
case. I briefly read that xpointers can also be expressed in URIs, maybe
we can just re-use that?

4) Section 3, there is something missing from the last sentence of the
first paragraph

5) Section 4, are the relations strictly limited to calendar components?
The text reads that way, but I was thinking it could also be other
values. I would also explcitly mention which properties the reltypeparam
(currently) applies to.

6) Section 4, "Applications MUST treat x-name and iana-token values they
don't recognize the same way as they would the PARENT value" -- so if an
unrecognized value is used, then this automatically becomes a parent?
What if there is already a parent? Would that mean the item has multiple
parents? I'd appreciate some clarification why the default PARENT makes
sense here.

7) Section 7.3, maybe you can explain better how REFID is used in the
intro to that section, specifically what kind of values would be common.
I see the example later on, but that only marginally helps understand
what it does. Maybe you can include a sentence that describes in what
other places the REFID may be used?

8) Section 8.1, maybe you can mention non-standard at the end instead of
the beginning.

9) Section 6, "VALUE=UID indicates that the associated value is the UID
for a component" -- Maybe you can elaborate on what a UID formally is,
with references to other documents.

10) Section 9, would it be a security concern that the relations may
reference components in another system that are meant to be private? If
relations between items are defined with this amount of structure, it
could allow making assumptions on private components.

Mike, I'd appreciate if you could also comment on the previous items and
fix the nits.n.

I would also appreciate if you could provide some details as to which
vendors have implemented the draft so far.

To anyone else reading this, please voice your concerns so we can move
this draft along.

Thank you very much for the work you have done on this document. I'm
looking forward to the next version.

Kind Regards,
Philipp

---

From: Michael Douglass <[email-masked]>
Date: Fri, 3 Feb 2017 13:57:54 -0500

A quick reply to one point below

> which this draft is about. Maybe it makes sense to move this to a

STRUCTURED-CATEGORY is the target of relationships. During our work on 
tasks we felt there was a need for explicitly stating the relationship 
that grouped tasks or events.

This type of relationship is also heavily used in public events - we use 
that type of relationship to create virtual collections and would like 
to see the approach formalised so that it can be exported.

So I agree STRUCTURED-CATEGORY itself is not a relationship but it 
allows for the creation of relationships with a reltype.
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Michael Douglass <[email-masked]>
Date: Fri, 10 Feb 2017 22:56:08 -0500

Thanks Philipp.

I'll resubmit with some of the changes made - I'm about to head for the 
CalConnect conference tomorrow.

Further comments

> up on the plane this morning. Anyway, some comments to consider for -02.
No problem - took me a while to deal with Ken's comments. I'll try to be 
more timely with these...
> not be considered the same as an attachment.
I guess it depends on how fast we go relative to managed attachments. I 
believe Ken is trying to move that along so maybe we can defer this 
until it's clear which will be first over the line.
> which this draft is about. Maybe it makes sense to move this to a
See earlier message
> the document I wouldn't know how to use it.
I've added some text extracted (and modified) from the Apthorp tasks 
draft (which was the original motivation)
> case. I briefly read that xpointers can also be expressed in URIs, maybe
Are you thinking of XLink? That might be reasonable. It was a specific 
case but may become more general - the original motivation was the smart 
grid work in which iCalendar entities may point at a portion of an XML 
payload. That may have more general uses, for example an event may be 
related to a specific page in a program.
> 4) Section 3, there is something missing from the last sentence of the
It seems OK - is below what you mean?

3.  Link Relation Types

    [RFC5988] defines two form of relation types, registered and
    extension.  Registered relation types are added to a registry defined
    by [RFC5988] while extension relation types are specified as unique
    unregistered URIs, (at least unregistered in the [RFC5988] registry).

    The relation types defined here will be registered with IANA in
    accordance with the specifications in [RFC5988].

> values. I would also explcitly mention which properties the reltypeparam
It's a parameter on RELATED-TO which explicitly states it's for calendar 
components only. I think it's up to the property in which it's used to 
define the limitations. I think the approach is that RELATED-TO is for 
relations between calendar components and LINK for relations to 
non-calendar components. I was urged (in earlier discussions) to make 
that distinction.
> parents? I'd appreciate some clarification why the default PARENT makes
That text all comes from RFC5545. I'm not that keen on defaults but I 
think we're stuck with it.

The actual meaning of relationships may depend on the application so in 
some cases multiple parents may not be unreasonable - but again - these 
types come from 5545.
> 8) Section 8.1, maybe you can mention non-standard at the end instead of
Reused (modified) wording from 5545
> could allow making assumptions on private components.
Wouldn't that be true within a single collection? If the owner marked 
some events as private after they have been linked to then the system 
shoudl probably not deliver them to anybody other than the owner. The 
whole CLASS thing isn't well implemented anyway. I woudl suggest that 
creating a parent child relationship - or any other relationship - 
doesn't alter the way access is calculated for a specific entity. I can 
make that statement
> Mike, I'd appreciate if you could also comment on the previous items and
OK - I might need help on this:

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
      have content which was first submitted before 10 November 2008.  If you
      have contacted all the original authors and they are all willing to grant
      the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
      this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
      (See the Legal Provisions document at
      http://trustee.ietf.org/license-info  for more information.)

> vendors have implemented the draft so far.
Some of this is implemented by bedework - hope to have the rest done 
soon. This will also require updates to ical4j (or at least the bedework 
fork of that project)