[rfc-i] draft-iab-xml2rfc-03, "2.11 <boilerplate>"

Joe Hildebrand (jhildebr) jhildebr at cisco.com
Tue Mar 15 09:16:24 PDT 2016


On 3/14/16, 4:06 PM, "Paul Kyzivat" <pkyzivat at alum.mit.edu> wrote:



>> Requested changes can only be applied to documents published after the change.  Otherwise, there is no way for the authors to agree to them.  If the IESG or the Trust feels really strongly about the change, a new document can always be published that obsoletes the previous document and includes the new boilerplate, same as for the .txt-based stream today.
>
>That seems reasonable. How will that be managed? Doesn't there need to 
>be something that correlates the xmL with the formatters that can be 
>used to render it?

I was envisioning this as:

- we add new boilerplate rules, which MAY be used during a 
  transition period, and SHOULD after that
- we add a new ipr attribute value to supersede "trust200902"
- support for the new attribute and boilerplate is added to the tooling
- I-D tooling and RPC update to the new version
- "it's time to start using the new IPR rules" is announced by 
  stream owners
- authors start using the new attribute, updating their tooling when 
  they find they have the wrong version that doesn't support that rfc/@ipr
- once we have implementation experience, the tooling is changed to 
  warn on old rfc/@ipr values
- at some point, the old values may be treated as errors, at the 
  discretion of the stream owners

(note to Paul: the v3 schema needs to be modified to allow new rfc/@ipr values in the future, from a list on a web page under control of the RFC editor)

>IOW, if the IAB made such a change in the future, will the subsequent 
>xml be tagged accordingly, with the formatters being sensitive to such tags?

Hopefully the steps above would make the change *very* explicit, under author control, and subject to the policy choices of the stream owners.

-- 
Joe Hildebrand


More information about the rfc-interest mailing list