Subject: Relative URI in 2445 ?

From: Olivier Gutknecht <[email-masked]>
Date: Wed, 12 Feb 2003 17:51:06 +0100

Hi

Do we accept relative links in URI values in RFC 2445, for instance in 
ATTACH ?

The specification says:
	Purpose: This value type is used to identify values that contain a 
uniform resource 	identifier (URI) type of reference to the property 
value.
	Formal Definition: The data type is defined by the following    
notation:
	uri        = <As defined by any IETF RFC>

	Description: This data type might be used to reference binary 
information, for values that are large, or otherwise undesirable to 
include directly in the iCalendar object. The URI value formats in RFC 
1738, RFC 2111 and any other IETF registered value format can be 
specified. Any IANA registered URI format can be used. These include, 
but are    not limited to, those defined in RFC 1738 and RFC 2111.

1738 only covers relative links with the following definition: "In some 
cases, URLs are used to locate resources that contain pointers to other 
resources. In some cases, those pointers are represented as relative 
links where the expression of the location of    the second resource is 
in terms of "in the same place as this one    except with the following 
relative path". Relative links are not described in this document. 
However, the use of relative links depends on the original URL 
containing a hierarchical structure against which the relative link is 
based. Some URL schemes (such as the ftp, http, and file schemes) 
contain names that can be considered hierarchical; the components of 
the hierarchy are separated by "/". "

My question is: -if- the iCalendar data is stored and referenced 
through a scheme which is compatible with relative linking (i.e. an ics 
file on a filesystem file:/home/olg/mycal/ol.ics, or accessed through a 
http://foobar.com/cals/ol.ics or ftp url, is it correct iCalendar to 
use a relative URI in an attach property ?
A simple scenario could be a ics file with an external attachment 
expressed as a file: URI then transferred (with the attachment) to a 
FTP server. Using a relative link here could keep the resource 
accessible without modification of the original iCalendar data. The 
problem is that we don't have an explicit notion of a base URI in 
iCalendar. so that's probably invalid or left to the interpretation of 
the CUA ?

Ol.

---

From: John Stracke <[email-masked]>
Date: Wed, 12 Feb 2003 12:42:56 -0500

> iCalendar. so that's probably invalid or left to the interpretation of 

I would think so.  It's analogous to the case of HTML: HTML permits 
relative links, but you have to be careful with them when transferring 
data around.  If you mail somebody a page that you see via an http: URL, 
relative links in the HTML will be invalid unless your MUA either 
rewrites them or (more commonly) adds a <base> tag.  Similarly, a CUA 
that composes iCalendar with relative URLs has to rewrite those URLs 
when it sends the iCalendar to any other CUA.

As a rule of thumb, I would say that relative URLs are highly unlikely 
to work in most iCalendar scenarios.  They work on a local drive; but 
very few applications store iCalendar in local files (the only exception 
I know of is Evolution).  They work on an HTTP server; but the only app 
I know of that stores iCalendar via HTTP is Outlook/Exchange, and that's 
a private HTTP server whose URLs are not likely to be visible to the 
iCalendar recipient.

If you have a scenario where it's useful to store iCalendar in a local 
file (despite the performance problems of searching such a store), I'd 
say you need to assume that URLs to anything outside the iCalendar store 
will break when you send the iCalendar to anybody else.

Personally, I don't think I'd care for a CUA that stored attachments via 
file: URLs pointing to random places on my hard drive; it reminds me 
strongly of Eudora, which used to (still does?) strip attachments off of 
incoming messages and dump them in J. Random Folder.  That was always a 
pain; I much prefer more modern MUAs, which leave the attachments in the 
messages and parse them out at render time.

-- 
/===========================================================\
|John Stracke      [email-masked]                    |
|Principal Engineer|http://www.centive.com                  |
|Centive           |My opinions are my own.                 |
|===========================================================|
|"What we have here is a failure to assimilate." --Cool Hand|
|Locutius                                                   |
\===========================================================/

---

From: [email-masked]
Date: Thu, 20 Feb 2003 14:56:03 -0500

John replied on 02/12/2003 12:42:56 PM:
> to work in most iCalendar scenarios. 

I guess this also depends on how you contruct the iCalendar data stream. 

If you constructed the file as a multipart/related MIME message then you 
could include both the iCalendar object and the referenced ATTACHment data 
(using CID: URIs).  Separating the iCalendar entry from the ATTACHment 
data is frought with peril; including it in the same data stream is much 
much safer.

> will break when you send the iCalendar to anybody else.

Not 100% true.  See above.

Separating entry from ATTACHment is a receipe for peril when you start to 
try and preserve linkages.

Then again I guess you could make the ATTACHment inline (shudder, did I 
actually say that!?!?!) but doing so for a, say, big ZIP or MPEG is NOT 
something that inline ATTACHments were created for.  It is legal but its 
against the intent of inlines...  This just goes to show you that there 
are at least 2 alternatives that help prevent linkage breaks.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: John Stracke <[email-masked]>
Date: Thu, 20 Feb 2003 15:32:02 -0500

[email-masked] wrote:

> If you constructed the file as a multipart/related MIME message then 
> you could include both the iCalendar object and the referenced 
> ATTACHment data (using CID: URIs).

I suppose.  But the original question was about file: and http: URLs.

-- 
/==========================================================\
|John Stracke      [email-masked]                   |
|Principal Engineer|http://www.centive.com                 |
|Centive           |My opinions are my own.                |
|==========================================================|
|A man's concepts should exceed his vocabulary, or what's a|
|metaphor?                                                 |
\==========================================================/

---

From: [email-masked]
Date: Fri, 21 Feb 2003 10:23:07 -0500

> I suppose.  But the original question was about file: and http: URLs.

The original question was about relative URIs (ie: not fully qualified 
URIs) and not about just file: or http: (or ftp:...) URIs.  CIDs are 
somewhat realtive in that they point to other parts of the same data 
stream; kind of like a permanently relative URI (if ya squint a bit).

In any case, since its possible to craft a .mht file as a file I was 
merely pointing out that there is NO requirement that the sole data in 
that file be JUST iCalendar.  It is legal and possible to craft the file 
to be mutltipart internally and thus preserve linkage.  (I have sample 
.mht files from web sites if someone wants to check it out...)

Bruce