Re: Cool Features - Was: (Re: Examples Are Somewhat Confusing)

[Tim Howes <howes@xxxxxxxxxxxx>]

Peter O'Leary wrote:
> 
> I'm all for raising the issues and reaching consenus by working through
> them. My point is simply that if the issue being discussed is outside of
> the scope of Calendaring and Scheduling, in the opinion of the group,
> then it is appropriate to table it until other more pressing issues are
> resolved.
> 
> I personally believe that the issue of whether or not properties should
> be typed, while it may be an important question, does not need to be
> resolved for the purpose of Calendaring and Scheduling operations.

We've been discussing several issues. Here's the first one:

	1) Ordering of attributes within a body part (i.e., should we
	   require all the CNs come together).

Here's what application/directory says on this topic (from Section 5,
"The application/directory Content-Type", under "Published
specification".
Note sentence number two:

   Note that the meanings of the various type names and  the  format  of
   the  corresponding  values must be defined as specified in Section 9.
   Specifications may impose ordering on the type  constructs  within  a
   body  part,  though  none  is required by default. The various x-name
   constructs are used for bilaterally-agreed upon type names, parameter
   names and parameter values.

So, whether ordering is imposed or not is indeed an issue for C&S to
decide. If you need it, impose it in your profile definition. If you
don't then don't. The app/dir spec was designed this way on purpose,
to be flexible enough to support a wide variety of applications.

Issue number two:

	2) The datatype parameter (should it exist at all, be optional
	   or required, etc.).

Two options here. One, we could add datatype to the base app/dir spec
as an optional parameter. If the C&S profile thought it was necessary
to require it, you could do that in your profile definition. I'd be
happy to do this, not happy to require it all the time in the base
app/dir spec, since I think not every application needs it. Second
option is to leave the base app/dir spec alone, and just define the
datatype parameter in the C&S profile document (procedures for doing
this are given in app/dir). Since it seems like a potentially generally
useful thing to me, I'd like to see us take the first route. If we
do that, then the only C&S issue is whether to require use of this
parameter.

Issue number three:

	3) Saving space for repeated values of the same type.

Two options here, too. One, change it in the base spec as Alec
suggested (missing type before the ':' defaults to the previous
type). Two, define a new type (e.g., names instead of name) that
has in its syntax the ability to specify multiple values (e.g.,
names: (name1, name2, ...) or something - you get the idea).

On this one, the debate seems to be whether the space savings
are really worth the extra parsing complexity or not. The issue
for C&S is whether you need to save the space. If so, let's figure
out the best way of doing this. If not, let's stop talking about
it, at least until we find a real application that needs this.

Issue number four:

	4) Grouping of disjoint profiles within the same body part.

I believe you can do this in your C&S profile definition, and
that the base app/dir spec allows it already. If that's not the
case, and somebody can suggest the wording change to app/dir to
explicitly allow it, I'm happy to add it.

So, this was all just a long way around to summarize the issues
and to say that some of them definitely do apply to C&S. If
C&S come up with some requirement you don't think the current
app/dir draft can handle (e.g., you need the space saving, you
don't think app/dir allows grouping of profiles, etc.), then
let ASID know and we'll work to change app/dir.       -- Tim