Hi Bruce,
Please consider what Stephan Casner says. I totally agree with his
response. I simply want to make a few comments.
I think you really should ask yourself how it comes that the current
process has been used in 6-7 years and for more than 70 registrations
without anyone raising any issues. I take this as an sign that the
current process works and is viable. It can only benefit from a bit of
clarification. For example in the area of text. Where all we desire is
clarification on the possibility to register types that are restricted
to RTP without the strict requirement on basic parsing.
I also question if the MIME world really can continue using that
criteria themselves. Is this really working, it seems not in the
application I am using. I don't want to see the html formating in my
browser, even if it is readable.
Bruce Lilly wrote:
I have suggested grandfathering existing RTP-related registrations in
a separate RTP registry. That would prevent further confusion and
would give the RTP registry a separate sandbox with clean sand and new
toys. Some small amount of copying work would be required, and of course
registration procedures for both registries would require some minor
tweaking.
We don't want a new sandbox, moving from the current is such work that
it isn't worth it with the small gain and great risk for confusion it
creates. What I suggest is that we clean up the current sandbox so that
we can reduce the confusion on what is in it and what is allowed.
Because of widely-deployed mission-critical MIME applications, any such
"clean up" cannot change the fundamental rules for text media types, as
detailed earlier. We're not talking about mere entertainment applications,
we're talking about email and things like Internet fax, voice messaging,
and EDI.
I am not intending to breaking MIME based applications. I want to avoid
breaking any of the applications, MIME or RTP. But you seem to be fine
saying that breaking RTP does not count, it isn't mission critical,
despite it being a hugely deployed protocol. Separating the registries
will cause confusion, generate errors and inconsistencies in a number of
standard documents IETF's and others.
Re workload:
o for whom?
A separate registry would mean that AVT would need to perform the
following work:
- Write a new registration RFC
- Update the 70+ registrations documented in 35+ RFC
- Inform a number of standard organizations or consortium like ITU,
ETSI, 3GPP, 3GPP2, DLNA, etc about the new rules and have them update
their specifications.
Are you volunteering to see these changes thou?
Regards
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(_dot_)westerlund(_at_)ericsson(_dot_)com
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf