RE: [AVT] Re: Working group last call: draft-ietf-avt-evrc-smv-00.txt

> Not exactly, because that means the guy who wants to use only the
> "MAY" format would still have to implement both to be compliant.  I
> believe it would be acceptable for the specification to say that both
> formats SHOULD be implemented to maximize interoperability.  My
> objection is to the statement that receivers MUST implement both.
>
> Then, because implementations may need to decide on accepting an SDP
> offer based on which of the two formats is proposed, the two formats
> should be identified by separate MIME subtypes rather than by a
> parameter of a single subtype.

Hi Steve,

I do see very well your concerns on this issue.

(1) It does seem a little bit awkward to require that both format must be
supported when the wireless nodes will probably always use only one of them.

However, I am not sure changing that word to "SHOULD" is going to either
make it look much better or eliminate the interoperability problem
completely. Probably it achieves neither goal. Take for example (sorry for
another example :-)), I guess the authors of RTP RFC are probably regreting
that maybe they should put a "MUST" in that RFC for RTCP instead of a
"SHOULD". The RTCP issue has constantly come up on this reflector. Changing
the "SHOULD" to "MUST" for RTCP now will create much trouble for the
existing implementations, but I am guessing the authors' and many people
here probably incline toward a "MUST" indeed. "Implementing some basic RTCP
is not that hard after all, right?" I heard people argue.

All it takes to add Type 1 support on top of Type 2 support (or vice versa)
for EVRC/SMV is to skipping a two octet header. "ptr += 2". My opinion is
that is a very small price to pay compare to the potential trouble and the
potential regret in the future. Just my personal opinion though, and I am
open to hear all suggestions on this. If a "SHOULD" is what people thinks it
should be, I am allright with it.

(2) About whether the type should be indicated by MIME subtype or a
parameter, I am not sure about that either. So, are we going to have two
MIME subtype - EVRC1 and EVRC2?

That seems to complicate the negotiation process quite a bit. Now two
seperate sets of parameter can be exchanged. Even after two terminals agree
on one, there could be another more efficient setup. Also, there is still
such probablity that two terminals will not talk to each other, even they
speak the same codec and using the same RFC. The storage mode of the two
subtype are exactly the same, but an implementation will have to register
itself twice for both types. Besides, it seems there is no precedent of this
type of double subtype before for all the payload types here.

Things seem to be so much simpler if we have the "MUST" and a single
subtype. Each terminal announces once and there is no guess work on what the
other side can do. And the cost for that seems to be quite minimal. Again,
this is just my personal opinion, and I am very open to further discussions.

Adam

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt