[AVT] Re: Comments on draft-freed-media-types-reg-01.txt

[Magnus Westerlund <[e-mail]>]

Hi Ned,

See below.

[e-mail] 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.

  [snip]

> 
>> 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?

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 my view both format has 
advantages of using the parameters:

mode-set
channels
dtx
rate

While the RTP payload format also needs in addition the following:
ptime
maxptime
octet-align
interleaving

These parameter has all to do with how you configure the RTP payload 
format and how much media you aggregate together.

The basic common structure, and the need for the same media coder makes 
it reasonable from my perspective to use the same media type name for 
both usage. The context one receives the media type will make it clear 
what exact format that will be used.

Comments

> 
>> MW4: Section 4.3: Syntax rules for parameters? I think the syntax (ABNF)
[snip]
> The best I can do here is to say that specific transport may impose
> limits on the allowed syntax for parameter values. I will add words to
> that effect.

Okay

> 
>> MW5: Section 4.9: I think the draft hints in section 4.2 that with
>> certain limited usage, another document may further define how the media
>> types should be treated, and what to think of. However I think it might
>> be worth being a bit more clear on what such a document should do. In
>> addition to defining any further restrictions on registration, I think
>> it should define a "name" for this application to be used in the
>> "Restriction on Usage" heading in the template.
> 
> 
> I'm really not sure we want to go here. Asking for people to specify an
> application names gets us onto a slippery slope towards having an 
> application
> name registrary. And AFAIK past experience with such registrations has been
> poor.

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.

The fact is that RTP is not an application, it is a framework that 
different application can use.

> 
>> 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.

The above is the reason I think one might need to consider to provide 
"intended usage" for different usages.


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt