Introduction
In reviewing the standards work that has been and is being done in the SCTE
Subcommittees, it is clear that one of the most difficult areas to get right is referencing.
The purpose of this paper is to clarify how references should be included in SCTE
standards.
References are essential to the development of standards. Using references makes for
shorter, more concise documents; higher accuracy when the same information must be
used in many places; and elimination of the problems associated with trying to use
information which is the intellectual property of some other organization. In this paper
we will cover general good practices; options for specifying normative references; how to
deal with patents and licenses; and how to deal with standards which reference each
other.
General
It is essential that a separate section be included in each standard that lists all the
references to other documents. These should be separated into two categories –
normative references and informative references.

Normative references have the same ‘mandatory’ nature as the basic standard.
In other words, the effect is exactly the same as if the document were to be taken
in whole and placed within your standard. Implementations which are said to
conform to the standard must conform to all of the mandatory parts of the
reference. Normative references are by far the most important, since they
mandate conformance. Unclear or conflicting references could be a factor in
legal action where a vendor claims conformance with your standard and the
customer believes that the claim is inaccurate. So it is critical that the
references are done correctly.

Informative references are provided for the education or convenience of the
user of the standard. Like informative clauses in standards, they are not required
for implementation.
There are several basic things to remember about references when you include them in
your standard. In the reference section 
Make sure that title, version, etc. is complete and accurate. Don’t assume that
everybody will know the details. Where there are internal and external
designations, use the external one. (SCTE 41 2002 for example, not DVS
301r1.)

Make sure that the reference is to the latest available/approved document unless
you specifically want to use an earlier version. (And if you do, it’s a good idea to
note that fact in the reference section.) This is very important when revising a
standard, since it is likely that many of the references will have new versions
available.

Make sure that the reference is reasonably available. This means that you can
actually get it from someone at a reasonable price and that there are no other
onerous terms and conditions associated with simply reading it. Provide
sufficient information for the reader to obtain the document.

Check the normative references in any normative reference! In the absence of
any statement to the contrary, the entire reference chain becomes normative in
your standard.
In the body of the document 
Make sure that the reference is used at least once. There have been a number
of instances where a document was listed as a normative reference, and then
was never referenced in the body of the text. When this happens, it is likely that
the reference should never have been normative.

Make sure that the reference is specific as to which part of a normative reference
is being used. Failure to do makes the entire document normative, and this may
result in the inclusion of features that you did not intend to incorporate.
Reference version control
All references must be exact as to the reference that is being used. There are two ways
of doing this: a reference to a specific incarnation of a document, or a reference to the
most recent version.
The issue that the developer must deal with is that the document referenced will change
over time as its developer maintains and enhances it. This independent work may take
the document in directions that were not foreseen when the reference was used. For
this reason, the preferred way is to make the reference to a specific version – this will be
identified with a date, a version number, an edition, or similar control information. (Some
items, such as Internet Engineering Task Force (IETF) RFCs do not need
supplementary information because their replacements have different numbers). When
this kind of specific reference is included the standards writer knows that it will always
have the same content – and while it may become obsolete from the point of view of its
owner, your standard will not be affected. Their are two drawbacks to this approach.
First, improvements in the referenced document which create a new version may be
desirable in your standard, but you will have to revise (and reballot) yours to take
advantage of the new document. And second, continued reliance on ‘old’ versions may
lead to the point where the referenced document is no longer available.
The other approach to a reference is to simply state that the reference is to the latest
available version of the document. Now the advantage is that you do not have to keep
watching for new versions, and you do not have to revise your own standard to take
advantage of newer versions. However your standard is subject to changes in the
direction of the referenced document, and you may find that your standard has
normative aspects that are undesirable or even conflicting due to changes in the
referenced documents.
It is up to the standards developer to select how each reference should be done based
on the stability of the referenced document and the best information about how it might
proceed in the future. Specific references are preferred because control over content is
maintained; but there is no objection to using ‘latest’ references where the situation
dictates.
Patents and Licenses
SCTE standards may, under certain conditions, have intellectual property embodied in
them such that a product implementation which conforms to the standard may require a
license or other legal arrangement with the IP holder. This is most often a patent. The
existence of such patents should be identified, and patent declarations are required
according to SCTE policy. However the patent itself may, if necessary, be included as a
reference since the use of the patent as a document requires no arrangements.
Under normal circumstances a simple reference to someone else’s document does not
create an intellectual property considerations. However there are some instances where
the owner of the document requires additional agreements (e.g. a license where the
document recipient must agree to certain things, or a non-disclosure agreement) in order
to have access to the text. This is acceptable so long as the conditions for obtaining the
document are, like patents, fair and non-discriminatory. As with patents, SCTE is not
responsible for determining whether the conditions are met; this is a matter between the
parties.
Standards that reference developing standards
It is sometimes necessary for developing standards to have references to other
standards still in development. There are three cases.
The simplest case is a unilateral reference; where your standard needs to reference
another SCTE standard that is under development and which may not be finally
approved until after yours gets final approval. This approach is discouraged since it
gives a de facto approval outside of the regular process. However if it is necessary, it
may be included. When this happens, the referenced draft will be provided on the web
site through the Reference Resource spreadsheet available on the Standards Available
page. Standards writers are cautioned, however, that references to drafts may
introduce problems in conformance determination that could result in legal action
between parties. Users of draft standards as references are asked to revise their own
standards as soon as the official version is approved to avoid the simultaneous
availability of various versions of SCTE standards.
There are also several bilateral reference possibilities. One of the most common is
where there is a product standard and an associated test procedure, and the author of
the test procedure wishes to reference the product standard in order to tell the reader
where the test will be used. This kind of bilateral reference is generally not acceptable.
The product standard will define the tests that have to be performed, and these might
include references to specific test standards. However the test procedure standard must
be independent of the product specification (and still useful when product specifications
change) and should therefore have no normative references back to the product. In
cases like these, it is suggested that a general reference be made to “standards for
products” so that interested parties can get additional information.
The most difficult case is where two standards are interdependent; where they each
require the other to be completed in order for the references to be correct, although the
development process is being carried on in two groups. This could happen, for example,
where both standards are being revised and content from one is moving into the other.
In this case, the use of drafts is not acceptable. Under this circumstance, the two
standards should be balloted at exactly the same time, with the understanding that a
negative vote on one of them for technical reasons is to be treated as a negative vote on
the other for a faulty normative reference. The two groups will then have to coordinate
any revisions and withdrawal of negatives.