Magnus-
We all agree the preferable choice is option (a), but how do we get there? The management of the RTP header extensions is not ideal due to circumstances now behind us. I don't see how we can make existing conformant practice (nearly anything) non-conformant upon publication of this ID.
At best, all a STDs track publication can say is "SHOULD" at this point in my personal view. It is not likely to be as simple as managing the "defined by profile" field as an enumerated field by IANA or explicit RFC publication as some have suggested, since 3350 gave no indication at all how to manage this field or even if it was a constant (which some presume incorrectly).
IETF AVT WG is an open process. All other existing current extension syntax authors are invited to try and make the effort to merge them into a single compatible standard design as part of the process. Although I wish I was aware of this other design sooner in the process, I tried to craft the proposal in this thread so that both could exist concurrently in a well-structured manner. I would welcome other uses to come forward so we could craft a single overall mechanism. We all *know* there are other uses (I found a new one last week), but the burden is on those authors to come forward and make the effort. Lacking other contributions, the WG should make an effort to make the published ones (minimally these two) work as best we can.
I am still trying to avoid an evaluation ("bake-off") of the two designs since it will alienate one of them after the fact, but....you cite "tradeoff" and "proprietary" evaluation criteria to support the 4/4-bit design alone in pursuit of option (a). So if the path forward is to have a technical evaluation of tradeoffs and relative "propriety" to reach option (a), then I would like to understand your conclusions better, especially the one about one being more proprietary than another.
But before we enter into a "bake-off", it is still my view that the best we can accomplish under the circumstances of how 3350 left things is to document what practices we know about (via authors willing to bring them forward) in a clearly discriminating manner, concurrent with a recommendation for all new designs. Please note that I did not try to assert that the other design in this thread as the preferred one - the contrary in fact, deferring to the existing ID's proposal for future designs.
Regards,
Mike
At 12:03 PM 7/26/2007, Magnus Westerlund wrote:Michael A Dolan skrev:Dave and all-
I was hoping to avoid a debate on relative deployment and the value of 4 bits versus 8 bits by proposing option (c) below (which is what I tried to articulate in last week's post). In a perfect world, we would drive to (a), but I don't see how to get there in any reasonable timeline.
Mean-time the world moves on making more of these deployments, and worse, more non-conformant variants we don't even know about....
Can everyone live with option (c)?
Preferably no, this is a core extension that we are likely to see quite a lot of use in the future. I think 4+4 has a good tradeoff. I would like to go with a) because of this to avoid confusing things. If there are "proprieatery" deployment as it is of 8+8 that is not different from other "proprieatery" extensions in this field.
Choices:
a) go with just 4+4 or just 8+8, and drop one. I am aware of implementations of both, so this isn't ideal.
b) in the same document, require support for both.
c) in the same document, require support for one, and recommend support for the other.
d) publish one separately, as an informational RFC.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- 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
-- David Singer Apple/QuickTime
_______________________________________________ Audio/Video Transport Working Group avt at ietf.org https://www1.ietf.org/mailman/listinfo/avt