Subject: [Ietf-calsify] Re: AD review issue #1: Use of ALTREP

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 04 Jul 2008 09:52:19 -0400

I don't believe the current proposal is appropriate.

As it stands, the draft (RFC2445 as well) makes it clear that ALTREP is 
only allowed on 6 specific text properties, that is, COMMENT, 
DESCRIPTION, LOCATION, RESOURCES, SUMMARY, and CONTACT. I also believe 
the meaning of ALTREP is already properly defined.

In practice though, I'm not sure there is a single calendar user agent 
that exposes it (i.e., allow an end user to set its value, or make use 
of it).

Finally, the following search on the web will only report two iCalendar 
objects that makes use of ALTREP!

http://www.google.com/search?q=ALTREP+filetype%3Aics

In the past we've discussed limiting the URI schemes allowed for 
CAL-ADDRESS but never got around to it.  Perhaps we should limit the URI 
schemed allowed both for ALTREP and CAL-ADDRESS (two sets) while we're 
at it.

On the other hand, when applications while actually start making use of 
ALTREP, I suspect the media type of the resource being pointed at might 
be the real interop issue (e.g., http URL pointing to an XHTML, HTML, 
PDF, PNG, or JPG document).

Cheers,
Bernard

Eliot Lear wrote:
> Am I correct in that this issue is to be resolved as below?  Are there 
> any objections?
> 
> Eliot
> 
> Lisa Dusseault wrote:
>>
>> On Jun 23, 2008, at 3:49 AM, Aki Niemi wrote:
>>
>>> May I suggest an alternative approach? Since the list of "known" uses of
>>> ALTREP can actually be narrowed down to about three, I think we should
>>> add to the definition of each of these properties exactly what it means
>>> to receive one with the ALTREP parameter that contains an HTTP URL.
>>> Other URIs permitted, but their meaning is undefined. In other words,
>>> document current practice as much as we can, but keep further uses open.
>>>
>>> And then to ALTREP parameter, add the description you propose, as
>>> generic advice to how the parameter should be handled/used.
>>
>> +1
>> _______________________________________________
>> Ietf-calsify mailing list
>> [email-masked]
>> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>>
> 
> 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 04 Jul 2008 10:02:28 -0400

Cyrus Daboo wrote:
> Hi Aki,
> 
> --On June 16, 2008 12:59:12 PM +0300 Aki Niemi <[email-masked]> wrote:
> 
>>> > Section 3.2.6, DIR parameter:  This should be limited to LDAP URLs
>>> > only, if not by requirement then at least by noting that other types
>>> > of URLs are likely to be harmful to interoperability.
>>
>> For maximum interoperability, a mandatory-to-implement choice should be
>> defined. However, is LDAP even widely enough supported in iCalendar
>> implementations to justify this? I suspect vCardDAV URLs could in the
>> future start appearing here as well.
> 
> I think at the very least HTTP/HTTPS needs to be allowed as well.
> 

cid and mid would be needed in the context of iMIP.

Here's a proposal for the mandatory-to-implement:

cid
data (e.g., to embed vCard directly?)
file
ftp
http
https
ldap
mid

Cheers,
Bernard

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 04 Jul 2008 10:46:33 -0400

While I was about to propose that we deprecate SIBLING I found cases 
where it might be handy in the future...

1- Group multiple to-dos that don't have a parent to-do. Not a very 
important use cases I think...

2- When breaking an unbounded recurring events in two events (i.e., the 
truncated unbounded recurring events for past recurrence instances, and 
a new unbounded recurring event for the "new" future recurrence 
instances), it might be useful to link the events together with this 
relationship.

Cheers,
Bernard

Aki Niemi wrote:
> ma, 2008-06-16 kello 10:03 +0300, ext Aki Niemi kirjoitti:
>>> Section 3.2.15: RELTYPE.  What does it mean that a calendar component  
>>> referenced is the SIBLING of this one?  How is a user agent supposed  
>>> to use this information?  Is this parameter ever used except on  
>>> RELATED-TO?  Is it actually in use even there?  Health warnings at  
>>> least.
> 
> Good question. Is there a use case that requires a relationship beyond
> parent-child (which currently is the only *defined* relationship in the
> document anyway)?
> 
> Cheers,
> Aki
>

---

From: "Robert Ransdell" <[email-masked]>
Date: Sat, 5 Jul 2008 21:51:07 -0400

Notes uses it on Description and Comment.

From:
Bernard Desruisseaux <[email-masked]>
To:
Eliot Lear <[email-masked]>
Cc:
"[email-masked]" <[email-masked]>
Date:
07/04/2008 09:56 AM
Subject:
[Ietf-calsify] Re: AD review issue #1: Use of ALTREP
Sent by:
[email-masked]

Cheers,
Bernard