[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[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.
[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 +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt