Hi,
IETF standards track documents are strong recommendations on how to
solve a problem. In many case that doesn't rule out the existence
of other solutions. However, it may hurt interoperability and/or
complicate implementations. There is no protocol police that goes
ut and stop usage that doesn't follow IETF. In addition the header
extension mechanism in RTP is free to use by anyone. So 8+8 is
definitely conformant to RFC 3550. One has only to be aware of the
limitations they result in. But the desirable future is that anyone
in the future that needs this functionality will use RFC XXX (what
ever the number will be for draft-ietf-avt-hdrext).
As I see it the best we can do for the future is to select one
solution and go forward. And hope that most future users out there
uses that single solution. That is in my view the best way and will
maximize interoperability in the future. I can also hope that some
that uses their own extension mechanism will move to the IETF
defined one.
Which is why I think I would like to document them in one document,
> with 4+4 support required and 8+8 documented and mentioned and
> support for it optional.
I hope that it is clearer why I propose to select only a single one
and stick with that. I don't want to have two of them in the
document because that will result in that everyone will have to
implement both. IETF has become worse and worse at selecting a
single solution and sticking with it. I asked the question about
deployement, because as I see it there are some difference in the
technical tradeoff but if you had a large deployement that would
still be compatible with the tag value mechanism in the current WG
document then I think it would have been reasonable to switch to
the 8+8 tradeoff. However, as you aren't forthcomming with that
information there is no data to for determinging that 8+8 would be
a more reasonable choice then 4+4. I am also worried about the ID
numberspace and control over that.
I am worried about the 8+8 ID namespace that may make it difficult
to adopt. draft-ietf-avt-hdrext contains a larger namespace that is
mapped onto the ID values. This as 16 values would never last. But
the same is also true for 256 values. Thus the same rule could be
applied. However, that requires that IETF gets full control of at
least a substantial block of the field values. There must be full
agreement between the original definers and IETF that control is
transfered. In addition it must be known which values are used and
already handed out. The only alternative for a 8+8 solutio would be
to go with another header extension identifier.
Because of that I would propose that we go forward with a document
that only provides the 4+4 solution.
Dave Singer skrev:
If that is a problem, how about we add a sentence to the 4+4 spec.
saying "A variant of this design, using 8-bit length and tag
fields, also exists, using a different value for the field that
takes the value 0xBEDE here."?
There might be value in pointing out that there exist similar but
not IETF defined solutions for the header extension field. However,
I wonder if it would confuse more then any benefit it gives. But my
attempt is the following:
"At least one similar solution is known to exist for solving the
first drawback. That solution uses different field lengths, but
also another 16-bit identifier value, thus no risk of misstake
between them exist. The resolution of the second drawback and
slightly differnt tradebacks resulted in the solution present in
this document."
The above is written based on that the solution you documents did
not try to resolve the namespace issues to provide an basically
unlimited number of header extensions.
I might have not given the impression before that there is benefit
in document the 8+8 solutions that are in use. I think it would be
best that it is documented in an informational RFC. However, I
would like to see good wording in there that this is a
documentation of something that is used, but that it is prefered to
use draft-ietf-avt-hdrext.
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