Subject: RE: [Ltru] Normative vs Informative references

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Mar 2005 12:20:30 -0800

Agreed and done.

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: John Cowan [mailto:[email-masked]]
> Sent: vendredi 18 mars 2005 12:20
> To: Addison Phillips
> Cc: [email-masked]
> Subject: Re: [Ltru] Normative vs Informative references
> 
> Addison Phillips scripsit:
> 
> > The normative references consist of:
> >
> > RFC 1766 (mostly for historical reasons, could be informative)
> > RFC 3066 (obviously)
> 
> 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

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

---

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Mar 2005 15:13:06 -0800

I changed the text as noted below (including the BCP number).
 
Addison

Addison P. Phillips

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: vendredi 18 mars 2005 15:03
> To: [email-masked]
> Hi -
> > From: "McDonald, Ira" <[email-masked]>
> > To: "'Addison Phillips'" <[email-masked]>; "Randy Presuhn"
> <[email-masked]>; <[email-masked]>
> > Sent: Friday, March 18, 2005 2:06 PM
> > Subject: RE: [Ltru] Normative vs Informative references
> >
> 
> > Hi,
> >
> > I would suggest that you add to your 'Security Considerations'
> > section an informative reference to RFC 3552 / BCP 72
> > "Guidelines for Writing RFC Text on Security Considerations".
> >
> > So revise text from:
> >
> > The evaluation of the exact magnitude of the threat, and any possible
> > countermeasures, is left to each application protocol.
> >
> > to:
> >
> > The evaluation of the exact magnitude of the threat, and any possible
> > countermeasures, is left to each application protocol (see [RFC3552]
> > for best practice guidance on security threats and defenses).
> ...
> 
> As a technical contributor, I'd suggest making the citation in terms of
> the BCP number.  Thus:
> 
> | The evaluation of the exact magnitude of the threat, and any possible
> | countermeasures, is left to each application protocol (see BCP 72,
> | RFC 3552 [RFC3552] for best current practice guidance on security
> | threats and defenses).
> 
> The motivation behind BCP and STD numbers is twofold: to be able to
> refer to multi-document sets, and, important in this case, to refer to
> whatever RFC(s) hold the current version of a specification.
> 
> Randy
> 
> 
>

---

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

If we end up wanting ISO 3166-3, we should have a separate reference to that part. 

I see that there is an ISO 3166-1:1997. I'll update the reference to use that (which appears to be most recent).

The RFC 2860 reference I inherited, I think. I only glanced at the text where it is referenced to see if it "looked normative". Your suggestion sounds like a better choice.

Addison

Addison P. Phillips

> Behalf Of Frank Ellermann
> Sent: vendredi 18 mars 2005 17:50
> To: [email-masked]
> Subject: [Ltru] Re: Normative vs Informative references
> 
> Addison Phillips wrote:
> 
> [...]
> > 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.
> 
> 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
> 
> 
>