Re: [calsify] SCHEMA vs New Property

[Doug Royer <[e-mail]>]

On 7/9/19 4:18 PM, Michael Douglass wrote:
> 
> On 7/9/19 16:57, Tim Hare wrote:
>> What is needed is documentation that says all calendar UAs are not required
>> to handle STRUCTURED-DATA and SCHEMA,  perhaps that if STRUCTURED-DATA is
>> used then DESCRIPTION  SHOULD be present to describe what the structured
>> data is so that any CUA can display _that_ text,  but consumers of the
>> calendar item that DO understand the SCHEMA can use it.
>>
>> In my view, defining new properties for every possible kind of VEVENT or
>> VTODO amounts to the same amount of work as defining a SCHEMA for that
>> structured data.  CUAs would fail, graciously, to process those properties
>> in the just about same way as they'd fail to handle the structured data.
>> The difference, to me,  is that using STRUCTURED-DATA and SCHEMA  means the
>> RFC isn't constantly updated for new use cases involving new kinds of data
>> that is related to the calendar event but not calendar data per se.

The effect of SCHEMA would be to create an entirely new object identifier to replace mime-type.

If the data is proprietary, the X-PROP with an undocumented data type works now and no documentation needed. Implementations are free to ignore X-PROP.

If the data is to be shared between vendors, then documenting is what is needed, and is the reason for the IETF, RFCs, and standards. It can be released as a proposed standard, or informational.

The issue with maintenance is work flow, and not so much data values. They are proposing both the flow and the data. The draft needs work and feedback.

> Additionally - data that is incompatible with the iCalendar format can be transported easily.

It already can, iCalendar is a MIME content type that can contain internal to the same MIME object - via CID, or external with a URL object sets. That is in the introduction of 5545.

A fact is that, some (many?) user interfaces do not take advantage of that may make it appear that a new object identifier is needed.

 From 5545:

	"...Note: While there is no restriction imposed on the URI schemes
          allowed for this parameter, Content Identifier (CID) [RFC2392],
          HTTP [RFC2616], and HTTPS [RFC2818] are the URI schemes most
          commonly used by current implementations. ..."


> And I don't think it's quite the same amount of work.

Same is relative to where the code is at, and the final version.

> New iCalendar properties need to be generally useful in calendars and scheduling. Very specific properties used to address a need such as this are probably better contained in data with their own schema.

There is no restriction on the type of attachments that can added.

The proposal to replace  Mime-Type identifiers inside of a MIME object, would be creating an entire new set of identifiers. Something that would be in parallel and out of step with how the IETF has decided to define object types.

The 'how to define any object in the world' debate has no solution. So the IETF decided on Mime-Type and a process to register new ones. And a process to use proprietary types of data. These defied mime types are known to many operating systems already. The IETF has a process in place to define new object types.

With many applications, I can copy/paste an attached object and the mime headers tell the drop point what the data is. It would be tossing all object identifiers new object identifiers.

> There's a whole other discussion as to whether or not these properties are generally useful - probably not as something only for maintenance.

Workflow is a great topic for iCalendar. Which I think is at the heart of their proposal. Perhaps their draft could be released (when ready) as an informational RFC, simply to document how it is done by several vendors. Then a parallel discussion about workflow would not delay them.

> As an aside having reread the draft - email is not the only possible transport mechanism. CalDAV or some other protocol might be appropriate. Any draft should probably allow for different ways of transporting the messages.

iCalendar is a MIME content type, that does not mean it must be transported via iMIP. And 5545 makes that point in the introduction section. And one reason that 2445 chose it as a MIME content type, was for attachments.

I can not think of any transport that can not transport a multipart MIME object.

I do not see any plus to internalizing any random kind of attachment, inventing a new object identifier, simply to make it a property value. If a need exists, use ATTACH with fmttypeparam set to a mime-type that has been defined or can be registered, and base64 encode it.

Or for  proprietary use, make up an X-PROP and include any proprietary value in any format needed.

-- 

Doug Royer - (http://DougRoyer.US)
[e-mail]
714-989-6135