Re: draft-ietf-avt-rtp-amr-13.txt -- please include link to source code

James, Magnus,

In general, to think a URL will remain stable over the lifetime of an
RFC is somewhat ludicrous.  Just try to follow the URLs that are in
listed in many current RFCs and see how far you get.

As for ETSI, they have redesigned their directory structure at least
twice in the last few years.  About the only URL that you can count on
to remain stable is "www.etsi.org".

In fact, the URL may not even be *available* in the future.  Until just
2 or 3 years ago you had to pay for ETSI documents (similar to the ITU
now).  And ETSI reserves the right to resume charging a fee in the
future.

Also, as many people have already said, a link to a specific version is
a bad idea as well, since ETSI issues updates *VERY FREQUENTLY* (GSM
06.10 has been released 14 times in the last decade!) under its
different release schemes.

So in this case, using a URL link as a normative reference is a good way
to ensure that people will be cursing your name in a few years. :)

Finally, why should there be a URL reference at all?  I have seen many
references to ISO 10646 and to ITU-T G.726 in different IETF documents,
yet I have to see a URL link to them included in RFCs.  So why should
there be one here?  Just because it is source code?  That doesn't
matter; text is text regardless of its media.  You want a link to make
it easier to find?  That won't work:  the URL is entirely unstable, and
will point to possibly outdated versions.  The proper reference you want
is "3GPP TS 26.093" that is available from ETSI, and include its version
number if you want.  People can start at www.etsi.org and search from
there.  Doing anything more specific than is guaranteed to make the
reference worthless in a short time.

Jeff


Colin Perkins wrote:
> 
> Magnus, James,
> 
> Adding a non-normative pointer to the reference codec would seem to be
> reasonable, but we should ensure that any URL is stable and unlikely to
> change over the lifetime of the RFC.
> 
> Colin
> 
> --> Magnus Westerlund writes:
> >James,
> >
> >Well, lets try to add this during the authors 48 hours. Below is a
> >proposal for changes in the spec for the WG and authors to consider.
> >This will inform the reader that there exist reference implementations.
> >I also included links to the correct directory.
> >
> >How to do with the MIME section I am not sure. The reason is that the
> >reference codec implementation  is not directly capable of handling in
> >the file format specified to be used by the MIME type. I would also like
> >the scenario to be as simple as you picture it. But even with the
> >reference implementation it is at least a couple of days of work to get
> >a working implementation even in a nice framework. So is something more
> >informative than the current, go look in the payload format
> >specification, needed?
> >
> >Regards
> >
> >Magnus W.
> >
> >
> >Adding a single sentence to the following paragraph:
> >
> >3.1. The Adaptive Multi-Rate (AMR) Speech Codec
> >
> >   The AMR codecs was originally developed and standardized by the
> >   European Telecommunications Standards Institute (ETSI) for GSM
> >   cellular systems. It is now chosen by the Third Generation
> >   Partnership Project (3GPP) as the mandatory codec for third
> >   generation (3G) cellular systems [1]. A reference implementation
> >   is available in either floating-point code [25] or fix-point code
> >   [26].
> >
> >Adding a single sentence to the following paragraph
> >
> >3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec
> >
> >   The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was
> >   originally developed by 3GPP to be used in GSM and 3G cellular
> >   systems. A reference implementation is available in either
> >   floating-point code [27] or fix-point code [28].
> >
> >
> >Add to the reference section 11.1 the following
> >
> >   [25] 3GPP TS 26.104, "ANSI-C code for the floating-point Adaptive
> >        Multi-Rate (AMR) speech codec", version 4.3.0 (2002-03),
> >        3rd Generation Partnership Project (3GPP),
> >        "ftp://ftp.3gpp.org/specs/latest/Rel-4/26_series/".
> >
> >   [26] 3GPP TS 26.073, "AMR speech Codec; C-source code", version
> >        4.1.0 (2001-12), 3rd Generation Partnership Project (3GPP),
> >        "ftp://ftp.3gpp.org/specs/latest/Rel-4/26_series/".
> >
> >   [27] 3GPP TS 26.204, "ANSI-C code for the floating-point Adaptive
> >        Multi-Rate (AMR) wideband speech codec", version 5.0.0
> >        (2002-03), 3rd Generation Partnership Project (3GPP),
> >        "ftp://ftp.3gpp.org/specs/latest/Rel-5/26_series/".
> >
> >   [28] 3GPP TS 26.173, "ANSI-C code for the Adaptive Multi Rate (AMR)
> >        Wideband speech codec", version 5.4.0 (2002-03),
> >        3rd Generation Partnership Project (3GPP),
> >        "ftp://ftp.3gpp.org/specs/latest/Rel-5/26_series/".
> >
> >
> >
> >James Salsman wrote:
> >
> >> Magnus,
> >>
> >> Thank you for your reply:
> >>
> >>> I am not convinced that a informative reference to the implementation
> >>> directly from the payload format is necessary. There exist ways of
> >>> finding the reference implementation, it is for example referenced in
> >>> the AMR main spec TS 26.090. If the draft was not approved and in the
> >>> rfc-editors queue I would be less inclined to avoid doing this change.
> >>
> >>
> >> The worst that can happen is that you will be the author of two RFCs
> >> instead of one. Would you rather ask the editors for an additional
> >> reference included (not a huge request) or would you rather be the
> >> author of a mime type registration that could have had a pointer to
> >> working code but didn't? Trust me, including working code is something
> >> that the rfc editors really like, because the audience loves it.
> >>
> >> Imagine these two scenarios. Joe Random Tech gets a message with MIME
> >> type Audio/AMR or audio/amrnb and so he goes to the MIME type
> >> registration
> >> and sees that [scenario 1:] the source code may or may not be available
> >> or [scenario 2:] the source code is a few (dozen key)clicks away. Which
> >> is the superior RFC user experience? Which is the superior
> >> interoperability experience for your company's products?
> >>
> >>> A direct link to to the specification is anyway out of the question. The
> >>> reason is that the specification may be changed in the future and then a
> >>> new version number will be given. Somebody may find a bug in the
> >>> reference implementation (not that unlikely) and a change request is
> >>> sent in. It that change request is approved the updated specification
> >>> will be given the version number 4.2.0 which will result in that the
> >>> filename becomes 26073-420.zip. Due to this a direct link can not be
> >>> used.
> >>
> >>
> >> Unless the old versions are going to be deleted, it would be nice to get
> >> the reference code. The idea of a multi-rate vocoder is a very important
> >> one, and I feel it is very important to allow quick access to code for
> >> those who might have any influence on its development, e.g., most people.
> >>
> >>> Magnus Westerlund
> >>>
> >>> Multimedia Technologies, Ericsson Research ERA/T/VA
> >>> ----------------------------------------------------------------------
> >>> Ericsson Radio Systems AB | Phone +46 8 4048287
> >>> Torshamsgatan 23 | Fax +46 8 7575550
> >>> S-164 80 Stockholm, Sweden | mailto: [email protected]
> >>
> >
> >
> >
> >
> >_______________________________________________
> >Audio/Video Transport Working Group
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email protected]
> https://www1.ietf.org/mailman/listinfo/avt
----------------------------------------------------------
This message was sent to you, since you are subscribed to
[email protected]. You can manage your subscription at
http://www.neystadt.org/cgi-bin/majordomo