Re: I-D ACTION:draft-ietf-asid-mime-direct-02.txt

[Tim Howes <howes@xxxxxxxxxxxx>]

Alec Dun (Exchange) wrote:
> 
> This is the follow-up to our phone conversation last Friday about
> merging the mime-props draft from the calendaring working group with the
> mime-dir draft from the asid working group.  The two drafts are not that
> different, here are the key changes I think we need to make to
> encapsulate the thoughts of mime-prop into mime-dir:

Here's my take on these proposed changes. To summarize, it wouldn't
kill me one way or another on these, but they do bring up some
interesting issues.

> 1.  Add an optional datatype parameter.  This will allow an application
> to identify and handle data based on it's  type.  We talked about the
> proto parameter being used to specify a way for an application to deal
> with the data, so maybe we should collapse the proto paramater into the
> datatype parameter.  I think we can also collapse "valuetypeparam"
> production into a url datatype.  We'd also pre-define the data formats,
> but not limited to that which we have in the MIME-PROPS draft.  See the
> suggested grammar below:
> 
> parameter := encodingparam / charsetparam
>                     / languageparam / datatypeparam /  [paramtype "="]
> paramvalues
> 
> datatypeparam := "datatype" "=" datatype
> 
> datatype := "text" / "boolean" / "datetime" / "time" / "date" / "float"
> / "long"
>                   / "binary" / "currency" / "url" / x-datatype /
> iana-datatype

As Harald points out, we would need to be clear on the relationship
between the use of this parameter and the implicit data type
associated with an attribute name, since the two could be used in
conflict. From this standpoint, it would be simpler to only do it
one way.

On the other hand, the datatype parameter provides a pretty simple
and effective way to transmit the "syntax" of an attribute to someone
who might not otherwise know it, making it a lot easier to define
attributes on the fly, for use between communicating parties.

The change to the doc is trivial, though. And in fact, it was always
our intention to allow people to define their own parameters, since
we figured we couldn't think of all the useful ones up front. Whether
this gets into the core spec or ends up defined as described in
Section 13 of the current draft, probably doesn't make a huge
difference.
Well, it doesn't make a huge difference to me, anyway.
But if Harald et. al can convince Alec that this is a Bad Idea, then
the whole issue becomes moot anyway, of course.

> 2.  Efficiency in repeated properties.  To increase efficiency, I
> propose that we allow properties which have the same name to be repeated
> without the name.  In this scheme, the repeated property would inherit
> the attributes from the previous property.  For example:
> 
> CN:  Frank Arthur
> CN:  Arthur Frank
> CN:  Frank
> 
> would become
> 
> CN:  Frank Arthur
> :Arthur Frank
> :Frank

We had a similar concept in the original draft. It was a "defaulttype"
parameter on the MIME body part, the value of which would be assumed
as the type in the absence of a type before the colon ':'. We did this
for the same reasons Alec mentions. It was removed because people did
not see the need and thought it was cruft. Alec's proposal is actually
more flexible than our original one, since it allows the default type
to change within the body part.

I think before we start deciding how to do this, we should decide
whether it's necessary. What's the application you have in mind, Alec?
In the original proposal, I had in mind using these things to carry
centroid or other indexing information that might contain many many
values of the same type. Once we decide that, we can argue about
whether to do it like this, or like John suggested, basically defining
a new type that is meant to hold a bunch of values.

> 3.  Grouping disjoint profiles.  We need to be able to assign a profile
> to groups of properties.  For example, I am sending a meeting request,
> identifying all the attendees and in the same message I am identifying
> where the meeting is, what time it's at, etc.  We thought about having a
> base body part that had URLs to other parts, but that has a lot of
> overhead, so instead we were thinking of a construct that looked more
> like this, allowing multiple profiles within a single body-part:
> 
> begin:  meetingdetails
> Location; datatype=text:  "At the boathose"
> Date; datatype=date: 11 Aug 96
> Time; datatype=time: 10:30:00
> begin:  meetingattendee
> CN:  Frank Arthur
> SN:  Jones
> Status:  Required
> begin:  meetingattendee
> CN:  James George
> SN:  Brown
> Status:  Optional

Overhead is one concern. Another is whether the content of the body
part should be able to live outside of MIME, without the structure
that MIME gives it. This was one of our goals with the vcard profile,
which came from a different environment and still wanted to be useful
there (e.g., copy-pasted on clipboards, beamed around between PIMs,
downloaded to your phone, etc.). In these environments, the overhead
is a much bigger concern. And while I know our focus is on the
Internet, not on these other environments, I think it would be a
shame to force them to do something different from us when it would
be pretty easy to adopt something useful both places.         -- Tim