Subject: RE: [Ltru] Normative vs Informative references

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Mar 2005 11:56:48 -0800

I have split the references into informative and normative.

I have eliminated the following dead references:

RFC 1327
RFC 1521
RFC 3639
RFC 2616 (is cited by the matching draft)
RFC 2396

The informative references consist of two items:

ISO 639 Principles (referenced in a note in section 2.2.1)
RFC 2231 (MIME parameter values, cited as an example in Section 2.1.1)

The normative references consist of:

ISO 639-1:2002
ISO 639-2:1998
ISO 15924:2003
ISO 3166:1988
UN M.49
RFC 1766 (mostly for historical reasons, could be informative)
RFC 2026 (obviously)
RFC 2028 (organizations involved in ietf process)
RFC 2119 (normative language)
RFC 2234 (ABNF)
RFC 2434 (writing IANA considerations sections)
RFC 2860 (defined IANA)
RFC 3066 (obviously)
RFC 3339 (defines ISO 8601 and the date format used in the registry)

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: vendredi 18 mars 2005 11:18
> To: [email-masked]
> Subject: Re: [Ltru] Normative vs Informative references
> 
> Hi -
> 
> (as a technical contributor)
> 
> > From: "McDonald, Ira" <[email-masked]>
> > To: "'Scott Hollenbeck'" <[email-masked]>; "'Frank Ellermann'"
> <[email-masked]>; <[email-masked]>
> > Sent: Friday, March 18, 2005 10:33 AM
> > Subject: [Ltru] Normative vs Informative references
> ...
> > Separating references has a more important impact - it makes
> > clear where the main body text should have a section labelled
> > something like '4.2 Blazzle (Informative)', because all of the
> > dependencies are informative.
> 
> Although I agree that informative sections of material benefit
> from being clearly labeled, one cannot use the absence of
> normative references in a section to characterize that section
> as non-normative.
> 
> For example, a section could read:
> 
> Implementations MUST do X in situation Y.  For an explanation
> of why this is required, see the analysis in section Z of
> [unrelated-protocol-informative-reference].
> 
> This would be perfectly good normative material, with a perfectly
> good informative reference.
> 
> > Also, the list of normative references should stay short!
> 
> If possible.
> 
> ...
> > PS - If other working group members contribute text, please
> > specify the references as normative or informative right then.
> ...
> 
> Good suggestion.  Note however, that some references to a particular
> specification might be informative, and others normative.  If *any* of
> the references to a specification are normative, then it goes into the
> normative references section.
> 
> Randy
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: John Cowan <[email-masked]>
Date: Fri, 18 Mar 2005 15:19:37 -0500

> RFC 1766 (mostly for historical reasons, could be informative)

These should be informative, not normative.  Making them normative implies
that you can't understand the new document without referring to them,
which is untrue.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 [email-masked]
 I wish it were impossible."                    http://www.ccil.org/~cowan

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Mar 2005 12:36:50 -0800

Hi -

(as technical contributor)

> From: "John Cowan" <[email-masked]>
> To: "Addison Phillips" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, March 18, 2005 12:19 PM

...

Agreed.   The references to both are informative.  The passages where the
string "3066" occurs that seem to have the most normative weight refer to
the registrations that have happened under that regime, rather than the
document itself.

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 19 Mar 2005 02:50:13 +0100

> The normative references consist of:
 
[...]
> ISO 3166:1988

I'd prefer a newer edition, maybe we want 3166-3 later as a
source for canonical values where UN M.49 doesn't help (like
DDDE, YDYE, etc.)  And their public Web site corresponds to
their 5th edition.

> RFC 1766 (mostly for historical reasons, could be

Yes, informative, maybe the same for RfC 3066 as John said.
As long as you stick to "obsoletes 3066" that's no problem.

> RFC 2860 (defined IANA)

That's an informational RfC with the MoU between the IETF and
ICANN about IANA, not what I'd consider as "normative".  Your
BCP 11 (RfC 2028) reference is IMHO good enough to define IANA,
if you replace IANA [17] => 2860 by IANA [10] => BCP 11 in 2.2.

                            Bye, Frank

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 18 Mar 2005 18:14:11 -0800

Hi -

As a contributor...

> From: "Frank Ellermann" <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, March 18, 2005 5:50 PM
> Subject: [Ltru] Re: Normative vs Informative references
...
...

We don't need to say very much *about* IANA.  It's understood to the
point of being one of those few well-known acronyms (like IP) that don't
need to be expanded on first use.  After all, an "IANA Considerations"
section is required for any internet draft needing IESG approval
to become an RFC.  For details, see http://www.ietf.org/ID-Checklist.html
section 2.2 (7).

Randy

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 19 Mar 2005 07:21:53 +0100

Randy Presuhn wrote:
 
> We don't need to say very much *about* IANA.

Sure, but IFF we'd want it, then BCP 11 already used elsewhere
as reference also explains IANA and IESG.  I've checked what
similar BCPs do (charsets, headers, URNs), most mention 2026,
one mentions 2028, none has 2860.

> It's understood to the point of being one of those few
> well-known acronyms (like IP) that don't need to be expanded
> on first use.

We should create en-Latn-US-ietf as show case.  Of course it's
fine to say IANA without reference.  Only IANA [17] could be a
trap if the IANA MoU in [17] is "normative" and modified later.

> an "IANA Considerations" section is required

And IANA probably knows what it is without a normative 2860 ;-)

                        Bye, Frank