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

[Philipp Kewisch <[e-mail]>]

Hi Mike,

please see comments inline.

On 2/11/17 4:56 AM, Michael Douglass wrote:
>>> - Sec 1.4, last para: Should the discussion of ATTACH handling
>>> 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.
> 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.
Looks like managed attachments is pretty far so this would be feasible.
>
>> 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?
> 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.
The example I found suggests that
http://www.example.com/lucy.xml#xpointer(//character[@castmember="arnaz"])
would be a valid xpointer in an URI, but then again I did not read the
rest of that book and I am not an expert in the XML usecases you have. I
was just wondering if it would be better to stay more general instead of
fulfilling a specific XML usecase here.


>> 4) Section 3, there is something missing from the last sentence of the
>> first paragraph
> 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].
Yes. Specifically this part. Reading it twice does make it sound right
now, I guess the comma after URIs fooled me. Could you move it before
the "while" or drop it?
> 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).





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

>> 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.
> 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.
Ok. Could you add something like "For consistency with [RFC5545] Section
XXX, ... "
>
>> 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.
> 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
I am not concerned about the access, but the tokens could contain
information that already allows making assumptions, even without access
to the target system.

>> Mike, I'd appreciate if you could also comment on the previous items and
>> fix the nits.n.
> 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.)
I'd have to leave the exact answer to someone with more knowledge on the
process but from what I gathered, this draft is marked to update rfc
5545, which has a version -00 that was posted before RFC5378, and the
authors are not the same as in 5545.

Is there any content in this draft that was created before 10 November
2008, where the author is not willing to grant rights?
>
>> I would also appreciate if you could provide some details as to which
>> 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)
Great, it would be nice to have some practical experience with this
draft. Have any other vendors implemented this?

Philipp