[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Re: Comments on draft-freed-media-types-reg-01.txt
Hi Ned,
See below.
ned.freed at mrochek.com wrote:
>> Hi Ned and John,
>
>
>> I have now reviewed your document and have some comments and questions.
>
>
>> MW1: Section 3.4: Based on all arguments I have heard about any
> But this is what the section already says:
>
> However, with the simplified registration procedures described above
> for vendor and personal trees, it should rarely, if ever, be
> necessary to use unregistered experimental types, and as such use of
> both "x-" and "x." forms is discouraged.
>
> I think this is pretty clear already.
I think one could use a stronger language in discouraging people.
Then by all means suggest some.
>
>> ME3: Section 4.3: Parameters only applicable to a specific domain of
>> usage? Certain types will be (are) registered for several domain of
>> usage, however the different domain may require that different
>> parameters are used. I can give you an example in RFC 3267 that has
>> quite many parameters for RTP usage, but none for the file format. How
>> is it supposed to be indicated that this is the case?
>
>
> IMO if the parameter space is different the types are different. I don't
> think it is appropriate to have domain-specific parameters, only
> type-specific ones.
Okay, so registering the RTP payload format and a dedicated file format
for the same codec needs to use two different media types, due to that
that they partially needs to have different parameters?
They most certainly do.
I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have
RTP payload format that carries the different audio frames. There is
also a specification of a file format, that also contains the same
frames. The wrapping structure is somewhat different due to that they
are file format and RTP payload format.
In other words, the bits are different as well. That means two media types are
required regardless of whether or not the parameters are the same.
While it is nice to be able to cater to some extent to protocol-specific needs
in our procedures, we cannot afford to compromise the core functionality media
types provide. One of those core functions is that each type labels a single,
canonical object format. Types don't label codecs, and it has long been the
case that a single codec can give rise to multiple media types. (It is also
possible for multiple codecs to be combined in a single type.)
I understand. I might have not meant application really correctly. What
I mean is that if we update the RTP registration rules for media types,
we can define a string that should be written into Restriction on usage
if only RTP is supported. That way we are not really being explicit
about application, but can ensure that we have a good definition on what
restriction we applies.
That may be the right thing to do for RTP, but we need to think more
generally here. Of course nothing prevents RTP from specifying its
own additional registrations requirements for media types it uses.
The MIME specification is certainly going to do something along these
lines once it is revised.
>> MW6: I think further clarification on the coupling between the "intended
>> usage" and the "Restriction on usage" is needed. For example, is one
>> allowed to use "Common" when the restriction of usage says: Only for use
>> in RTP? And is the classification of what is common, limited usage, or
>> obsolete depending on the domain?
>
>
> I guess I don't see the problem. The commonality of use of something
> has almost nothing to do with how usage is restricted. I could have
> a media type that's commonly used but only RTP. Or I could have
> an obsolete type that can be used anywhere. Any combination is possible.
>
> Perhaps moving the restrictions on usage field below the intended usage
> field in the registration form and adding some text as to what goes
> in the restrictions on usage will help.
>
What could happen is that we have a media type that is for a codec and
with two defined usages, file format and RTP payload format. The RTP
payload format is after standardization used, but later found unsuitable
for usage. Therefore a new RTP payload format is defined. However as
there is a deployed basis one can't simple use the same media type for
the new RTP payload format and defines a new one. The previous name is
still valid for the file format part, while OBSOLETE for the RTP payload
part.
In other words, having a media type that labels more than one sort of
object can give rise to situations where the intended usage varies
depending on where the type is employed. This is hardly surprising given
that the initial premise violates the entire media type philosophy.
This is still more reason why having a single label for two very differnet
things is TOTALLY unacceptable.
Ned
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt