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

[Stephen Casner <[e-mail]>]

Adam,

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

I agree, it does not eliminate the interoperability problem.  But I
also believe it does not make the problem worse.  The interoperability
problem stems from the fact that all parties concerned could not agree
on a single format for all uses.  Hence, there are two formats and the
possibility/probability that some implementations will support only
the one that is appropriate for their perceived application
environment.  This will be true whether the draft says MUST or
SHOULD.

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

The revision of the RTP RFC does _not_ change from SHOULD to MUST
precisely because it would not be appropriate to increase the
requirement level for existing applications, and because there are
applications in which sending RTCP (from all receivers) is infeasible
or impossible.

But this example is not relevant to the question for the EVRC/SMV
draft because 1) draft is not published yet, and 2) we're talking
about changing MUST to SHOULD.

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

That is why I say SHOULD, not MAY.  But for an implementation in an
environment where only one of the formats is feasible, e.g., if
zero-byte header compression must be used, then it is not reasonable
for the spec to say the implementation MUST include both as it does
not meet the constrainst of RFC 2119 for that term.

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

I would like to hear other opinions beyond mine and the authors'.

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

I disagree.  Two sets of parameters must be exchanged in either case
because the payload type must be bound to a particular format type:

     a = rtpmap:97 EVRC    \            /    a = rtpmap:97 EVRC1
     a = fmtp:97 ptype=1    \          /
                             >  -OR-  <
     a = rtpmap:98 EVRC     /          \     a = rtpmap:98 EVRC2
     a = fmtp:98 ptype=2   /            \

> Even after two terminals agree on one, there could be another more
> efficient setup.

I don't know what this means.

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

I agree.  I addressed the root of that problem above.

> The storage mode of the two subtype are exactly the same, but an
> implementation will have to register itself twice for both types.

No, the storage mode should be registered for only one of the types.
Since the storage mode has a TOC byte, I would say it makes most sense
for this to go with type 1.  The other registration would be for RTP
transport only.

I would not use "EVRC1" and "EVRC2".  I think "EVRC" is the right name
for type 1 and for storage.  The type 2 could be EVRC-ZERO or EVRC0 or
whatever you (authors) decide is appropriate.

> Besides, it seems there is no precedent of this type of double
> subtype before for all the payload types here.

RFC 2250 is the precedent:  MPA + MPV, or MP1S, MP2T, MP2P.

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

It would be even simpler with only one format.

							-- Steve


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