Re: comments on draft-eastlake-cturi-01.txt

Hi Al,

At 11:08 PM 1/28/01 -0500, Al Gilman wrote:
>I never caught up with the requirement being addressed, here.  What does CC/PP
>actually do with types that it hears about?  What does it need to know about a
>type?  What is the range of types it would come in touch with?

What kind of 'type' are you talking about here?  A MIME Content-type, or a 
more abstract math-ish kind of a type?

For the former, the currently proposed vocabularies for CC/PP (as opposed 
to the core structure, which is agnostic on such matters) use a text 
literal to designate a content-type, per MIME spec.  (This may not be how 
one would do it using RDF from the outset, but that proposal is an import 
from the CONNEG work.)

Assuming the IANA:URN namespace proposal can be established, the plan is 
that the RDF property that designates the MIME content-type value (and 
other CONNEG-derived properties) would be named via URN from the CONNEG 
registry.

>Does it ever compare a type and an instance for conformance?

The current CC/PP proposals don't attempt that:  it is left to the origin 
server to interpret the RDF property values that represent CC/PP attribute 
values.

>Or does it compare type references for equivalence?

I don't think we have any such thing.

>What types would one hard-code into CC/PP?  Or are the types not protocol
>parameters, but rather protocol data in CC/PP?

The only types hard-coded in the current proposal are the RDF classes that 
represent the basic structural elements of CC/PP.  There are some 
recommendations for value types, but they're not hard coded.

>It seems to me it would make more sense to create a schema which documents the
>structure of the Internet Media Type space.  Then reference Internet Media
>Types via their place in this schematized index to the existing dictionary of
>types.  Does CC/PP need to know that text/* is a supertype of text/html and of
>text/plain?  Does it need to know that application/octet-stream is a supertype
>of application/anything-else?  If it does, just injecting each type-indication
>(header field value) into URI space as an unrelated atom loses a lot of the
>value of the Internet Media Type system.

In its current proposed form, it knows nothing of these things.

But, on a related matter, when we looked at creating the CONNEG feature tag 
for media types, we took a view that it should focus primarily on the 
type/subtype elements, and play down the parameters.  On review, Ned Freed 
took a harder line, with which I agreed, which was to completely prohibit 
Content-type parameter values:  many of them just aren't relevant outside 
of a particular MIME usage (e.g. boundary on multipart) and others are 
better treated as separate features (e.g. charset on text/*).  This was a 
position taken for media feature descriptions -- other scenarios may have 
different requirements.

#g

Received on Monday, 29 January 2001 13:53:18 UTC