Re: [rfc-i] Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[RFC Editor]

Hi Julian,

I went through version -08 of the headers-boilerplates document and
attempted to put together all of the possible combinations of text for
the "Status of This Memo."   I believe the attached file is a complete
list of these possibilities, based on the text in Section 3.   

Please note that I have updated the URLs to match that of the existing
metadata pages that were created in response to this document
(http://www.rfc-editor.org/info/rfc).  

The RFC Editor hopes that the IAB will agree to update the URLs
(throughout) and the text in Appendix A to reflect the appropriate
text from the corresponding Stream/Status/Consensus in the attached
file during the editing process.  

Please feel free to check the attached files, as manual error is
possible.

Hope this is of some help! Thanks!

Sandy


On Tue, Nov 24, 2009 at 02:01:56PM +0100, Julian Reschke wrote:
> Hi,
> 
> I just created five test cases representing the appendices A.1 to A.5. 
> Turns out that the text in the examples is not in sync with the 
> definitions in Section 3 (see, for instance, 
> ).
> 
> Best regards, Julian
> 
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >>
> >> 
> >>  
> >> says:
> >>
> >>"Information about the current status of this document, any errata,
> >>and how to provide feedback on it may be obtained at
> >>http://www.rfc-editor.org//rfc.html"
> >>
> >> Can we please recommend *not* to put a file extension into the URL?
> >>
> >> BR, Julian
> >> ...
> > 
> > Hi,
> > 
> > in the meantime I have finished a prototype implementation of the new 
> > boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
> > available from , and 
> > requires the use of two new extension Processing Instructions to enable 
> > the new boilerplate:
> > 
> >   
> >   
> > 
> > (where the first enables the new format, while the second provides the 
> > information about whether there was consensus, something the current 
> > xml2rfc format doesn't provide).
> > 
> > I haven't found any problems in addition to what was reported before, 
> > except for a trailing dot in one of the boilerplate statements, and 
> > cases of repeating sentence beginnings -- maybe all of this can be fixed 
> > during AUTH48 (although I'd prefer to see this in a new draft for 
> > community review).
> > 
> > For the record, here's a complete summary:
> > 
> > -- snip --
> > 3.1.  The title page header
> > 
> >  This describes the area where the work originates.
> >   Historically, all RFCs were labeled Network Working Group.
> >   "Network Working Group" refers to the original version of today's
> >   IETF when people from the original set of ARPANET sites and
> >   whomever else was interested -- the meetings were open -- got
> >   together to discuss, design and document proposed protocols
> >   [RFC0003].  Here, we obsolete the term "Network Working Group" in
> >   order to indicate the originating stream.
> > 
> >   The  is the name of the RFC stream, as defined in
> >   [RFC4844] and its successors.  At the time of this publication,
> >   the streams, and therefore the possible entries are:
> > 
> >   *  Internet Engineering Task Force
> > 
> >   *  Internet Architecture Board
> > 
> >   *  Internet Research Task Force
> > 
> >   *  Independent
> > 
> > JRE: as discussed earlier: should this be "Independent Submission"
> > instead of "Independent"?
> > 
> >[:]  Some relations between RFCs in the
> >   series are explicitly noted in the RFC header.  For example, a new
> >   RFC may update one or more earlier RFCs.  Currently two
> >   relationships are defined: "Updates", and "Obsoletes" [RFC2223].
> >   Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
> >   Other types of relationships may be defined by the RFC Editor and
> >   may appear in future RFCs.
> > 
> > JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".
> > 
> > 3.2.2.  Paragraph 2
> > 
> >The second paragraph of the "Status of This Memo" will now include a
> >paragraph describing the type of review and exposure the document has
> >received.  This is defined on a per-stream basis, subject to general
> >review and oversight by the RFC Editor and IAB.  There is a specific
> >structure defined here to ensure there is clarity about review
> >processes and document types.  These paragraphs will need to be
> >defined and maintained as part of RFC stream definitions.  Initial
> >text, for current streams, is provided below.
> > 
> >The paragraph may include some text that is specific to the initial
> >document category, as follows: when a document is Experimental or
> >Historic the second parag

Re: RIM patents using a mime body in a message (and ignores IETF IPRrules)

[Sabahattin Gucukoglu]

On 19 Nov 2009, at 19:32, Dan Wing wrote:
>> Rescinding RFCs-to-be only based on late disclosures may set 
>> a precedence for the future we may not like.
> 
> Doing so would provide an incentive for the patent holder to delay disclosure
> until after the RFC is issued.
> 
> IETF lacks a censure policy for such violations.  Maybe we need one.

I have a suspicion that part of the problem is that in cases like this one, the 
IETF has demonstrated a will to validate IPR all by itself, which is fine 
except that nowhere that I know of have we publicly expressed our 
dissatisfaction with the vast majority of what passes for "Rescindable", 
preferring instead to do without at the time the disclosure is made.  A BCP 
stating, "Patents are a nuisance, be told, and we'd sooner be without them." 
would seem to suit us well in cases where outsiders might otherwise be tempted 
to play fast and loose with the rules, perhaps this would encourage more 
upfront disclosures and, thereby, acceptance of reasonable and 
non-discriminatory IPR.  And can the IETF deny its preference for non-patented 
work?

I take no sides myself, I just want us to live in peace and harmony.

Cheers,
Sabahattin

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-ietf-idnabis-tables

[Patrik Fältström]

This is taken care of in upcoming version (-08) of the document.

   Patrik

On 17 okt 2009, at 17.50, Bernard Aboba wrote:

> I reviewed draft-ietf-idnabis-tables-07.My comments are enclosed below. 
> 
> 
> 
> Technical
> 
> 
> 
> Section 5.1
> 
> 
> 
>   IANA is to keep a list of the derived property for the versions of
> 
>   Unicode that is released after (and including) version 5.1.  The
> 
>   derived property value is to be calculated according to the
> 
>   specifications in sections Section 2 and Section 3 and not by copying
> 
>   the non-normative table found in Appendix B.  
> 
> 
> 
> [BA] This seems to imply that IANA will do the calculation itself,  rather
> 
> Than just registering the results of a calculation made by someone else.  
> 
> Is that correct? 
> 
> 
> 
> Editorial
> 
> 
> 
> Section 1
> 
> 
> 
>  For example, a
> 
>   character can have its Unicode General_Category value change from So
> 
>   to Sm, or from Lo to Ll, without affecting the algorithm results.
> 
>   Moreover, even if such changes were to result, the BackwardCompatible
> 
>   list (Section 2.7) can be adjusted to ensure the stability of the
> 
>   results.
> 
> 
> 
> [BA] Lo and L1 are not defined until the next section.  Would it make sense
> to define these terms earlier on? 
> 
> 
> 
>   Some code points need to be allowed in exceptional circumstances, but
> 
>   should be excluded in all other cases; these rules are also described
> 
>   in other documents.  The most notable of these are the the Join
> 
> 
> 
> [BA] "the the" -> "the"
> 
> 
> 
> Section 5.1
> 
> 
> 
>  in sections Section 2 and Section 3
> 
> 
> 
> [BA] Should this be "Sections 2 and 3"?
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: If you found today's plenary debate on standards track tedious...

[Cullen Jennings]

On Nov 11, 2009, at 5:33 AM, Richard Barnes wrote:

> 
> From the perspective of the world outside the IETF, this is already the case. 
>  An RFC is an RFC is an RFC...
> --Richard
> 

+1

As far as I can tell, 3GPP treats information and experimental RFC the same as 
standards track just to give you an idea of even how some of the outside world 
that does standards views the IETF

And let me add to the comment about SIP being PS ... some of the most deployed 
SIP RFCs are informational. 


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: I-D Action:draft-housley-iesg-rfc3932bis-12.txt

[Julian Reschke]

Julian Reschke wrote:

...
JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?
...


To illustrate the problem: for "IETF Experimental, with Consensus Call", 
we get:


"This document defines an Experimental Protocol for the Internet 
community. This document is a product of the Internet Engineering Task 
Force (IETF). It represents the consensus of the IETF community..."


I think

"This document defines an Experimental Protocol for the Internet 
community. It is a product of the Internet Engineering Task Force (IETF) 
and represents the consensus of the IETF community..."


would read much better.

Best regards, Julian


___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Important: do not publish "draft-iab-streams-headers-boilerplates-08" as is!

[Julian Reschke]

Hi,

I just created five test cases representing the appendices A.1 to A.5. 
Turns out that the text in the examples is not in sync with the 
definitions in Section 3 (see, for instance, 
).


Best regards, Julian

Julian Reschke wrote:

Julian Reschke wrote:


 
says:


   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

Can we please recommend *not* to put a file extension into the URL?

BR, Julian
...


Hi,

in the meantime I have finished a prototype implementation of the new 
boilerplate in rfc2629.xslt (*not* xml2rfc!). The implementation is 
available from , and 
requires the use of two new extension Processing Instructions to enable 
the new boilerplate:


  
  

(where the first enables the new format, while the second provides the 
information about whether there was consensus, something the current 
xml2rfc format doesn't provide).


I haven't found any problems in addition to what was reported before, 
except for a trailing dot in one of the boilerplate statements, and 
cases of repeating sentence beginnings -- maybe all of this can be fixed 
during AUTH48 (although I'd prefer to see this in a new draft for 
community review).


For the record, here's a complete summary:

-- snip --
3.1.  The title page header

 This describes the area where the work originates.
  Historically, all RFCs were labeled Network Working Group.
  "Network Working Group" refers to the original version of today's
  IETF when people from the original set of ARPANET sites and
  whomever else was interested -- the meetings were open -- got
  together to discuss, design and document proposed protocols
  [RFC0003].  Here, we obsolete the term "Network Working Group" in
  order to indicate the originating stream.

  The  is the name of the RFC stream, as defined in
  [RFC4844] and its successors.  At the time of this publication,
  the streams, and therefore the possible entries are:

  *  Internet Engineering Task Force

  *  Internet Architecture Board

  *  Internet Research Task Force

  *  Independent

JRE: as discussed earlier: should this be "Independent Submission"
instead of "Independent"?

   [:]  Some relations between RFCs in the
  series are explicitly noted in the RFC header.  For example, a new
  RFC may update one or more earlier RFCs.  Currently two
  relationships are defined: "Updates", and "Obsoletes" [RFC2223].
  Variants like "Obsoleted by" are also used (e.g in [RFC5143]).
  Other types of relationships may be defined by the RFC Editor and
  may appear in future RFCs.

JRE: "Obsoleted By" is not a variant of "Obsoletes" or "Updates".

3.2.2.  Paragraph 2

   The second paragraph of the "Status of This Memo" will now include a
   paragraph describing the type of review and exposure the document has
   received.  This is defined on a per-stream basis, subject to general
   review and oversight by the RFC Editor and IAB.  There is a specific
   structure defined here to ensure there is clarity about review
   processes and document types.  These paragraphs will need to be
   defined and maintained as part of RFC stream definitions.  Initial
   text, for current streams, is provided below.

   The paragraph may include some text that is specific to the initial
   document category, as follows: when a document is Experimental or
   Historic the second paragraph opens with:

   Experimental:  "This document defines an Experimental Protocol for
  the Internet community."

   Historic:  "This document defines a Historic Document for the
  Internet community."

JRE: the way paragraph 2 is generated, we end up with instances where
the 1st and 2nd sentence both start with "This document". This is ugly.
Is it too late to fix this?

  In addition a sentence indicating the consensus base within the
  IRTF may be added: "This RFC represents the consensus of the
   Research Group of the Internet Research Task Force
  (IRTF)." or alternatively "This RFC represents the individual
  opinion(s) of one or more members of the  Research
  Group of the Internet Research Task Force (IRTF)".

JRE: trailing dot missing in 2nd variant.


3.2.3.  Paragraph 3

   "Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org//rfc.html"

JRE: please do not bake a file extension into the permanent URL (see also
)

-- snip --

Best regards, Julian





___
Ietf mailing list
Ietf@ietf.org
https: