Subject: [xml2rfc] checking I-D references vs tools.ietf.org
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jan 4 03:07:37 2007

Hi,

I just updated check-references.xslt (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>) 
so that it uses the status information recently made available on 
tools.ietf.org to check Internet-Draft references (Henrik, thanks for 
the good work).

Best regards, Julian

(full download: <http://greenbytes.de/tech/webdav/rfc2629xslt.zip>)
>From dbharrington at comcast.net  Thu Jan  4 09:10:55 2007
From: dbharrington at comcast.net (David B Harrington)
Date: Thu Jan  4 06:14:13 2007
Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Let me point that the web service uses the old boilerplate.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwyn Davies
> Sent: Thursday, December 21, 2006 10:19 AM
> To: xml2rfc mailing list
> Cc: Leslie Daigle; Tools Team Discussion
> Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
> 
> Hi.
> 
> It has just been pointed out to me that the current stable release
of 
> xml2rfc (v1.31) does not implement the RFC4748 boilerplate 
> updates (IETF 
> Trust).
> They have been put into v1.32pre2.
> 
> Would it be possible to do a maintenance update to 1.31 since 
> we are now 
> supposed to be using the new boilerplate?
> 
> Merry Christmas
> /Elwyn
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jan  4 06:43:10 2007
Subject: [Tools-discuss] RE: [xml2rfc] xml2rfc v1.31 and RFC4748
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

David B Harrington schrieb:
> Let me point that the web service uses the old boilerplate.
> 
> dbh 

<http://xml.resource.org/experimental.html> should use the current one.

Best regards, Julian
>From brc at zurich.ibm.com  Thu Jan  4 15:45:40 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Thu Jan  4 06:45:47 2007
Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-01-04 15:10, David B Harrington wrote:
> Let me point that the web service uses the old boilerplate.

http://xml.resource.org/experimental.html is your friend

     Brian

> 
> dbh 
> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Elwyn Davies
>> Sent: Thursday, December 21, 2006 10:19 AM
>> To: xml2rfc mailing list
>> Cc: Leslie Daigle; Tools Team Discussion
>> Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
>>
>> Hi.
>>
>> It has just been pointed out to me that the current stable release
> of 
>> xml2rfc (v1.31) does not implement the RFC4748 boilerplate 
>> updates (IETF 
>> Trust).
>> They have been put into v1.32pre2.
>>
>> Would it be possible to do a maintenance update to 1.31 since 
>> we are now 
>> supposed to be using the new boilerplate?
>>
>> Merry Christmas
>> /Elwyn
>>
>>
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From mrose at dbc.mtview.ca.us  Thu Jan  4 11:08:26 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Jan  4 11:08:34 2007
Subject: [xml2rfc] xml2rfc v1.31 and RFC4748
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

here's a question:

is there anything deficient in 1.32pre2?

if not, it's a good time to promote that to production.

/mtr

From: Jeff.Hodges at neustar.biz (Jeff Hodges)
Date: Mon Jan 15 16:10:22 2007
Subject: [xml2rfc] desirable texttable features
Message-ID: <[email-masked]>

desirable texttable features...

1. a vertical alignment setting attribute, as a complement to the present 
"align" attribute of <ttcol>, suggested values: "top", "bottom", "center"

2. be able to nest <t>..</t> (and (most) all legit sub-elements thereof) within 
<c>..</c>

thanks,

=JeffH

ps: fyi/fwiw - xml2rfc v1.32pre2 presently handles <t> within <c> without 
barfing, it even tries to do the right thing, but it seemed to me that there's 
a bug where the setting of the ttcol/align attribute was subsequently ignored.

---
end

From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Jan 16 06:15:19 2007
Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder]
Message-ID: <[email-masked]>

We really need the new version in production...

-------- Original Message --------
Subject: Internet-Draft Boilerplate Reminder
Date: Mon, 15 Jan 2007 11:51:16 -0500
From: IETF Secretariat <[email-masked]>
To: IETF Announcement list <[email-masked]>
CC: [email-masked]

This message is to remind you that as of February 1, 2007 the IETF
Secretariat will no longer accept Internet-Drafts with the old
(i.e. pre RFC 4748) boilerplate.  For your convenience, below is
the text of the message that was sent to the IETF Announcement
List by the IETF Chair on October 26, 2006 with Subject: Update to
Internet Draft and RFC Boilerplate.

The IETF Secretariat.
--------------------------------------------------------------
A small update to BCP 78 was recently approved by the IESG as RFC 4748,
to update the boilerplate (i.e., standard legal text) in RFCs and
Internet-Drafts to recognize the IETF Trust as a rights holder,
instead of ISOC.

The actual boilerplate changes are given below this message.

Starting as soon as reasonably possible, all authors of Internet-Drafts
are requested to use the new boilerplate. The RFC Editor will in any
case be inserting it in all RFCs issued from 2006-11-01. (The rights
held by ISOC in older RFCs will be administratively transferred to
the IETF Trust.)

The public ID Nits checker already accepts I-Ds with old or new
boilerplate. The Secretariat has started accepting I-Ds with old or
new boilerplate.

XML2RFC version 1.32 will generate the new boilerplate.
Users of I-D templates are requested to update them appropriately.

http://www.ietf.org/ID-Checklist.html and
http://www.ietf.org/ietf/1id-guidelines.html are being updated.

Starting December, the public ID Nits checker will issue warnings for old
boilerplate.

Starting February 2007, the Secretariat will refuse the old boilerplate
in Internet-Drafts.

We are sorry for the inconvenience, but this change cannot be avoided.

     IETF Chair
     IETF Secretariat
     TOOLS Team

--------

Copyright Notice (required for all IETF Documents)

    (Normally placed at the end of the IETF Document.)

NOTE: by convention, the first line of the copyright statement is usually
placed near the beginning of each document. This must also be updated.

OLD
       "Copyright (C) The Internet Society (year).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

NEW
       "Copyright (C) The IETF Trust (year).

       This document is subject to the rights, licenses and restrictions
       contained in BCP 78, and except as set forth therein, the authors
       retain all their rights.

Disclaimer (required in all IETF Documents)

    (Normally placed at the end of the IETF Document after the copyright
    notice.)

OLD
       "This document and the information contained herein are provided
       on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
       THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
       EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
       THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
       ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
       PARTICULAR PURPOSE."

NEW
       "This document and the information contained herein are provided
       on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
       REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
       IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
       WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
       WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
       ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
       FOR A PARTICULAR PURPOSE."

Exceptions

       In MIB modules, PIB modules and similar material commonly
       extracted from IETF Documents, except for material that is being
       placed under IANA maintenance, the following abbreviated notice
       shall be included in the body of the material that will be
       extracted in lieu of the notices otherwise required by Section 5:

OLD
          "Copyright (C) The Internet Society <year>.  This version of
          this MIB module is part of RFC XXXX; see the RFC itself for
          full legal notices."

NEW
          "Copyright (C) The IETF Trust <year>.  This version of
          this MIB module is part of RFC XXXX; see the RFC itself for
          full legal notices."

       When the MIB or PIB module is the initial version of a module that
       is to be maintained by the IANA, the following abbreviated notice
       shall be included:

OLD
          "Copyright (C) The Internet Society <year>.  The initial
          version of this MIB module was published in RFC XXXX; for full
          legal notices see the RFC itself.  Supplementary information
          may be available at:
          http://www.ietf.org/copyrights/ianamib.html."

NEW
          "Copyright (C) The IETF Trust <year>.  The initial
          version of this MIB module was published in RFC XXXX; for full
          legal notices see the RFC itself.  Supplementary information
          may be available at:
          http://www.ietf.org/copyrights/ianamib.html."

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 16 09:14:46 2007
Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> We really need the new version in production...

it is going through QA now. it is scheduled for release this week;  
hopefully tomorrow morning.

/mtr

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Jan 16 13:05:51 2007
Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <p06240845c1d2edd79428@[165.227.249.210]>

Greetings again. A number of the references at xml.resource. org are 
badly formatted, causing inclusion of them in XML input to fail. For 
example, look at 
<http://xml.resource.org/public/rfc/bibxml/reference.RFC.4306.xml>. 
The abstract has:

<t>&lt;p>This document describes version 2 of the Internet Key 
Exchange (IKE) protocol. IKE is a component of IPsec used for 
performing mutual authentication and establishing and maintaining 
security associations (SAs).&lt;/p>&lt;p> This version of the IKE 
specification combines the contents of what were previously separate 
documents, including Internet Security Association and Key Management 
Protocol (ISAKMP, RFC 2408), IKE (RFC 2409), the Internet Domain of 
Interpretation (DOI, RFC 2407), Network Address Translation (NAT) 
Traversal, Legacy authentication, and remote address 
acquisition.&lt;/p>&lt;p> Version 2 of IKE does not interoperate with 
version 1, but it has enough of the header format in common that both 
versions can unambiguously run over the same UDP port. [STANDARDS 
TRACK]&lt;/p></t>

All those '&lt;' should be '<' in order to make it well-formed XML, 
or at least XML that xml2rfc doesn't barf over.

--Paul Hoffman, Director
--VPN Consortium
>From fenner at gmail.com  Tue Jan 16 14:20:02 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Jan 16 14:20:16 2007
Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 1/16/07, Paul Hoffman <[email-masked]> wrote:
> Greetings again. A number of the references at xml.resource. org are
> badly formatted, causing inclusion of them in XML input to fail.

There are two problems here:

1. I think these are validly (but oddly) formed xml, so xml2rfc
shouldn't be barfing.

2. The script that generates these from rfc-index.xml should be
converting <p></p> to <t></t>.  (This changed some time ago, when the
RFC Editor realized they wanted to be able to include
multiple-paragraph abstracts sensibly in the xml index).

  Bill
>From paul.hoffman at vpnc.org  Tue Jan 16 15:08:01 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Jan 16 15:08:17 2007
Subject: [xml2rfc] Keeping artwork on one page
Message-ID: <p06240846c1d30b196f77@[165.227.249.210]>

Greetings again. Is there a way to force artwork to be kept on one 
page? I am using the following for artwork:

<figure><artwork><![CDATA[
                      1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !   RESERVED    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                          some kruft                           ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

--Paul Hoffman, Director
--VPN Consortium
>From nobody at xyzzy.claranet.de  Wed Jan 17 12:26:10 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Jan 17 03:37:37 2007
Subject: [xml2rfc] Re: Keeping artwork on one page
References: <p06240846c1d30b196f77@[165.227.249.210]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:

> <figure><artwork><![CDATA[
[...]

Somewhere I tested <?rfc needLine='8' ?> for a similar purpose,
and the trick was to use 8 instead of 7 (for your example):

<http://permalink.gmane.org/gmane.text.xml.rfc/1158>

Ideally xml2rfc 1.33pre1 should handle this as expected without
explicit needLines, splitting small figures is always ugly.

Maybe the split is caused by compact="yes".  Or of subcompact,
but IIRC I always tested subcompact="no".

Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jan 17 09:12:27 2007
Subject: [xml2rfc] [Fwd: Internet-Draft Boilerplate Reminder]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> We really need the new version in production...

here is a .zip of just the program, for those who can not wait.

/mtr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xml2rfc.tcl.zip
Type: application/zip
Size: 112385 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070116/38a73719/xml2rfc.tcl-0001.zip
>From paul.hoffman at vpnc.org  Wed Jan 17 09:24:15 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Jan 17 09:24:26 2007
Subject: [xml2rfc] Re: Keeping artwork on one page
In-Reply-To: <[email-masked]>
References: <p06240846c1d30b196f77@[165.227.249.210]>
 <[email-masked]>
Message-ID: <p06240809c1d40bcdaf52@[10.20.30.108]>

At 12:26 PM +0100 1/17/07, Frank Ellermann wrote:
>Somewhere I tested <?rfc needLine='8' ?> for a similar purpose,
>and the trick was to use 8 instead of 7 (for your example):

Thanks, that works after I changed "needLine" to "needLines". (I note 
that "needlines" does not work...).

It would be good if a future version of xml2rfc would make needlines 
an attribute of <artwork> and possibly some other elements.

--Paul Hoffman, Director
--VPN Consortium
>From nobody at xyzzy.claranet.de  Fri Jan 19 03:40:47 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Jan 18 18:41:40 2007
Subject: [xml2rfc] Re: Keeping artwork on one page
References: <p06240846c1d30b196f77@[165.227.249.210]>
	<p06240809c1d40bcdaf52@[10.20.30.108]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
 
> It would be good if a future version of xml2rfc would make needlines
> an attribute of <artwork> and possibly some other elements.

Yes, <figure><?rfc needLines="8" ?><artwork> or similar is a bit odd.

Maybe xml2rfc 1.33pre1 could treat a <figure> like a <section> and 
"do the right thing" without explicit attribute.

Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Jan 19 00:18:30 2007
Subject: [xml2rfc] Re: Keeping artwork on one page
In-Reply-To: <[email-masked]>
References: <p06240846c1d30b196f77@[165.227.249.210]> <p06240809c1d40bcdaf52@[10.20.30.108]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
> Paul Hoffman wrote:
>  
>> It would be good if a future version of xml2rfc would make needlines
>> an attribute of <artwork> and possibly some other elements.
> 
> Yes, <figure><?rfc needLines="8" ?><artwork> or similar is a bit odd.

Yes.

> Maybe xml2rfc 1.33pre1 could treat a <figure> like a <section> and 
> "do the right thing" without explicit attribute.

One problem here is that it's not entirely clear what "the right thing" 
is. Sometimes artwork just contains code that can and should be broken 
at end of page. Maybe an additional attribute (keep-on-same-page) is in 
order.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Fri Jan 19 09:13:43 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan 19 09:13:48 2007
Subject: [xml2rfc] xml2rfc 1.32 is released
Message-ID: <[email-masked]>

the most urgent user visible feature: the new boilerplate

http://xml.resource.org/

/mtr

From: hagens at ISI.EDU (Alice Hagens)
Date: Fri Jan 19 10:46:57 2007
Subject: [xml2rfc] Re: Keeping artwork on one page
Message-ID: <[email-masked]>

>One problem here is that it's not entirely clear what "the right thing" 
>is. Sometimes artwork just contains code that can and should be broken 
>at end of page. Maybe an additional attribute (keep-on-same-page) is in 
>order.

Yes, this sounds good, with default set to yes.

RFC Editor/ah

>X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on boreas.isi.edu
>X-Spam-Level: 
>X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY  
autolearn=ham version=3.1.0
>X-Authenticated: #1915285
>Date: Fri, 19 Jan 2007 09:18:15 +0100
>From: Julian Reschke <[email-masked]>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) 
Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666
>MIME-Version: 1.0
>To: Frank Ellermann <[email-masked]>
>Subject: Re: [xml2rfc] Re: Keeping artwork on one page
>Content-Transfer-Encoding: 7bit
>X-Y-GMX-Trusted: 0
>cc: [email-masked]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.1
>List-Id: Mailing list for software packages implementing rfc2629 
<xml2rfc.lists.xml.resource.org>
>List-Unsubscribe: <http://lists.xml.resource.org/mailman/listinfo/xml2rfc>, 
<mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <http://lists.xml.resource.org/mailman/listinfo/xml2rfc>, 
<mailto:[email-masked]?subject=subscribe>
>X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
>X-MailScanner-From: [email-masked]
>
>Frank Ellermann schrieb:
>> Paul Hoffman wrote:
>>  
>>> It would be good if a future version of xml2rfc would make needlines
>>> an attribute of <artwork> and possibly some other elements.
>> 
>> Yes, <figure><?rfc needLines="8" ?><artwork> or similar is a bit odd.
>
>Yes.
>
>> Maybe xml2rfc 1.33pre1 could treat a <figure> like a <section> and 
>> "do the right thing" without explicit attribute.
>
>One problem here is that it's not entirely clear what "the right thing" 
>is. Sometimes artwork just contains code that can and should be broken 
>at end of page. Maybe an additional attribute (keep-on-same-page) is in 
>order.
>
>Best regards, Julian
>_______________________________________________
>xml2rfc mailing list
>[email-masked]
>http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Jan 19 14:30:28 2007
Subject: [xml2rfc] Bad text in the abstracts at xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> 2. The script that generates these from rfc-index.xml should be
> converting <p></p> to <t></t>.  (This changed some time ago, when the
> RFC Editor realized they wanted to be able to include
> multiple-paragraph abstracts sensibly in the xml index).

fine, let me add something to the conversion script.

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 23 13:04:50 2007
Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
> the most urgent user visible feature: the new boilerplate
> 
> http://xml.resource.org/
> 
> /mtr

Thanks Marshall.

Now that a new stable release is out, maybe it's time to think about the 
next steps?

In rfc2629.xslt, I've been experimenting with several new features (see 
documentation at 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extensions> 
and examples such as <http://greenbytes.de/tech/webdav/rfc2616.html>).

Looking at what I use the most, I think

1) the ability to have markup in artwork (for <xref> elements), and

2) the ability to let an <xref> target a specific section of a document 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>)

seem to be the most valuable ones.

Of the things people have asked for, I'd also like to mention

3) paragraph breaks in list items 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.list>) 
and

4) a way to signal whether a page break in artwork is desired or not.

Feedback appreciated,

Julian
>From paul.hoffman at vpnc.org  Tue Jan 23 14:25:38 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Jan 23 14:26:14 2007
Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
Message-ID: <p06240855c1dc3b1dc793@[10.20.30.108]>

At 10:01 PM +0100 1/23/07, Julian Reschke wrote:
>1) the ability to have markup in artwork (for <xref> elements), and
>
>2) the ability to let an <xref> target a specific section of a 
>document 
>(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>)
>
>seem to be the most valuable ones.
>
>Of the things people have asked for, I'd also like to mention
>
>3) paragraph breaks in list items 
>(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.list>) 
>and
>
>4) a way to signal whether a page break in artwork is desired or not.
>
>Feedback appreciated,

Those hit most of my top requests. Another would be to specify the 
bullet characters (the "o" can be quite confusing in some contexts).

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Tue Jan 30 14:06:36 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 30 05:06:43 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
Message-ID: <[email-masked]>

Hi,

I just noted that xml2rfc accepts documents like a preamble like this:

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
   <!ENTITY rfc2119 PUBLIC ''
     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>

(note the ENTITY definition is outside the DTD declaration, which causes 
a conforming XML processor to reject the document).

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Tue Jan 30 09:40:50 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jan 30 09:40:56 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I just noted that xml2rfc accepts documents like a preamble like this:
>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
>   <!ENTITY rfc2119 PUBLIC ''
>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC. 
> 2119.xml'>
>
> (note the ENTITY definition is outside the DTD declaration, which  
> causes a conforming XML processor to reject the document).

doesn't this fall under the second part of the "be conservative in  
what you transmit, be liberal in what you accept" philosophy?

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 30 09:48:42 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
>> I just noted that xml2rfc accepts documents like a preamble like this:
>>
>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
>>   <!ENTITY rfc2119 PUBLIC ''
>>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
>>
>> (note the ENTITY definition is outside the DTD declaration, which 
>> causes a conforming XML processor to reject the document).
> 
> doesn't this fall under the second part of the "be conservative in what 
> you transmit, be liberal in what you accept" philosophy?

Well, but that philosophy hasn't been used for XML.

This means that xml2rfc accepts files that aren't accepted by any 
compliant XML parser, which IMHO is a problem.

(The file was seen on <ftp://ftp.rfc-editor.org/in-notes/authors/>, so 
it seems to be the result of something the RFC Editor is doing. Not Good.)

Best regards, Julian

From: hagens at ISI.EDU (Alice Hagens)
Date: Tue Jan 30 12:14:49 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian,

> (The file was seen on <ftp://ftp.rfc-editor.org/in-notes/authors/>,  
> so it seems to be the result of something the RFC Editor is doing.  
> Not Good.)

This error was introduced by the RFC Editor in one case, and was in  
the submitted file in another case. We have updated the xml files.  
Generally, we edit the xml file for its effect on the xml2rfc output.

As we use xml2rfc more, guidance on its use are invaluable. Also,  
providing the community with a template would be helpful. Are there  
templates available that you would recommend? I know of those created  
by Elwyn Davies for his xml2rfc tutorial in March 06 (http:// 
www3.ietf.org/proceedings/06mar/index.html).

Thanks,
Alice Hagens
for the RFC Editor

On Jan 30, 2007, at 9:48 AM, Julian Reschke wrote:

> Marshall Rose schrieb:
>>> I just noted that xml2rfc accepts documents like a preamble like  
>>> this:
>>>
>>> <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
>>>   <!ENTITY rfc2119 PUBLIC ''
>>>     'http://xml.resource.org/public/rfc/bibxml/reference.RFC. 
>>> 2119.xml'>
>>>
>>> (note the ENTITY definition is outside the DTD declaration, which  
>>> causes a conforming XML processor to reject the document).
>> doesn't this fall under the second part of the "be conservative in  
>> what you transmit, be liberal in what you accept" philosophy?
>
> Well, but that philosophy hasn't been used for XML.
>
> This means that xml2rfc accepts files that aren't accepted by any  
> compliant XML parser, which IMHO is a problem.
>
> (The file was seen on <ftp://ftp.rfc-editor.org/in-notes/authors/>,  
> so it seems to be the result of something the RFC Editor is doing.  
> Not Good.)
>
> Best regards, Julian
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
http://www3.ietf.org/proceedings/06mar/index.html
>From hagens at ISI.EDU  Tue Jan 30 12:20:54 2007
From: hagens at ISI.EDU (Alice Hagens)
Date: Tue Jan 30 12:21:24 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Guidance on its use *is* invaluable.

[cringe]
Alice

On Jan 30, 2007, at 12:14 PM, Alice Hagens wrote:

> are

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070130/32fcc1c5/attachment.htm
>From julian.reschke at gmx.de  Tue Jan 30 21:35:05 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jan 30 12:35:12 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alice Hagens schrieb:
> Julian,
> 
>> (The file was seen on <ftp://ftp.rfc-editor.org/in-notes/authors/>, so 
>> it seems to be the result of something the RFC Editor is doing. Not 
>> Good.)
> 
> This error was introduced by the RFC Editor in one case, and was in the 
> submitted file in another case. We have updated the xml files. 
> Generally, we edit the xml file for its effect on the xml2rfc output.
> 
> As we use xml2rfc more, guidance on its use are invaluable. Also, 
> providing the community with a template would be helpful. Are there 
> templates available that you would recommend? I know of those created by 
> Elwyn Davies for his xml2rfc tutorial in March 06 
> (http://www3.ietf.org/proceedings/06mar/index.html).
> 
> Thanks,
> Alice Hagens
> for the RFC Editor

Well, I would recommend to run the file through a validating XML parser. 
If the parser rejects the file, there's a problem (unfortunately, 
xml2rfc currently doesn't use a compliant parser).

Best regards, Julian
>From dbharrington at comcast.net  Tue Jan 30 15:43:45 2007
From: dbharrington at comcast.net (David B Harrington)
Date: Tue Jan 30 12:47:42 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I agree that the XML should be validated by more than xml2rfc. Many
XML editors will not load an invalid XML file, even if xml2rfc
processes it just fine. 

XML validation helps to ensure compliance to the XML standard,
something we should appreciate, even when IETF-related tools are
designed to be liberal in what they accept ;-)

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian
Reschke
> Sent: Tuesday, January 30, 2007 3:35 PM
> To: Alice Hagens
> Cc: [email-masked]; xml2rfc mailing list; Marshall Rose
> Subject: Re: [xml2rfc] XML parsing error in xml2rfc
> 
> Alice Hagens schrieb:
> > Julian,
> > 
> >> (The file was seen on 
> <ftp://ftp.rfc-editor.org/in-notes/authors/>, so 
> >> it seems to be the result of something the RFC Editor is 
> doing. Not 
> >> Good.)
> > 
> > This error was introduced by the RFC Editor in one case, 
> and was in the 
> > submitted file in another case. We have updated the xml files. 
> > Generally, we edit the xml file for its effect on the 
> xml2rfc output.
> > 
> > As we use xml2rfc more, guidance on its use are invaluable. Also, 
> > providing the community with a template would be helpful. Are
there 
> > templates available that you would recommend? I know of 
> those created by 
> > Elwyn Davies for his xml2rfc tutorial in March 06 
> > (http://www3.ietf.org/proceedings/06mar/index.html).
> > 
> > Thanks,
> > Alice Hagens
> > for the RFC Editor
> 
> Well, I would recommend to run the file through a validating 
> XML parser. 
> If the parser rejects the file, there's a problem (unfortunately, 
> xml2rfc currently doesn't use a compliant parser).
> 
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: fenner at gmail.com (Bill Fenner)
Date: Tue Jan 30 12:51:15 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

This [the fact that xml2rfc doesn't validate its input] is why I
created http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

It's a validating xml parser with some specific smarts about the xml2rfc format.

  Bill
>From tli at cisco.com  Tue Jan 30 22:08:10 2007
From: tli at cisco.com (Tony Li)
Date: Tue Jan 30 22:08:27 2007
Subject: [xml2rfc] XML parsing error in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Ah, the irony....  ;-)

Tony

On Jan 30, 2007, at 12:20 PM, Alice Hagens wrote:

> Guidance on its use *is* invaluable.
>
> [cringe]
> Alice
>
> On Jan 30, 2007, at 12:14 PM, Alice Hagens wrote:
>
>> are
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070130/ac68afcd/attachment.htm

From: thomas.morin at orange-ftgroup.com (Thomas Morin)
Date: Tue Feb  6 07:43:46 2007
Subject: Next steps, was: [xml2rfc] xml2rfc 1.32 is released
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <1170671121.21745.6.camel@wintermute>

Hi folks,

Julian Reschke :
[...]
> Now that a new stable release is out, maybe it's time to think about the 
> next steps?

One suggestion I'd like to make is that it would be nice to have xml2rfc
(and the XML spec) accept numbers for specifying month in <date/> tags .
In my experience, I've seen current behavior (only full month name is
accepted) be a frequent case of error for first-timers; since specifying
the date is one of the first thing you do, making it a bit easier will
certainly lower the barrier for new xml2rfc users.

Cheers,

-Thomas

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Feb  6 12:11:49 2007
Subject: [xml2rfc] Re: Next steps
References: <[email-masked]> <[email-masked]> <1170671121.21745.6.camel@wintermute>
Message-ID: <[email-masked]>

Thomas Morin wrote:

> I've seen current behavior (only full month name is accepted) be a
> frequent case of error for first-timers; since specifying the date
> is one of the first thing you do

IIRC the "new" (?) approach is to specify no date attributes at all,
because xml2rfc uses a decent "now" default.  It still insists on a
a date-element, though, but an empty <date /> works as expected.

Frank

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Feb 10 05:10:45 2007
Subject: [xml2rfc] Entities in figure titles
Message-ID: <[email-masked]>

Hi.

I came across a document that was trying to produce the text '<domain> 
example' as a figure title.  The author had followed instincts and used 
entities to escape the < and > in the title attribute but they weren't 
substituted so the title came out as '&lt;domain&gt; example'.  Is this 
a bug or a characteristic of attribute processing?  My knowledge is not 
deep enough to know the answer offhand.

/Elwyn
>From julian.reschke at gmx.de  Sat Feb 10 14:45:57 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb 10 05:46:02 2007
Subject: [xml2rfc] Entities in figure titles
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies schrieb:
> Hi.
> 
> I came across a document that was trying to produce the text '<domain> 
> example' as a figure title.  The author had followed instincts and used 
> entities to escape the < and > in the title attribute but they weren't 
> substituted so the title came out as '&lt;domain&gt; example'.  Is this 
> a bug or a characteristic of attribute processing?  My knowledge is not 
> deep enough to know the answer offhand.

That would be a bug. I just tried...:

<figure title="another figure &lt;x&gt;" anchor="testfig">
   <artwork>
   +--+
   |  |
   +--+
</artwork>
<postamble>with postamble and title...</postamble>
</figure>
<t>
   The figure above has the title "<xref target="testfig" format="title" 
/>".
</t>

which was transformed to:

      +--+
      |  |
      +--+

    with postamble and title...

                        Figure 2: another figure <x>

    The figure above has the title "another figure &lt;x&gt;".

So the title itself seems to work, but the <xref> handling seems to be 
broken (the HTML output mode gets it right).

Best regards, Julian

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Feb 10 06:11:11 2007
Subject: [xml2rfc] Entities in figure titles
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Elwyn Davies schrieb:
>> Hi.
>>
>> I came across a document that was trying to produce the text 
>> '<domain> example' as a figure title.  The author had followed 
>> instincts and used entities to escape the < and > in the title 
>> attribute but they weren't substituted so the title came out as 
>> '&lt;domain&gt; example'.  Is this a bug or a characteristic of 
>> attribute processing?  My knowledge is not deep enough to know the 
>> answer offhand.
>
> That would be a bug. I just tried...:
>
> <figure title="another figure &lt;x&gt;" anchor="testfig">
>   <artwork>
>   +--+
>   |  |
>   +--+
> </artwork>
> <postamble>with postamble and title...</postamble>
> </figure>
> <t>
>   The figure above has the title "<xref target="testfig" 
> format="title" />".
> </t>
>
> which was transformed to:
>
>      +--+
>      |  |
>      +--+
>
>    with postamble and title...
>
>                        Figure 2: another figure <x>
>
>    The figure above has the title "another figure &lt;x&gt;".
Interesting!  My quick trial using the online service produced a title 
with unsubstituted entities in both text and HTML.
I got the same unsubstituted answer using a not very up-to-date version 
of the XSL preview from within XMLmind.

      <figure align="center" anchor="xml_happy" 
title="&amp;gt;domain&amp;lt;">
        <preamble>Preamble text - can be omitted or empty.</preamble>

        <artwork align="left"><![CDATA[

+-----------------------+
| Use XML, be Happy :-) |
|_______________________|

            ]]></artwork>

        <postamble>Cross-references allowed in pre- and postamble. <xref
        target="min_ref" />.</postamble>
      </figure>

produced

                 Preamble text - can be omitted or empty.

   +-----------------------+
   | Use XML, be Happy :-) |
   |_______________________|

           Cross-references allowed in pre- and postamble. [1].

                         Figure 1: &gt;domain&lt;

But anyway there is something amiss.  That's all I need to know for the 
time being.

/Elwyn

>
>
> So the title itself seems to work, but the <xref> handling seems to be 
> broken (the HTML output mode gets it right).
>
> Best regards, Julian
>
>
>
>
>From julian.reschke at gmx.de  Sat Feb 10 15:31:18 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Feb 10 06:31:24 2007
Subject: [xml2rfc] Entities in figure titles
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies schrieb:
> ...
> Interesting!  My quick trial using the online service produced a title 
> with unsubstituted entities in both text and HTML.
> I got the same unsubstituted answer using a not very up-to-date version 
> of the XSL preview from within XMLmind.
> 
>      <figure align="center" anchor="xml_happy" 
> title="&amp;gt;domain&amp;lt;">
>        <preamble>Preamble text - can be omitted or empty.</preamble>
> 
>        <artwork align="left"><![CDATA[
> 
> +-----------------------+
> | Use XML, be Happy :-) |
> |_______________________|
> 
> 
>            ]]></artwork>
> 
>        <postamble>Cross-references allowed in pre- and postamble. <xref
>        target="min_ref" />.</postamble>
>      </figure>
> 
> produced
> 
>                 Preamble text - can be omitted or empty.
> 
> 
>   +-----------------------+
>   | Use XML, be Happy :-) |
>   |_______________________|
> 
> 
> 
>           Cross-references allowed in pre- and postamble. [1].
> 
>                         Figure 1: &gt;domain&lt;

But that's correct. If you have "&amp;gt;" in the title attribute, 
that's a text value of "&gt;" (because have it double-escaped). If you 
want a "<", then put that into the title attribute, and escape it *once* 
as required in XML.

> ...

Best regards, Julian
>From elwynd at dial.pipex.com  Sat Feb 10 15:56:44 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Feb 10 07:56:04 2007
Subject: [xml2rfc] Entities in figure titles
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Oh dear! I really wasn't with it was I. :-(

But now I realize probably what has happened in the draft.  I typed the 
text into XMLmind in the attribute editor as '&gt;' etc and it has saved 
the text exactly as I copied into the email.  I had either forgotten or 
wasn't really aware that XMLmind turns these meta-characters into 
entities when saving.

So:
- Users need to be aware that XMLmind does this to metacharacters
- There is the bug in the xref which you found

Sorry.
/Elwyn

Julian Reschke wrote:
> Elwyn Davies schrieb:
>> ...
>> Interesting!  My quick trial using the online service produced a 
>> title with unsubstituted entities in both text and HTML.
>> I got the same unsubstituted answer using a not very up-to-date 
>> version of the XSL preview from within XMLmind.
>>
>>      <figure align="center" anchor="xml_happy" 
>> title="&amp;gt;domain&amp;lt;">
>>        <preamble>Preamble text - can be omitted or empty.</preamble>
>>
>>        <artwork align="left"><![CDATA[
>>
>> +-----------------------+
>> | Use XML, be Happy :-) |
>> |_______________________|
>>
>>
>>            ]]></artwork>
>>
>>        <postamble>Cross-references allowed in pre- and postamble. <xref
>>        target="min_ref" />.</postamble>
>>      </figure>
>>
>> produced
>>
>>                 Preamble text - can be omitted or empty.
>>
>>
>>   +-----------------------+
>>   | Use XML, be Happy :-) |
>>   |_______________________|
>>
>>
>>
>>           Cross-references allowed in pre- and postamble. [1].
>>
>>                         Figure 1: &gt;domain&lt;
>
> But that's correct. If you have "&amp;gt;" in the title attribute, 
> that's a text value of "&gt;" (because have it double-escaped). If you 
> want a "<", then put that into the title attribute, and escape it 
> *once* as required in XML.
>
>> ...
>
> Best regards, Julian
>From fenner at gmail.com  Sat Feb 10 22:22:38 2007
From: fenner at gmail.com (Bill Fenner)
Date: Sat Feb 10 19:22:49 2007
Subject: [xml2rfc] Entities in figure titles
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	 <[email-masked]> <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 2/10/07, Elwyn Davies <[email-masked]> wrote:
> So:
> - Users need to be aware that XMLmind does this to metacharacters

Indeed.  This is XMLMind being a document editor - you tell it what
you want in the document, and it does what's needed for the XML.  In
this case, since you said you wanted "&gt;" in the document, it
inserted "&amp;gt;" into the XML.

  Bill
>From paf at cisco.com  Thu Feb 15 11:21:26 2007
From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Thu Feb 15 11:21:38 2007
Subject: [xml2rfc] Large XML documents...
Message-ID: <[email-masked]>

I have an XML document that create, hrm, a Very Large Table(tm). You  
can find the XML file (3.4Mbyte large) as http://stupid.domain.name/ 
stuff/draft-faltstrom-idnabis-tables-02.xml ...there are some anchors  
and references that are not correct yet, I know that, but...

The problem I have is that running xml2rfc on the file make the  
program never terminate. If I use the website I get an empty document  
back, no messages.

Whats up?

Anyone with something faster/larger/more memory than my MacBookPro  
that can try?

The textfile that is produced, ends like this, if I terminate the  
program:

:
:
:
            | U+0A26 | YES   | GURMUKHI LETTER DA       | A     |
            | U+0A27 | YES   | GURMUKHI LETTER DHA      | A     |
            | U+0A28 | YES   | GURMUKHI LETTER NA       | A     |
            | U+0A2A | YES   | GURMUKHI LETTER PA       | A     |
            | U+0A2B | YES   | GURMUKHI LETTER PHA      | A     |
            | U+0A2C | YES   | GURMUKHI LETTER BA       | A     |

Faltstrom                Expires August 5, 2006               [Page 187]

Internet-Draft             Unicode Codepoints              February 2006

            | U+0A2D | YES   | GURMUKHI LETTER BHA      | A     |
            | U+0A2E | YES   | GURMUKHI LETTER MA       | A     |
            | U+0A

     Patrik
>From mrose at dbc.mtview.ca.us  Thu Feb 15 12:25:21 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 15 12:25:26 2007
Subject: [xml2rfc] Large XML documents...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Anyone with something faster/larger/more memory than my MacBookPro  
> that can try?

hmmm... i didn't know there were computers that were faster/larger/ 
better than an MBP.

i'm running your file on a 2.16GHz / 2GB 667MHz system.

i've added some instrumentation to see if there is a loop somewhere.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Feb 15 17:25:34 2007
Subject: [xml2rfc] Large XML documents...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Anyone with something faster/larger/more memory than my MacBookPro  
> that can try?

it took 5h30m to run on my MBP. xml2rfc isn't optimized for running  
on really big files...

/mtr

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Fri Feb 16 09:25:41 2007
Subject: [xml2rfc] Large XML documents...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Anyone with something faster/larger/more memory than my MacBookPro 
>> that can try?
>
> it took 5h30m to run on my MBP. xml2rfc isn't optimized for running on 
> really big files...
>
> /mtr
>
For the hell of it I ran it on a spare Windows machine for comparison.  
5h 48m on half a Pentium 4 2.8GHz (i.e. one thread on a dual core machine).
It peaked at something over 420*10^6 bytes of memory right at the end.
Roughly split into 40m for pass 1, 2h 20m for pass 2 and 2h 48m for pass 3.

Patrik: I've stuffed the output (4179168 bytes, 1165 pages) on my web 
site if you want it! 
http://dialspace.dial.pipex.com/prod/dialspace/town/square/hq41/ietfpriv/draft-faltstrom-idnabis-tables-02.txt

/Elwyn
>From fenner at gmail.com  Fri Feb 16 11:18:10 2007
From: fenner at gmail.com (Bill Fenner)
Date: Fri Feb 16 11:18:15 2007
Subject: [xml2rfc] Large XML documents...
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2/15/07, Patrik F?ltstr?m <[email-masked]> wrote:
> I have an XML document

Actually it's not well-formed, there's a broken entity reference on
line 54146 ;-)

I ran it through Julian's xslt, for kicks.  It took 2 hours (on a
1.7ghz Pentium) to create a 4.3 meg HTML file.  I didn't check memory
usage.

I never finished my xslt -> nroff translator, but that seems like it
might be your best bet to get text output in only a couple of hours.
But I don't think 2 hours is really much better than 5 hours, you
might as well just run it overnight ;-)

  Bill

From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Fri Feb 16 16:17:15 2007
Subject: [xml2rfc] Large XML documents...
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 16 feb 2007, at 11.18, Bill Fenner wrote:

> On 2/15/07, Patrik F?ltstr?m <[email-masked]> wrote:
>> I have an XML document
>
> Actually it's not well-formed, there's a broken entity reference on
> line 54146 ;-)
>
> I ran it through Julian's xslt, for kicks.  It took 2 hours (on a
> 1.7ghz Pentium) to create a 4.3 meg HTML file.  I didn't check memory
> usage.
>
> I never finished my xslt -> nroff translator, but that seems like it
> might be your best bet to get text output in only a couple of hours.
> But I don't think 2 hours is really much better than 5 hours, you
> might as well just run it overnight ;-)

Thanks everyone!

This is a document that is about use of Unicode in Internationalized  
Domain Names. I guess I have to have a different way of listing the  
Unicode Codepoints and their "score" in the algorithm used :-)

I think/hope I can get it down to 50 pages...

I ask myself what RFC editor would say if I passed them a >1000 pages  
I-D. It would be "fun".

I got a copy of the txt version of the draft, and I have it myself,  
so you can delete all copies that fill up your drives.

Once again, thanks!

    Patrik

From: EdwardB at actelis.com (Edward Beili)
Date: Mon Feb 19 09:17:03 2007
Subject: [xml2rfc] including a MIB text file
Message-ID: <[email-masked]>

Hi,
I'm looking for a mechanism to include an unparsed external ASCII file (e.g. MIB module) into an xml.

Up until xml2rfc-1.30 I used:

<section>
<figure><artwork><?rfc include="xxx-MIB.mib"?></artwork></figure>
</section>

However this behavior was broken starting from xml2rfc-1.31.

With xml2rfc-1.32 I pre-process the MIB file to insert the XML code before and after the MIB content:

Xxx-MIB.mib:
------------
<figure><artwork><![CDATA[
...<MIB content>...
]]></artwork></figure>

Simply putting <?rfc include="xxx-MIB.mib"?> in the xml file:
<section>
<?rfc include="xxx-MIB.mib"?>
</section>

I was wondering if there was another way to do this using only xml2rfc, without additional pre-processing in the Makefile.

Regards,
-E.

> -----Original Message-----
> From: Edward Beili
> Sent: Monday, August 28, 2006 1:22 AM
> To: [email-masked]
> Subject: [xml2rfc] include in 1.31
> 
> 
> Hi,
> 
> The following .xml code stopped working in v1.31:
> 
> <section title="Definitions">
> <figure>
>   <artwork>
> <?rfc include="efm-cu-mib.mib"?>
>   </artwork>
> </figure>
> </section>
> 
> In 1.30 the <?rfc include> directive included the MIB file 
> pre-formatted, i.e.
> 
> <pre>
> ... <!--Content of the include file here--> </pre>
> 
> In 1.31 it is putting 3 empty blocks instead:
> 
> <div style='display: table; width: 0; margin-left: 3em;
> margin-right: auto'><pre>
> </pre></div><div style='display: table; width: 0;
> margin-left: 3em; margin-right: auto'><pre> </pre></div><div 
> style='display: table; width: 0;
> margin-left: 3em; margin-right: auto'><pre> </pre></div>
> 
> Is it a bug in 1.31 or should I use some other trick to insert the 
> pre-formatted external file into the document?
> 
> Regards,
> -Edward
> 

From: ali.fessi at uni-tuebingen.de (Ali Fessi)
Date: Wed Feb 21 13:21:45 2007
Subject: [xml2rfc] <list> tag subordinated by a <t> tag
Message-ID: <[email-masked]>

Hi all,

sorry if I missed something. but I submitted a draft last summer and 
evrything was fine. Now I'm working on a update and the xml2rfc tool 
does not even accept the same identical xml file as the one from the 
last version anymore.

It doesn't like it when I have a <list> tag subordinated by a <t> tag, e.g.
--------

<t>This is my time tabe for the week:
    <list style="hanging">

	<t hangText="Monday to Friday">
             working
	</t>

	<t hangText="Saturday and Sunday">
	    working
	</t>

   </list>
</t>

---------

Could someone give me a hint please how to fix this?

Thanks a lot!
  Ali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3263 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070221/fa380fec/smime.bin
>From nobody at xyzzy.claranet.de  Wed Feb 21 22:42:48 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 21 13:44:18 2007
Subject: [xml2rfc] Re: <list> tag subordinated by a <t> tag
References: <[email-masked]>
Message-ID: <[email-masked]>

Ali Fessi wrote:
 
> It doesn't like it when I have a <list> tag subordinated by a <t> tag, e.g.
> --------
[...]
> --------
> Could someone give me a hint please how to fix this?

I inserted your example as is in a test document and it worked:

2.  Security Considerations

   Read [simple]...

   This is my time tabe for the week:
   Monday to Friday  working
   Saturday and Sunday  working

Frank

From: ali.fessi at uni-tuebingen.de (Ali Fessi)
Date: Wed Feb 21 14:13:49 2007
Subject: [xml2rfc] Re: <list> tag subordinated by a <t> tag
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Frank!

thanks for your quick response!

could you please do me a favor and try this as well? I don't know what's 
exactly the problem, but the error is:

"xml2rfc: error: <list> element not subordinate to <t> element around 
input line 764" (the line 764 is marked below)

Thanks a lot!

cheers,
  ali

--------

<section title="Session State Machine">

    <t>The state machine consists of three main states:</t>
    <list style="hanging">
       <t hangText="'idle':">dummy text</t>
	
       <t hangText="'pending':">
          <t> The 'pending' state consists of 2 sub-states</t>
             <list style="hanging">   <!-- here is line 764 -->
                 <t hangText="pending.first">dummy text</t>
                 <t hangText="pending.second">dummy text</t>
             </list>
       </t>
						
       <t hangText="'established':">
          <t> The 'established' state consists of 2 sub-states</t>
	    <list style="hanging">	
	       <t hangText="established.first">dummy text</t>
	       <t hangText="established.second">dummy text</t>
	    </list>
	 </t>
     </list>	

</section>

-----------

Frank Ellermann wrote:
> Ali Fessi wrote:
>  
>> It doesn't like it when I have a <list> tag subordinated by a <t> tag, e.g.
>> --------
> [...]
>> --------
>> Could someone give me a hint please how to fix this?
> 
> I inserted your example as is in a test document and it worked:
> 
> 2.  Security Considerations
> 
>    Read [simple]...
> 
>    This is my time tabe for the week:
>    Monday to Friday  working
>    Saturday and Sunday  working
> 
> Frank
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/
>From nobody at xyzzy.claranet.de  Wed Feb 21 23:27:46 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Feb 21 14:28:33 2007
Subject: [xml2rfc] Re: <list> tag subordinated by a <t> tag
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ali Fessi wrote:
 
> I don't know what's exactly the problem

Your <t>-s don't match the </t>-s, here's a modified working version:

<section title="Session State Machine">

    <t>The state machine consists of three main states:
    <list style="hanging">
       <t hangText="'idle':">dummy text</t>

       <t hangText="'pending':">
          The 'pending' state consists of 2 sub-states
             <list style="hanging">   <!-- here is line 764 -->
                 <t hangText="pending.first">dummy text</t>
                 <t hangText="pending.second">dummy text</t>
             </list>
       </t>

       <t hangText="'established':">
          The 'established' state consists of 2 sub-states
            <list style="hanging">
               <t hangText="established.first">dummy text</t>
               <t hangText="established.second">dummy text</t>
            </list>
         </t>
     </list></t>

</section>

2.  Session State Machine

   The state machine consists of three main states:
   'idle':  dummy text
   'pending':  The 'pending' state consists of 2 sub-states
      pending.first  dummy text
      pending.second  dummy text
   'established':  The 'established' state consists of 2 sub-states
      established.first  dummy text
      established.second  dummy text

Frank

From: fenner at gmail.com (Bill Fenner)
Date: Mon Feb 26 09:47:45 2007
Subject: [xml2rfc] Re: DTD modifications for multi-paragraph lists
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 11/11/06, John C Klensin <[email-masked]> wrote:
> Around Wednesday, August 30, 2006, several people discussed
> ideas similar to
>
> > <!ELEMENT list  (t+|lt+)>
> > <!ELEMENT lt    (t|list)+>
> > <!ATTLIST lt
> >           hangText    %ATEXT;            #IMPLIED>
>
> I think this, or some close variant on it, would be a great
> improvement, especially since I have used the <vspace> kludge a
> lot and dislike it for all of the usual reasons.

I have an initial implementation of this.  I need to work on the html
output, but the text output seems reasonable.  Would anyone care to
test it (or send me test cases)?

> However, if we are going to create an <lt> element, perhaps this
> is the time to equip it with an optional "anchor" attribute.

I haven't worked on this yet.

  Bill

From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN)
Date: Thu Mar  1 15:38:03 2007
Subject: [xml2rfc]  TR: draft-stephan-ops-xml-mib-module-template-00.txt: XML template for MIB modules
Message-ID: <[email-masked]>

Hi,

The discussion on this draft takes place in ops-area ml.
As a lot of points are related to xml2rfc I invite you to have a glance at this ml.

Regards
Emile

_____________________________________________
De : STEPHAN Emile RD-CORE-LAN 
Envoy? : mercredi 28 f?vrier 2007 09:15
? : [email-masked]'; 'Romascanu, Dan (Dan)'
Cc : [email-masked]
Objet : draft-stephan-ops-xml-mib-module-template-00.txt: XML template for MIB modules

Hi,

A new draft is available.
This memo ( http://tools.ietf.org/html/draft-stephan-ops-xml-mib-module-template-00 ) presents a XML template for specifying SMI objects and proposes a common XSL base for sharing SMI objects definitions with XML applications. 

It includes an example of XML application loading MIB objects of a XML version of the SAMPLE-MIB of draft-harrington-text-mib-doc-template-02.txt.

Comments are welcome to prepare the mini bof of Prague.

Regards
Emile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070302/9786391e/attachment.htm
>From fenner at gmail.com  Mon Mar  5 13:22:02 2007
From: fenner at gmail.com (Bill Fenner)
Date: Mon Mar  5 10:22:10 2007
Subject: [xml2rfc] DTD anomaly: <section><section></section><t/></section>
Message-ID: <[email-masked]>

Hi,

  I accidentally came across a construct that's valid according to
rfc2629.dtd but seems to have no useful semantics.

<section title="Introduction">
<t>Paragraph 1 of Section 1</t>
  <section title="Subsection">
  <t>Paragraph 1 of Section 1.1</t>
  </section>
<t>Semantically, this is paragraph 2 of section 1.  However, it
renders as paragraph 2 of Section 1.1.</t>
</section>

xml2rfc and Julian's xslt both render the final <t> in a way that
makes it indistinguishable (visually) from being the second paragraph
of section 1.1.

I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
preceding-sibling::section node, then report an error at that point.

Any thoughts?

Thanks,
  Bill
>From carl at media.org  Mon Mar  5 12:32:40 2007
From: carl at media.org (Carl Malamud)
Date: Mon Mar  5 12:32:48 2007
Subject: [xml2rfc] DTD anomaly: <section><section></section><t/></section>
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
> preceding-sibling::section node, then report an error at that point.

If it is a no-op, why worry about it?

The <section><t>intro text</t><section> construct is a useful one.
If putting a paragraph at the end has no effect, wouldn't it be
simpler to just stay silent on the whole issue rather than
explain the subtle difference about where a <t> is placed?
It would take a page in the documentation to explain that the
dangling <t> results in an error in your document.  :)

Carl
>From fenner at gmail.com  Mon Mar  5 12:45:57 2007
From: fenner at gmail.com (Bill Fenner)
Date: Mon Mar  5 12:46:04 2007
Subject: [xml2rfc] DTD anomaly: <section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 3/5/07, Carl Malamud <[email-masked]> wrote:
> > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
> > preceding-sibling::section node, then report an error at that point.
>
> If it is a no-op, why worry about it?

It's not a no-op; it results in the text that's semantically
associated with section A to be rendered as though it was part of
section B.

> The <section><t>intro text</t><section> construct is a useful one.

No argument there, and I wasn't proposing changing anything about that.

> If putting a paragraph at the end has no effect, wouldn't it be
> simpler to just stay silent on the whole issue rather than
> explain the subtle difference about where a <t> is placed?

If you put the paragraph after the closing </section> of section 1.1,
then it's semantically associated with section 1 but will render as
though it's part of section 1.1.  The big problem with that is that if
you decide to move section 1.1 using an xml editor, you won't get all
of its apparent contents since part of it is actually part of section
1.

  <section title="Introduction">
    <t>Howdy!</t>
    <section title="Outline">
      <t>In this document, we'll start with fooing and barring.</t>
      <t>Then we'll frick and frack.</t>
    </section>
    <t>Finally, we'll be fribbing and frobbing.</t>
  </section>

formats as

1.  Introduction

   Howdy!

1.1.  Outline

   In this document, we'll start with fooing and barring.

   Then we'll frick and frack.

   Finally, we'll be fribbing and frobbing.

which will be confusing if you, say, cut-n-paste the <section> element
for the "Outline" section and it suddenly becomes

  <section title="Introduction">
    <t>Howdy!</t>
    <t>Finally, we'll be fribbing and frobbing.</t>
  </section>
  <section title="Outline">
    <t>In this document, we'll start with fooing and barring.</t>
    <t>Then we'll frick and frack.</t>
  </section>

1.  Introduction

   Howdy!

   Finally, we'll be fribbing and frobbing.

2.  Outline

   In this document, we'll start with fooing and barring.

   Then we'll frick and frack.

  Bill
>From Nicolas.Williams at sun.com  Mon Mar  5 15:13:03 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Mar  5 13:13:43 2007
Subject: [xml2rfc] DTD anomaly: <section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mon, Mar 05, 2007 at 12:45:57PM -0800, Bill Fenner wrote:
> On 3/5/07, Carl Malamud <[email-masked]> wrote:
> >> I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
> >> preceding-sibling::section node, then report an error at that point.
> >
> >If it is a no-op, why worry about it?
> 
> It's not a no-op; it results in the text that's semantically
> associated with section A to be rendered as though it was part of
> section B.

Warn or error sounds good to me.  Alternatively find a way to resolve
the ambiguity, e.g.:

1.  Foo

   Blah.

1.2.  Foobar

   Blah, blah.

1.  (continued) Foo

   Dangling paragraph.

Of course, this wouldn't result in a valid I-D, but it might be fine for
private memos.  Also, it should draw attention.

Nico
-- 
>From mrose at dbc.mtview.ca.us  Mon Mar  5 14:18:02 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar  5 14:18:09 2007
Subject: [xml2rfc] 
	Re: DTD anomaly: <section><section></section><t/></section>
Message-ID: <[email-masked]>

 > I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
 > preceding-sibling::section node, then report an error at that point.

 > Any thoughts?

i ran into this problem when using xml2rfc to author a book (the  
source was converted to sgml and then given to the publisher).

i think it is reasonable to change the dtd to enforce this  
limitation, i.e.,

> <!ELEMENT section ((t|figure|texttable|iref)*,section*)>

however, given that this is a rather substantive change (i.e., we  
will break a small percentage of old documents), we should make it a  
warning.

/mtr
  
>From julian.reschke at gmx.de  Mon Mar  5 23:51:50 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar  5 14:52:04 2007
Subject: [xml2rfc] 	Re: DTD anomaly:
	<section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
>> <!ELEMENT section ((t|figure|texttable|iref)*,section*)>
> 
> however, given that this is a rather substantive change (i.e., we will 
> break a small percentage of old documents), we should make it a warning.

I'm happy with both, with a small preference to change the DTD (at least 
in a beta) and see how many people scream :-).

Best regards, Julian
>From Dale.Worley at comcast.net  Mon Mar  5 18:14:27 2007
From: Dale.Worley at comcast.net ([email-masked])
Date: Mon Mar  5 15:14:38 2007
Subject: [xml2rfc] 
	Reminder: Intended status needed in front matter of drafts
Message-ID: <[email-masked]>

I recently received an e-mail with the above Subject from a Working
Group chair:

    Subject: [Sip] Reminder: Intended status needed in front matter of drafts
    To: SIP IETF <[email-masked]>
    Date: Sun, 4 Mar 2007 14:25:26 -0600

    I've been reminded that all IDs sent for publication are now expected  
    to have an "Intended status" field in their front matter.

    xml2rc handles this in the "category" field of the "rfc" element. For  
    example, I just revised the autoanswer draft, and it has the following:

    <rfc ipr="full3978" category="std" docName="draft-ietf-sip- 
    answermode-02">

    This produces an Intended status: of "Standards track" in the front  
    matter section as reproduced below:

It would seem to be a good idea for "<?rfc strict="yes" ?>" to enforce
a valid "category" attribute.

Dale
>From gwz at cisco.com  Tue Mar  6 05:50:31 2007
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 05:50:39 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
Message-ID: <[email-masked]>

Hi.  I've received this lovely missive twice in the last 2 days.  I've
duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is there a
magic incantation I can use to a) stop the IETF from changing the
boilerplate every 6 months, b) make xml2rfc insert the correct
boilerplate, c) turn xml2rfc into actual production toy or (preferably)
d) all of the above?

 [email-masked] <mailto:[email-masked]> allegedly scribbled on Monday, March
05, 2007 11:57 AM:

>>  <<draft-zorn-dime-diameter-base-protocol-mib-01.txt>>
>> 
> The Secretariat CANNOT process your Internet-Draft submission due to
> following reason(s):  * All Internet-Drafts must include the
> following  
> statement:
> 
> Copyright (C) The IETF Trust (2007).
> 
>  * All Internet-Drafts must include the following statement near the
> end of the document.: 
> 
> This document and the information contained herein are provided on an
> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   

From: dave at cridland.net (Dave Cridland)
Date: Tue Mar  6 05:58:06 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To:  <[email-masked]>
References:  <[email-masked]>
Message-ID: <[email-masked]>

On Tue Mar  6 13:50:31 2007, Glen Zorn (gwz) wrote:
> Hi.  I've received this lovely missive twice in the last 2 days.  
> I've
> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is 
> there a
> magic incantation I can use to a) stop the IETF from changing the
> boilerplate every 6 months, b) make xml2rfc insert the correct
> boilerplate, c) turn xml2rfc into actual production toy or 
> (preferably)
> d) all of the above?

FWIW, I do my "submission" copies off the web interface, which does 
produce the right boilerplate.

Or at least, my submission was accepted, which is good enough for me.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From br at brianrosen.net  Tue Mar  6 09:23:29 2007
From: br at brianrosen.net (Brian Rosen)
Date: Tue Mar  6 06:23:36 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Oh, I like b).  Specify a string for ipr that always matches latest IETF
rules.

Brian
> -----Original Message-----
> From: [email-masked] [mailto:xml2rfc-
> [email-masked]] On Behalf Of Glen Zorn (gwz)
> Sent: Tuesday, March 06, 2007 8:51 AM
> To: [email-masked]
> Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
> 
> Hi.  I've received this lovely missive twice in the last 2 days.  I've
> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is there a
> magic incantation I can use to a) stop the IETF from changing the
> boilerplate every 6 months, b) make xml2rfc insert the correct
> boilerplate, c) turn xml2rfc into actual production toy or (preferably)
> d) all of the above?
> 
>  [email-masked] <mailto:[email-masked]> allegedly scribbled on Monday, March
> 05, 2007 11:57 AM:
> 
> >>  <<draft-zorn-dime-diameter-base-protocol-mib-01.txt>>
> >>
> > The Secretariat CANNOT process your Internet-Draft submission due to
> > following reason(s):  * All Internet-Drafts must include the
> > following
> > statement:
> >
> > Copyright (C) The IETF Trust (2007).
> >
> >  * All Internet-Drafts must include the following statement near the
> > end of the document.:
> >
> > This document and the information contained herein are provided on an
> > "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
> > OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
> > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
> > OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
> > THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
> > WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 06:34:22 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dave Cridland <> allegedly scribbled on Tuesday, March 06, 2007 5:58 AM:

> On Tue Mar  6 13:50:31 2007, Glen Zorn (gwz) wrote:
>> Hi.  I've received this lovely missive twice in the last 2 days. I've
>> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is there
>> a magic incantation I can use to a) stop the IETF from changing the
>> boilerplate every 6 months, b) make xml2rfc insert the correct
>> boilerplate, c) turn xml2rfc into actual production toy or
>> (preferably) d) all of the above?
> 
> FWIW, 

It's worth a lot, thanks!

> I do my "submission" copies off the web interface, which does
> produce the right boilerplate. 
> 
> Or at least, my submission was accepted, which is good enough for me.
> 
> Dave.

From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Mar  6 06:48:56 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-03-06 14:50, Glen Zorn (gwz) wrote:
> Hi.  I've received this lovely missive twice in the last 2 days.  I've
> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is there a
> magic incantation I can use to a) stop the IETF from changing the
> boilerplate every 6 months,

I don't think so. Legal conditions do evolve. The most recent change
(to mention the IETF Trust) was phased in over many months with
multiple warnings. And still some people missed it...

> b) make xml2rfc insert the correct
> boilerplate,

It does, but you must use the current version.

> c) turn xml2rfc into actual production toy

I've been using it (the on-line version) as a production tool
for at least two years. What's the issue? Apart from it being
maintained by competent and motivated *volunteers*, that is.

     Brian
>From elwynd at dial.pipex.com  Tue Mar  6 14:52:30 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar  6 06:51:46 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

FWIW  I have just run both the web version and a newly downloaded 
version of xml2rfc r1.32 and they both appear to generate the complained 
of boilerplate not just word perfect but in the format specified below.

Not sure what the problem you are encountering is but I have attached a 
template that does appear to generate the right boilerplate.

Regards,
Elwyn

Glen Zorn (gwz) wrote:
> Hi.  I've received this lovely missive twice in the last 2 days.  I've
> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is there a
> magic incantation I can use to a) stop the IETF from changing the
> boilerplate every 6 months, b) make xml2rfc insert the correct
> boilerplate, c) turn xml2rfc into actual production toy or (preferably)
> d) all of the above?
>
>  [email-masked] <mailto:[email-masked]> allegedly scribbled on Monday, March
> 05, 2007 11:57 AM:
>
>   
>>>  <<draft-zorn-dime-diameter-base-protocol-mib-01.txt>>
>>>
>>>       
>> The Secretariat CANNOT process your Internet-Draft submission due to
>> following reason(s):  * All Internet-Drafts must include the
>> following  
>> statement:
>>
>> Copyright (C) The IETF Trust (2007).
>>
>>  * All Internet-Drafts must include the following statement near the
>> end of the document.: 
>>
>> This document and the information contained herein are provided on an
>> "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
>> OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
>> THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
>> OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
>> THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
>> WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.   
>>     
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: template-edu-full-03.xml
Type: text/xml
Size: 33338 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/68d518eb/template-edu-full-03-0001.xml
>From fenner at gmail.com  Tue Mar  6 06:57:17 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 06:57:20 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Glen Zorn (gwz) <[email-masked]> wrote:
> Hi.  I've received this lovely missive twice in the last 2 days.  I've
> duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.

If you still have the formatted versions that were rejected, could you
send them to me?

> a) stop the IETF from changing the
> boilerplate every 6 months

Don't worry, more change is coming.

> b) make xml2rfc insert the correct boilerplate

As far as I know there's no way to get it to insert the wrong one,
which is why I'm interested in seeing copies of your formatted files.

Thanks,
  Bill
>From paul.hoffman at vpnc.org  Tue Mar  6 08:54:53 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Mar  6 08:55:03 2007
Subject: [xml2rfc] FW:
 draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
 <[email-masked]>
 <[email-masked]>
Message-ID: <p06240864c2134bf64356@[10.20.30.108]>

At 3:48 PM +0100 3/6/07, Brian E Carpenter wrote:
>>c) turn xml2rfc into actual production toy
>
>I've been using it (the on-line version) as a production tool
>for at least two years. What's the issue?

There are many issues:

- Typical IETFers don't know when a new version comes out

- You can't tell that your draft is going to be rejected until after 
it is rejected

>Apart from it being
>maintained by competent and motivated *volunteers*, that is.

- The time it takes for those volunteers to do the maintenance could 
be better spent on them either improving the product (such as a UI 
that the entire IETF can understand, not just people who can read 
stack traces) or, even better, working on Internet protocols.

Given how important xml2rfc is to the IETF process, development and 
maintenance should be professionally done. It is logical for the RFC 
Editor to do it (they are a major user of the tool, or should be); it 
is logical for the Secretariat to do it (they are the keepers of the 
professionally-maintained IETF tools).

Obviously, this group should be able to contribute and help maintain 
and kibbitz and get credit for all the early work.

--Paul Hoffman, Director
--VPN Consortium
>From nobody at xyzzy.claranet.de  Tue Mar  6 18:35:32 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Mar  6 09:36:58 2007
Subject: [xml2rfc] 
	Re: FW:
	 draft-zorn-dime-diameter-base-protocol-mib-01.txt
References: <[email-masked]>
	<p06240864c2134bf64356@[10.20.30.108]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:

> Given how important xml2rfc is to the IETF process, development and
> maintenance should be professionally done. It is logical for the RFC
> Editor to do it (they are a major user of the tool, or should be); it
> is logical for the Secretariat to do it (they are the keepers of the
> professionally-maintained IETF tools).

Maybe later when 2629bis is published as RFC.  As long as there are 
minor tweaks needed in the DTD it's not the best point in time to ask
the RFC editor or the Secretariat to take over.

In combination with Bill's validator the online tools (both stable and
experimental) are IMO professional.  Maybe that could be moved to the
IETF tools server later, after Bill upgraded his DTD to the DTD used 
by 1.32 (again those DTDs...).  

The most important xml2rfc feature from my POV is the bibxml database,
and the scripts working behind the scenes to keep this database up to
date.  That worked perfectly since I watch it, and it would be a huge
mess if it suddenly ceased to work.

Is what you ask for (as "professional maintenance") actually a backup
server ?

Frank

From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 09:52:16 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Paul Hoffman <[email-masked]> wrote:
> - The time it takes for those volunteers to do the maintenance could
> be better spent on them either improving the product

That's what I thought Brian was talking about.

> (such as a UI
> that the entire IETF can understand, not just people who can read
> stack traces)

There is one remaining failure mode of which I'm aware that gives a
tcl error instead of a user-understandable error (an xref to an
undefined reference, which I've just fixed in my development copy).
If you know of some that I don't, please let us know.

  Bill
>From mrose at dbc.mtview.ca.us  Tue Mar  6 09:59:57 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar  6 10:00:06 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> It's worth a lot, thanks!
>
>> I do my "submission" copies off the web interface, which does
>> produce the right boilerplate.

glen - the web interface is version 1.32 and the current release is  
version 1.32, so they ought to be producing "the same thing".

and, afaik, "the same thing" is "the right thing".

please send a copy of the offending draft to bill and myself, so we  
can take a look at it.

/mtr

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Mar  6 10:19:27 2007
Subject: [xml2rfc]	Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <p06240864c2134bf64356@[10.20.30.108]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Mar 06, 2007 at 06:35:32PM +0100, Frank Ellermann wrote:
> Paul Hoffman wrote:
> 
> > Given how important xml2rfc is to the IETF process, development and
> > maintenance should be professionally done. It is logical for the RFC
> > Editor to do it (they are a major user of the tool, or should be); it
> > is logical for the Secretariat to do it (they are the keepers of the
> > professionally-maintained IETF tools).
> 
> Maybe later when 2629bis is published as RFC.  As long as there are 
> minor tweaks needed in the DTD it's not the best point in time to ask
> the RFC editor or the Secretariat to take over.

I don't see why the secretariat couldn't make xml2rfc part of the IETF
tools project and throw its resources at finishing rfc2629bis.

> In combination with Bill's validator the online tools (both stable and
> experimental) are IMO professional.  Maybe that could be moved to the
> IETF tools server later, after Bill upgraded his DTD to the DTD used 
> by 1.32 (again those DTDs...).  

I doubt Paul meant to demean the current support of xml2rfc as not
professional.  I think he meant that it would help if the IETF tools
project takes ownership of xml2rfc.

> The most important xml2rfc feature from my POV is the bibxml database,
> and the scripts working behind the scenes to keep this database up to
> date.  That worked perfectly since I watch it, and it would be a huge
> mess if it suddenly ceased to work.

That is quite valuable.

> Is what you ask for (as "professional maintenance") actually a backup
> server ?

I think that Paul was referring to having funded support and
development.

Nico
-- 
>From paul.hoffman at vpnc.org  Tue Mar  6 11:31:59 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Mar  6 11:32:12 2007
Subject: [xml2rfc]  	Re: FW: 	
 draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
 <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <p06240869c213720d30c7@[10.20.30.108]>

The folks on this list probably do not hear the complaints about 
xml2rfc from the IETFers that some of us do. In particular, when I 
was co-presenting the WG Leadership trainings on Sundays, we would 
hear chairs ask "some of my authors can't figure out xml2rfc, what 
should we tell them". When I was co-editing the Tao of the IETF, I 
got lots of comments to the effect of "you should not promote xml2rfc 
so much until it is more usable".

This is *not* the fault of this list, or of Marshall. xml2rfc is an 
excellent tool for those of us who can figure it out. However, when 
using the tool starts to become the only way to be sure that your 
Internet Draft will be accepted reliably, the tool needs to be more 
useful to more typical IETFers. In specific, it means that at least 
90% (I would say 98%) of all I-D authors need to be able to use it 
without problems. Getting it from its current state to that state is 
not a good use of volunteer time of the people on this list.

At 9:52 AM -0800 3/6/07, Bill Fenner wrote:
>There is one remaining failure mode of which I'm aware that gives a
>tcl error instead of a user-understandable error (an xref to an
>undefined reference, which I've just fixed in my development copy).
>If you know of some that I don't, please let us know.

This is not about "failure modes", unless you consider a user not 
being able to understand an error message to be a failure mode. When 
I work with co-authors not as familiar with XML as I am, they often 
have a terrible time editing the text and seeing if it worked.

As just one example from real life (problems co-authors of mine have 
had), leaving off a </section> somewhere produces the following error:

end tag "middle" does not match open element "section" around line 330
     while executing
"unexpected error {end tag "middle" does not match open element 
"section" around line 330}"
     ("uplevel" body line 1)
     invoked from within
"uplevel #0 $options(-errorcommand) [list "end tag \"$tag\" does not 
match open element \"[lindex $state(stack) end]\" around line 
$state(lineo)"]"
     (procedure "ParseEvent:ElementClose" line 9)
     invoked from within
. . .

That may not be understandable to typical document authors, Even if 
they do understand that they left off a </section> somewhere, it 
doesn't help them find out where.

A good tool would show them the structure of their sections at that 
point, and they could see that what they thought would be section 
3.2.2 was going to be section 3.2.1.1, and it al went to hell after 
that.

Just to be clear: there is *no* expectation that people here should 
write such a tool. But there is an expectation that if xml2rfc is the 
preferred IETF tool for Internet Draft creation, there is an 
expectation that the IETF make it usable to the vast majority of IETF 
authors. The IETF has money to create and maintain these tools. We 
also have plenty of advisors who will help point out what the tools 
should do, and in this case, already have a good prototype of the 
internals. And, as we all know on this list, there is much 
documentation that is needed in order for someone in the lower 25% of 
XML-enabled I-D authors to use xml2rfc without wasting hours guessing 
what to do.

At 6:35 PM +0100 3/6/07, Frank Ellermann wrote:
>Paul Hoffman wrote:
>
>  > Given how important xml2rfc is to the IETF process, development and
>>  maintenance should be professionally done. It is logical ...
>...snip...
>>... should be); it
>>  is logical for the Secretariat to do it (they are the keepers of the
>>  professionally-maintained IETF tools).
>
>Maybe later when 2629bis is published as RFC.  As long as there are
>minor tweaks needed in the DTD it's not the best point in time to ask
>the RFC editor or the Secretariat to take over.

With paid developers working on the tool, 2629bis will take shape 
much more quickly, driven in part by the developers noticing things 
that are not quite right. This is how many IETF protocols get to 
completion.

>The most important xml2rfc feature from my POV is the bibxml database,
>and the scripts working behind the scenes to keep this database up to
>date.  That worked perfectly since I watch it, and it would be a huge
>mess if it suddenly ceased to work.

Fully agree about the importance of this.

>Is what you ask for (as "professional maintenance") actually a backup
>server ?

No, it's much more than that. See above.

--Paul Hoffman, Director
--VPN Consortium
>From Nicolas.Williams at sun.com  Tue Mar  6 13:50:27 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Mar  6 11:51:06 2007
Subject: [xml2rfc]  	Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <p06240869c213720d30c7@[10.20.30.108]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <p06240869c213720d30c7@[10.20.30.108]>
Message-ID: <[email-masked]>

On Tue, Mar 06, 2007 at 11:31:59AM -0800, Paul Hoffman wrote:
> The folks on this list probably do not hear the complaints about 
> xml2rfc from the IETFers that some of us do. In particular, when I 
> was co-presenting the WG Leadership trainings on Sundays, we would 
> hear chairs ask "some of my authors can't figure out xml2rfc, what 
> should we tell them". When I was co-editing the Tao of the IETF, I 
> got lots of comments to the effect of "you should not promote xml2rfc 
> so much until it is more usable".

I find it very usable now.  In particular its messages about mis-matched
tags are useful nowadays (they didn't use to be).

> A good tool would show them the structure of their sections at that 
> point, and they could see that what they thought would be section 
> 3.2.2 was going to be section 3.2.1.1, and it al went to hell after 
> that.

The current error messages aren't as helpful as that, but they tell you
what went wrong where.  E.g.:

xml2rfc: error: xml2rfc: error: end tag "list" does not match open
element "t" around input line 213

says that I left off a </t> inside a <list> and tells me the line number
where the <list> is to be found.  (The double "xml2rfc: error:" seems
like a bug though.)

Now, if there are many list items then I may have a hard time finding
which <t> has a missing </t>, but since one can nest <t> and <list> (and
one often does) it's difficult for the tool to do much better.  Proper
indentation helps, of course, and so does having an editor with syntax
highlighting; both are out of scope for xml2rfc.

A better example of the limitations of xml2rfc would be the recent
report of difficulties with huge tables.

Nico
-- 
>From fenner at gmail.com  Tue Mar  6 15:26:42 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 12:26:48 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Nicolas Williams <[email-masked]> wrote:
> On Tue, Mar 06, 2007 at 11:31:59AM -0800, Paul Hoffman wrote:
> > A good tool would show them the structure of their sections at that
> > point, and they could see that what they thought would be section
> > 3.2.2 was going to be section 3.2.1.1, and it al went to hell after
> > that.
>
> The current error messages aren't as helpful as that, but they tell you
> what went wrong where.  E.g.:
>
> xml2rfc: error: xml2rfc: error: end tag "list" does not match open
> element "t" around input line 213

This is exactly the error that Paul said was not useful.  Different
expectations from different points of view.

This is the continuing question of how xml2rfc should deal with XML
input that is not well-formed or not valid.  One point of view is that
creating valid XML is the job of the authoring tool, and validating
XML is the job of the validation tool, and neither of those are
xml2rfc's job.  I created my validation tool and my authoring tool
specifically because of these gaps.

Paul is describing a tool that would help create a well-formed XML
document from one that is not well-formed.  (And, presumably, it would
also want to help create a valid document.)

  Bill
>From Nicolas.Williams at sun.com  Tue Mar  6 14:43:09 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Mar  6 12:43:58 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Mar 06, 2007 at 03:26:42PM -0500, Bill Fenner wrote:
> On 3/6/07, Nicolas Williams <[email-masked]> wrote:
> >The current error messages aren't as helpful as that, but they tell you
> >what went wrong where.  E.g.:
> >
> >xml2rfc: error: xml2rfc: error: end tag "list" does not match open
> >element "t" around input line 213
> 
> This is exactly the error that Paul said was not useful.  Different
> expectations from different points of view.

I thought Paul was complaining about backtraces in errors....

> This is the continuing question of how xml2rfc should deal with XML
> input that is not well-formed or not valid.  One point of view is that
> creating valid XML is the job of the authoring tool, and validating
> XML is the job of the validation tool, and neither of those are
> xml2rfc's job.  I created my validation tool and my authoring tool
> specifically because of these gaps.

Both of those would be generic tools, but xml2rfc is an IETF-specific
tool.  Editors and validators would be out of scope for the IETF tools
project, no?

Nico
-- 
>From paul.hoffman at vpnc.org  Tue Mar  6 13:18:33 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Mar  6 13:18:50 2007
Subject: [xml2rfc] Re: FW:
 draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>	
	<[email-masked]>	
	<[email-masked]>	
	<[email-masked]>
	<[email-masked]>
Message-ID: <p06240871c213891b97f3@[10.20.30.108]>

At 3:26 PM -0500 3/6/07, Bill Fenner wrote:
>Paul is describing a tool that would help create a well-formed XML
>document from one that is not well-formed.  (And, presumably, it would
>also want to help create a valid document.)

Exactly. Unless we start expecting all I-D authors to use XML editors 
to create their I-Ds, it is completely safe to assume that they will 
sometimes create versions that are not well-formed. From my 
experience with co-authors, this will happen often.

Some of the errors are easy to find, such as Nico's:
xml2rfc: error: xml2rfc: error: end tag "list" does not match open
element "t" around input line 213

Others are much harder, such as the example I gave earlier. There are 
many, many others. It is easy to imagine a tool or a set of tools 
that could help in this, and it certainly easy to imagine what kind 
of documentation would help users where the current doc doesn't ("how 
do I add an example", "how do I keep the lines together", "do I 
really need to type in all the info for the RFC references", ...)

--Paul Hoffman, Director
--VPN Consortium
>From Nicolas.Williams at sun.com  Tue Mar  6 15:35:16 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Mar  6 13:35:56 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <p06240871c213891b97f3@[10.20.30.108]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<p06240871c213891b97f3@[10.20.30.108]>
Message-ID: <[email-masked]>

On Tue, Mar 06, 2007 at 01:18:33PM -0800, Paul Hoffman wrote:
> At 3:26 PM -0500 3/6/07, Bill Fenner wrote:
> >Paul is describing a tool that would help create a well-formed XML
> >document from one that is not well-formed.  (And, presumably, it would
> >also want to help create a valid document.)
> 
> Exactly. Unless we start expecting all I-D authors to use XML editors 
> to create their I-Ds, it is completely safe to assume that they will 
> sometimes create versions that are not well-formed. From my 
> experience with co-authors, this will happen often.

Maybe we should expect I-D authors to use XML editors.  (I use VIM with
syntax highlighting -- not quite an XML editor, but close enough to make
do).
>From elwynd at dial.pipex.com  Tue Mar  6 22:47:47 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar  6 14:47:11 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <p06240871c213891b97f3@[10.20.30.108]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>		<[email-masked]>
	<[email-masked]>
	<p06240871c213891b97f3@[10.20.30.108]>
Message-ID: <[email-masked]>

The edu team commissioned a training session which was given at 
Vancouver and Montreal.  The slides and a couple of templates created to 
go with them can be found at 
http://www3.ietf.org/proceedings/06mar/xml2rfc.html.  It covers r1.30 
and r1.31: 1.32 isn't much different apart from the boilerplate.

The edu team are envisaging giving this course again in Chicago.

Input on improving the course would be welcomed by the author (me).  It 
will be updated to whatever release of xml2rfc is then current (ie at 
least 1.32).

I think this tells you quite a lot of the hints and tips mentioned here.

Personally I use a combination of XMLmind with Bill F's xml2rfc plugin 
for most editing (especailly when creating a draft from scratch) and 
jEdit for adding external references to the bibliographic library which 
is beyond XMLmind's capabilities at present.  XMLmind pretty much stops 
you getting malformed xml2rfc and handles all the balancing of begin and 
end tags.

I have been slowly working on a complicated piece of code to  convert a 
text draft into xml2rfc but it is not easy - all heuristics.   Bill's 
xml2rfc validator is very good value for checking and debugging xml - 
much better than the formatter.

Regards,
Elwyn

Paul Hoffman wrote:
> At 3:26 PM -0500 3/6/07, Bill Fenner wrote:
>> Paul is describing a tool that would help create a well-formed XML
>> document from one that is not well-formed.  (And, presumably, it would
>> also want to help create a valid document.)
>
> Exactly. Unless we start expecting all I-D authors to use XML editors 
> to create their I-Ds, it is completely safe to assume that they will 
> sometimes create versions that are not well-formed. From my experience 
> with co-authors, this will happen often.
>
> Some of the errors are easy to find, such as Nico's:
> xml2rfc: error: xml2rfc: error: end tag "list" does not match open
> element "t" around input line 213
>
> Others are much harder, such as the example I gave earlier. There are 
> many, many others. It is easy to imagine a tool or a set of tools that 
> could help in this, and it certainly easy to imagine what kind of 
> documentation would help users where the current doc doesn't ("how do 
> I add an example", "how do I keep the lines together", "do I really 
> need to type in all the info for the RFC references", ...)
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From henrik at levkowetz.com  Tue Mar  6 23:53:00 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue Mar  6 14:53:10 2007
Subject: [xml2rfc]	Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<p06240864c2134bf64356@[10.20.30.108]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Nicolas,

on 2007-03-06 19:18 Nicolas Williams said the following:
> On Tue, Mar 06, 2007 at 06:35:32PM +0100, Frank Ellermann wrote:
>> Paul Hoffman wrote:
>> 
>> > Given how important xml2rfc is to the IETF process, development and
>> > maintenance should be professionally done. It is logical for the RFC
>> > Editor to do it (they are a major user of the tool, or should be); it
>> > is logical for the Secretariat to do it (they are the keepers of the
>> > professionally-maintained IETF tools).
>> 
>> Maybe later when 2629bis is published as RFC.  As long as there are 
>> minor tweaks needed in the DTD it's not the best point in time to ask
>> the RFC editor or the Secretariat to take over.
> 
> I don't see why the secretariat couldn't make xml2rfc part of the IETF
> tools project and throw its resources at finishing rfc2629bis.

If by 'the IETF tools project' you mean the IETF Tools Team, I'd like to
clarify that the Tools Team are also volunteers, with Bill and myself
being the most active members.

[snip]

	Henrik
>From Nicolas.Williams at sun.com  Tue Mar  6 16:54:50 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Mar  6 14:55:32 2007
Subject: [xml2rfc]	Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<p06240864c2134bf64356@[10.20.30.108]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Mar 06, 2007 at 11:53:00PM +0100, Henrik Levkowetz wrote:
> > I don't see why the secretariat couldn't make xml2rfc part of the IETF
> > tools project and throw its resources at finishing rfc2629bis.
> 
> If by 'the IETF tools project' you mean the IETF Tools Team, I'd like to
> clarify that the Tools Team are also volunteers, with Bill and myself
> being the most active members.

Ah.  Then never mind :)  Keep doing what you're doing.
>From fenner at gmail.com  Tue Mar  6 15:01:44 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 15:01:51 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Elwyn Davies <[email-masked]> wrote:
> Personally I use a combination of XMLmind with Bill F's xml2rfc plugin
> for most editing (especailly when creating a draft from scratch) and
> jEdit for adding external references to the bibliographic library which
> is beyond XMLmind's capabilities at present.

To be clear, xxe Professional Edition can manage external references
for you, including entity references to bibliography files.  Even
though I have Professional Edition, I usually use the <?rfc include=?>
method, which xxe can handle (and in fact there's a menu item to
insert).

  Bill
>From elwynd at dial.pipex.com  Tue Mar  6 23:08:09 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Mar  6 15:07:26 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On 3/6/07, Elwyn Davies <[email-masked]> wrote:
>> Personally I use a combination of XMLmind with Bill F's xml2rfc plugin
>> for most editing (especailly when creating a draft from scratch) and
>> jEdit for adding external references to the bibliographic library which
>> is beyond XMLmind's capabilities at present.
>
> To be clear, xxe Professional Edition can manage external references
> for you, including entity references to bibliography files.  Even
> though I have Professional Edition, I usually use the <?rfc include=?>
> method, which xxe can handle (and in fact there's a menu item to
> insert).
>
>  Bill
Sorry - I was talking about the standard edition (free).

/Elwyn
>From gwz at cisco.com  Tue Mar  6 15:21:39 2007
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 15:21:54 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies <mailto:[email-masked]> allegedly scribbled on
Tuesday, March 06, 2007 6:53 AM:

> FWIW  I have just run both the web version and a newly downloaded
> version of xml2rfc r1.32 and they both appear to generate the
> complained of boilerplate not just word perfect but in the format
> specified below.  

The Web version seems to work fine, but my (also freshly downloaded)
1.32 produces the attached (note the lack of the "IETF Trust" stuff).

> 
> Not sure what the problem you are encountering is but I have attached
> a template that does appear to generate the right boilerplate. 
> 

...
-------------- next part --------------

Internet Engineering Task Force                                P. Savola
Internet-Draft                                       Abbreviated OrgName
Updates: 2345 (if approved)                               E. Davies, Ed.
Obsoletes: 999, 2567 (if approved)                      Folly Consulting
Expires: September 2, 2006                                    March 2006

                               Full Title
              draft-ietf-edu-xml2rfc-full-template-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created, except to publish it as an RFC and to translate it into
   languages other than English, other than to extract Section 6 as-is
   for separate use.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This is an abstract abstract.  I-Ds and RFCs MUST have an abstract
   but other uses might not want an abstract so it is optional unless
   strict="yes".  Remember, don't add references here.  So we would just

Savola & Davies         Expires September 2, 2006               [Page 1]

Internet-Draft              Abbreviated-Title                 March 2006

   say the 'language' used to write this document is defined in RFC
   2629.

Foreword

   This "foreword" section is an unnumbered section that is not included
   in the table of contents.  It is primarily used for the IESG to make
   comments about the document.  It can also be used for comments about
   the status of the document and sometimes is used for the RFC2119
   requirements language statement.

   In this example, it is used as a handy place to specify URLs to
   documents and tools to author RFC-style documents using XML.

   RFC2629 is the original published document on authoring RFC-style
   documents in XML
   (<http://xml.resource.org/public/rfc/html/rfc2629.html>).  It is
   being updated (and called RFC2629(bis) and is
   <http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html>.
   The tool to convert XML documents to RFC-style text (and HTML) files
   is described in document
   <http://xml.resource.org/authoring/README.html>.

   Please also remember to check out
   <http://www.ietf.org/ID-Checklist.html> for issues to note when
   writing drafts and the automated tools documented at
   <http://tools.ietf.org/tools/>.

   Remember, you don't need to have any other tools than a 'notepad' or
   your favorite editor to write xml2rfc drafts.  You can use the web
   interface at <http://xml.resource.org> for processing.  The benefit
   of using XML editors is mostly catching those missing tags which the
   processor will warn you about, but you don't need to worry about the
   editors when getting started.

   This template is not meant to be a conclusive list of everything, but
   will summarize the often-needed basic features to get one started.

Requirements Language

   This example makes extensive use of &quot;(")and &apos;(') entities:
   this is not strictly necessary but may avoid problems if pieces of
   text are moved into attribute values, where it would be necessary.
   It also avoids problems if the text is edited with Microsoft Word
   with the 'smart quotes' option turned on (see Word menu Tools->Auto
   Correct Options, 'AutoFormat As You Type' tab) which might result in
   the left and right quotes characters replacing the ASCII character.

Savola & Davies         Expires September 2, 2006               [Page 2]

Internet-Draft              Abbreviated-Title                 March 2006

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   An Example Section . . . . . . . . . . . . . . . . . . . . .   4
     2.1  A Subsection . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2  Tables . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.   More About Lists . . . . . . . . . . . . . . . . . . . . . .   6
     3.1  Numbering Lists Across Lists and Sections  . . . . . . . .   7
     3.2  Where the List Numbering Continues . . . . . . . . . . . .   8
   4.   Using Typed Artwork  . . . . . . . . . . . . . . . . . . . .   8
   5.   Decrypting XML2RFC Parsing Errors  . . . . . . . . . . . . .   9
   6.   Example of code or MIB module to be extracted  . . . . . . .  10
   7.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  10
   8.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  11
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  11
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  11
     10.1   Normative References . . . . . . . . . . . . . . . . . .  11
     10.2   Informative References . . . . . . . . . . . . . . . . .  11
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  11
   A.   Additional Stuff . . . . . . . . . . . . . . . . . . . . . .  12
        Intellectual Property and Copyright Statements . . . . . . .  13

Savola & Davies         Expires September 2, 2006               [Page 3]

Internet-Draft              Abbreviated-Title                 March 2006

1.  Introduction

   Now you can have a bit lengthier text here.

   The definition of the XML Data Type Description used to 'describe' an
   RFC or Internet Draft can be found in a document which we can refer
   to as RFC 2629 [2].

   Let's refer to a couple more documents, just for practice: "Ultimate
   Plan for Taking Over The World" [4] and L2TP [3].  For text
   generation, these look equivalent, but the latter looks a bit neater
   in the HTML representation.

   You might also add a note about the usage of RFC2119 keywords here
   using the same text as in the note above.

   You can cross-reference the sections of the document in a stable
   manner either by section number (Section 2) - the usual way - or by
   section title ("An Example Section"): if the organization of the
   document changes the reference will still be to the correct section.
   However "sect2" is not a very good 'anchor' name because there is no
   guarantee that this section will remain as Section 2 for ever.  It is
   best to use some sort of mnemonic for the contents of the section,
   which also makes it easier to remember the anchor when creating a
   cross-reference many pages later.  A final note about anchors:
   anchors are XML 'tokens' and must therefore consist only of letters,
   numbers, underscores, hyphens and periods, starting with either a
   letter or underscore.  Anchors with spaces or other punctuation
   characters are not allowed.

2.  An Example Section

   Technical documents often use lists.  There are multiple list styles:
   'empty', 'symbols', 'letters', 'numbers', 'hanging', 'format', etc.

   A more complicated list structure can be found in Section 3.

   o  First bullet

   o  Second bullet

   You can write text here as well - the difference, as compared with
   putting it in the next <t> element, is that there will not be a blank
   line between the last list item and this text if the processing
   instructions compact and subcompact are both set to "yes".  Otherwise
   list items and the text before and after will be separated by blank
   lines.

Savola & Davies         Expires September 2, 2006               [Page 4]

Internet-Draft              Abbreviated-Title                 March 2006

   One can draw fancy diagrams as well; remember to ensure that they
   don't exceed 69 chars/line until v1.31 comes along. v1.31 should give
   you the ability to start figures at the left margin getting figures
   up to 72 characters wide.

   Setting the alignment for the whole figure to "center" instead of the
   default "left" causes all the components to be centred unless it is
   overridden just for the "artwork", as it is here.

    Figures can have some text before the artwork should it be needed.
   Note that figures should NOT be inside <t> elements.  Originally they
      were allowed to be but you will now get a warning that this is
       deprecated, and the figure should be a 'child' of the section
                                 element.

   +-----------------------+
   | Use XML, be Happy :-) |
   |_______________________|

    Figures can also have text after the artwork and before the caption
     (if any).  This figure has an anchor.  This means that the figure
                          will get a caption...

                                 Figure 1

   Note that including a CDATA means you don't need to escape most
   special characters you might otherwise have to.  Figures may also
   have a title attribute but it won't be displayed unless there is also
   an anchor, and it will be somewhat disconcerting for readers if some
   figures have numbers and others don't..

2.1  A Subsection

   There can be a lot of subsections (and sub-subsections).  By default
   3 levels of nesting show in the Table of Contents but that can be
   adjusted with the value of the "tocdepth" processing instruction.
   There are also attributes that can be used to force individual titles
   in and out of the Table of Contents.

2.2  Tables

   Another item that you might need is a table.  The XML for tables is
   very similar to that for figures:

Savola & Davies         Expires September 2, 2006               [Page 5]

Internet-Draft              Abbreviated-Title                 March 2006

   Tables use ttcol to define column headers and widths.  Every cell
   then has a "c" element for its content.

                        +----------+----------+
                        | ttcol #1 | ttcol #2 |
                        +----------+----------+
                        |   c #1   |   c #2   |
                        |   c #3   |   c #4   |
                        |   c #5   |   c #6   |
                        +----------+----------+

   which is a very simple example.

                       Table 1: A Very Simple Table

3.  More About Lists

   One useful style of lists uses 'hanging labels' where the list item
   is indented by the amount of the hangIndent with the hanging label
   displayed to the left of the first line of the item.  This example
   shows how <vspace> can be used to deal with the odd label longer than
   the indent you really want to use (This is only really relevant to
   text mode output because the labels are always on separate lines in
   HTML output):

   short   With a label shorter than the hangIndent there is white space
           after the label and before the item text starts although it
           starts on the same line - clearly separating the label from
           the column of items.

   fantastically long label With a label longer than the hangIndent the
           label runs on into the text item and the separation is lost.

   vspace_trick
           Inserting a <vspace /> at the start of the item forces the
           new item to start on a new line emphasizing the separation
           again.

Savola & Davies         Expires September 2, 2006               [Page 6]

Internet-Draft              Abbreviated-Title                 March 2006

   List items in xml2rfc are made up of one <t> element.  In some cases
   it would be nice to have more than one paragraph in a list item.
   This can be achieved with <vspace> also:

   a.  First, a short item that needs only one paragraph.

   b.  Second, a longer list item.  We have more to say, and we want a
       separate paragraph.

       And here we can have it, and go on to our heart's content.

   If you just want an indented paragraph (say for a quotation) use the
   "empty" style:

             The quick, brown fox jumped over the lazy dog and lived to
             fool many another hunter in the great wood in the west.

3.1  Numbering Lists Across Lists and Sections

   Sometimes it is useful to be able to number items continuously
   although they are in separate <list> elements, maybe in separate
   sections.  This can be achieved using the "format" style and a
   "counter" variable.

   First list with (say) requirements items:

   R1  Requirement #1

   R2  Requirement #2

   R3  Requirement #3

   It is wise to specify the indent explicitly so that all the items
   line up nicely.  Otherwise the indent in each list is determined by
   the maximum length of the labels in that list, even if later lists
   have longer labels.

   A little later there is a second list with requirements items:

   R4  Requirement #4

   R5  Requirement #5

   R6  Requirement #6

   before this section finishes.

Savola & Davies         Expires September 2, 2006               [Page 7]

Internet-Draft              Abbreviated-Title                 March 2006

3.2  Where the List Numbering Continues

   But in the next section the list of requirements continues:

   Third list with requirements items:

   R7  Requirement #7

   R8  Requirement #8

   R9  Requirement #9

   R10 Requirement #10

   And finally that is all about the requirements.

4.  Using Typed Artwork

   The "artwork" element from RFC 2629 supports an optional "type"
   attribute.  While most possible values are just ignored, including
   the special case where the attribute is unspecified or just empty,
   some values are recognized.  In particular, "type='abnf'" can be used
   if the "artwork" contains an Augmented Backus-Naur Form (ABNF) syntax
   specification [5].  As a special extension in its _behavior_,
   *xml2rfc* will attempt to validate the syntax and colorize the HTML
   output of ABNF, since it is so widely used in RFCs.  It does this
   colorizing by relying on the full parsing it does right before, not
   on a quick and partial (e.g., line-by-line) pattern-based hack.  ABNF
   is the only artwork type to benefit from this kind of internal
   support at this time.  If the "strict" rfc-PI directive is activated,
   invalid ABNF content will cause *xml2rfc* to abort with an error
   message.  Omitting the "type" attribute altogether is the obvious way
   to avoid having this validation and colorizing performed.

Savola & Davies         Expires September 2, 2006               [Page 8]

Internet-Draft              Abbreviated-Title                 March 2006

   For example (to be viewed in HTML):

         char-val       =  DQUOTE *(%x20-21 / %x23-7E) DQUOTE
                                ; quoted string of SP and VCHAR
                                   without DQUOTE

         num-val        =  "%" (bin-val / dec-val / hex-val)

         bin-val        =  "b" 1*BIT
                           [ 1*("." 1*BIT) / ("-" 1*BIT) ]
                                ; series of concatenated bit values
                                ; or single ONEOF range

         dec-val        =  "d" 1*DIGIT
                           [ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]

         hex-val        =  "x" 1*HEXDIG
                           [ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]

         prose-val      =  "<" *(%x20-3D / %x3F-7E) ">"
                                ; bracketed string of SP and VCHAR
                                   without angles
                                ; prose description, to be used as
                                   last resort

   This is from the original RFC on ABNF [6], with its minor mistakes in
   manually folded comment lines purposely left intact, for
   illustration.  Since the result is still valid ABNF (but incorrect
   with respect to what was intended), this showcases how colorizing
   might give a human author (or editor or reader) a better chance to
   spot the three mistakes (and correct them, e.g., with extra
   semicolons, as has been done in a more recent version [5] of the ABNF
   specification).  Note that it is the white space characters at the
   beginning of the subsequent lines (including the commented ones) that
   conspire to extend the reach of those rules across several lines.

5.  Decrypting XML2RFC Parsing Errors

   The most common form of xml2rfc parsing errors are those where a
   closing tag has been expected to be present before a new kind of tag
   is specified.  In the example below, Introduction section's last
   paragraph was missing the closing t-element.  The rest of the error
   messages can be rather easily understood as well by reading it
   carefully and examining the context.  The reason is typically a
   missing tag somewhere.

Savola & Davies         Expires September 2, 2006               [Page 9]

Internet-Draft              Abbreviated-Title                 March 2006

   ======8<=========
   end tag "section" does not match open element "t" around line 65

   Context:
       <rfc ipr="full3667" category="info"
            docName="draft-ietf-template-edu-full-01.txt"
            updates="1,2"
            obsoletes="3">
       <middle>
       <section title="Introduction">
       <t>
   =======8<========

6.  Example of code or MIB module to be extracted

   /**** an example C program */

   #include <stdio.h>

   void
   main(int argc, char *argv[])
   {
       int i;

       printf("program arguments are:\n");
       for (i = 0; i < argc; i++) {
           printf("%d: \"%s\"\n", i, argv[i]);
       }

       exit(0);
   } /* main */

   /* end of file */

7.  Acknowledgements

   Remember, it's important to acknowledge people who have contributed
   to the work.

   This template was extended from an initial version written by Pekka
   Savola and contributed by him to the xml2rfc project.

Savola & Davies         Expires September 2, 2006              [Page 10]

Internet-Draft              Abbreviated-Title                 March 2006

8.  IANA Considerations

   This memo includes no request to IANA.

   (It's good - indeed pretty much mandatory now - to have an explicit
   note because otherwise IANA wastes cycles trying to figure out if
   something is needed..)

9.  Security Considerations

   Remember to consider security from the start.. and all drafts are
   required to have a security considerations section before they will
   pass the IESG.

10.  References

10.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997,
        <http://xml.resource.org/public/rfc/html/rfc2119.html>.

   [2]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
        June 1999.

   [3]  authSurName, authInitials., "RFC2661", year.

10.2  Informative References

   [4]  Mad Dominators, Inc., "Ultimate Plan for Taking Over the World",
        1984.

   [5]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [6]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

Authors' Addresses

   Pekka Savola
   Full Organization name
   Espoo
   FI

   Email: [email-masked]

Savola & Davies         Expires September 2, 2006              [Page 11]

Internet-Draft              Abbreviated-Title                 March 2006

   Elwyn Davies (editor)
   Folly Consulting
   Soham,
   UK

   Phone: +44 7889 488 335
   Fax:
   Email: [email-masked]
   URI:

Appendix A.  Additional Stuff

   You can add appendices just as regular sections, the only difference
   is that they go within the "back" element, and not within the
   "middle" element.  And they follow the "reference" elements.

Savola & Davies         Expires September 2, 2006              [Page 12]

Internet-Draft              Abbreviated-Title                 March 2006

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Savola & Davies         Expires September 2, 2006              [Page 13]

>From fenner at gmail.com  Tue Mar  6 15:31:29 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 15:31:36 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Glen Zorn (gwz) <[email-masked]> wrote:
> The Web version seems to work fine, but my (also freshly downloaded)
> 1.32 produces the attached (note the lack of the "IETF Trust" stuff).

Can you add "This document produced by &rfc2629.processor;" somewhere
inside a <t> to make sure that you're not accidentally running a
different xml2rfc that's installed somewhere else on your system?

Thanks,
  Bill
>From fenner at gmail.com  Tue Mar  6 19:55:22 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Mar  6 16:55:33 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Paul Hoffman <[email-masked]> wrote:
> Some of the errors are easy to find, such as Nico's:
> xml2rfc: error: xml2rfc: error: end tag "list" does not match open
> element "t" around input line 213
>
> Others are much harder, such as the example I gave earlier.

I'm still confused, since the example you gave earlier was:

end tag "middle" does not match open element "section" around line 330

I guess that's different than the list/t problem because of the amount
of the document that the problem could cover?  Or, is the problem, as
Nico suggests, that the meat of the error message was obfuscated by
the inclusion of a stack trace?

(I don't get stack traces, just the error.)

  Bill
>From paul.hoffman at vpnc.org  Tue Mar  6 17:10:43 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Tue Mar  6 17:10:58 2007
Subject: [xml2rfc] Re: FW:
 draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>	
	<[email-masked]>	
	<[email-masked]>	
	<[email-masked]>	
	<[email-masked]>	
	<[email-masked]>
	<[email-masked]>
Message-ID: <p06240880c213c000d847@[10.20.30.108]>

At 7:55 PM -0500 3/6/07, Bill Fenner wrote:
>I'm still confused, since the example you gave earlier was:
>
>end tag "middle" does not match open element "section" around line 330
>
>I guess that's different than the list/t problem because of the amount
>of the document that the problem could cover?

Yes, that's a big part of it. My co-author didn't even understand 
that this was the issue. "I see a </section> just before <middle>; 
the program must be confused." There was nothing helpful saying "it 
is likely that you forgot a </section> someplace, possibly much 
before line 330." Even more helpful would be "your outline at this 
point would have looked like <some outline>; if you see an extra 
level where you didn't want one, it is likely the missing </section> 
is just before that."

We don't have a feeling for what a typical I-D author will need, but 
if we want the tool to work for >90% of I-D authors, we can be sure 
that the last 20% will need a lot of hand-holding.

>Or, is the problem, as
>Nico suggests, that the meat of the error message was obfuscated by
>the inclusion of a stack trace?

That too, but much less important than the lack of help in 
determining where the error happened.

--Paul Hoffman, Director
--VPN Consortium
>From gwz at cisco.com  Tue Mar  6 20:27:03 2007
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 20:27:32 2007
Subject: [xml2rfc] Re: FW:
	draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <p06240871c213891b97f3@[10.20.30.108]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]><[email-masked]>
	<p06240871c213891b97f3@[10.20.30.108]>
Message-ID: <[email-masked]>

Paul Hoffman <> allegedly scribbled on Tuesday, March 06, 2007 1:19 PM:

> At 3:26 PM -0500 3/6/07, Bill Fenner wrote:
>> Paul is describing a tool that would help create a well-formed XML
>> document from one that is not well-formed.  (And, presumably, it
>> would also want to help create a valid document.)
> 
> Exactly. Unless we start expecting all I-D authors to use XML editors
> to create their I-Ds, it is completely safe to assume that they will
> sometimes create versions that are not well-formed. From my
> experience with co-authors, this will happen often.   

Actually, it's worse than that: I've had documents that xmlspy claimed
were both well-formed and valid, but xml2rfc rejected.  

...

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar  6 20:44:06 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]> <p06240871c213891b97f3@[10.20.30.108]> <[email-masked]>
Message-ID: <[email-masked]>

> Actually, it's worse than that: I've had documents that xmlspy claimed
> were both well-formed and valid, but xml2rfc rejected.

glen - when you encounter something like this, it really would be  
helpful if you'd report this in a somewhat more timely fashion...

/mtr

From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 21:58:41 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner <mailto:[email-masked]> allegedly scribbled on Tuesday,
March 06, 2007 3:31 PM:

> On 3/6/07, Glen Zorn (gwz) <[email-masked]> wrote:
>> The Web version seems to work fine, but my (also freshly downloaded)
>> 1.32 produces the attached (note the lack of the "IETF Trust" stuff).
> 
> Can you add "This document produced by &rfc2629.processor;" somewhere
> inside a <t> to make sure that you're not accidentally running a
> different xml2rfc that's installed somewhere else on your system? 

I inserted this:

<t> This document produced by &rfc2629.processor;</t>

Which produced this:

This document produced by &rfc2629.processor;

:-(
 
> 
> Thanks,
>   Bill

From: gwz at cisco.com (Glen Zorn (gwz))
Date: Tue Mar  6 22:19:36 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]> <p06240871c213891b97f3@[10.20.30.108]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose <mailto:[email-masked]> allegedly scribbled on
Tuesday, March 06, 2007 8:44 PM:

>> Actually, it's worse than that: I've had documents that xmlspy
>> claimed were both well-formed and valid, but xml2rfc rejected.
> 
> glen - when you encounter something like this, it really would be
> helpful if you'd report this in a somewhat more timely fashion... 

I know, mea culpa.  However, this kind of thing _never_ happens when I
have a great deal of time to do things other than just fix it...

> 
> /mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar  6 22:23:46 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]><[email-masked]> <p06240871c213891b97f3@[10.20.30.108]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I know, mea culpa.  However, this kind of thing _never_ happens when I
> have a great deal of time to do things other than just fix it...

sure. but even if you have to hack around it, just send the file  
anyway and forget about it...

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Mar  6 23:29:40 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Glen Zorn (gwz) wrote:
 
> I inserted this:
> <t> This document produced by &rfc2629.processor;</t>

> Which produced this:
> This document produced by &rfc2629.processor;

> :-(

That's fine, it's now clear that your version is NOT
1.32 or 1.32pre2 etc.

Somehow you run an older xml2rfc version, and that's
the reason for your boilerplate problem.

For I-Ds and RFCs you can get a similar effect as with
&rfc2629.processor; by always using:

<?rfc rfcprocack="yes" ?>

The former is some magic not supported by validators 
because it confuses Julian's post-processor when it's
mentioned in the DTD.  With rfcprocack="yes" you don't
have this problem.

Frank

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Mar  6 23:42:55 2007
Subject: [xml2rfc]  Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <p06240871c213891b97f3@[10.20.30.108]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:

> Unless we start expecting all I-D authors to use XML editors
> to create their I-Ds, it is completely safe to assume that they
> will sometimes create versions that are not well-formed. From
> my experience with co-authors, this will happen often.

Yes.  When I'm lost I simply ask the W3C validator or better
Bill's validator to figure out what went wrong.  Maybe the
online tool could start Bill's validator automatically when
it run into serious troubles.

> "how do I add an example", "how do I keep the lines together",
> "do I really need to type in all the info for the RFC references",
> ...

For a start in this direction see
http://www3.ietf.org/proceedings/06jul/slides/xml2rfc-1/sld1.htm

Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Mar  7 00:50:20 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
> <?rfc rfcprocack="yes" ?>
> 
> The former is some magic not supported by validators 
> because it confuses Julian's post-processor when it's
> mentioned in the DTD.  With rfcprocack="yes" you don't
> have this problem.

Nit: it's not a post-processor, it's a full processor. And using named 
entities for including non-static text simply is a bad idea: the right 
way to do this is not to rely on any DTD feature, but to use a special 
element which has well-defined semantics.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Wed Mar  7 11:49:13 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  7 03:02:35 2007
Subject: [xml2rfc] 
 Re: FW:
                draft-zorn-dime-diameter-base-protocol-mib-01.txt
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

  [&rfc2629.processor; vs. rfcprocack="yes"]
>> The former is some magic not supported by validators
>> because it confuses Julian's post-processor when it's
>> mentioned in the DTD.  With rfcprocack="yes" you don't
>> have this problem.

> Nit: it's not a post-processor, it's a full processor.

Yes, some minutes after I sent it... ;-)  s/post/XSLT/

> And using named entities for including non-static text
> simply is a bad idea

It's also used for &rfcXXXX; or similar here.  A hack.

We might still need this &rfc2629.processor; hack for
private documents (like IONs), where rfcprocack="yes"
has no effect in the text output.

Or maybe rfcprocack="yes" could also do something in the
direction of Bill's test string for private documents (?)

> the right way to do this is not to rely on any DTD
> feature, but to use a special element which has
> well-defined semantics.

We certainly agree that using undefined entities doesn't
fly... :-)  An element like <rfc2629.processor /> would
be also clumsy.

Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Mar  7 03:13:58 2007
Subject: [xml2rfc]  Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
>> the right way to do this is not to rely on any DTD
>> feature, but to use a special element which has
>> well-defined semantics.
> 
> We certainly agree that using undefined entities doesn't
> fly... :-)  An element like <rfc2629.processor /> would
> be also clumsy.

Actually that would be the right thing to do in XML (if the 
functionality is really needed).

Best regards, Julian
>From nobody at xyzzy.claranet.de  Wed Mar  7 17:08:23 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Mar  7 08:10:17 2007
Subject: [xml2rfc] Re: FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

>> We certainly agree that using undefined entities doesn't
>> fly... :-)  An element like <rfc2629.processor /> would
>> be also clumsy.
 
> Actually that would be the right thing to do in XML (if
> the functionality is really needed).

You'd have to add such elements to <t>, <spanx> (?), <c> (?), 
<cref> (?), but maybe not to the <t> in an <abstract>.  The
functionality is fine as long as xml2rfc, its DTDs, and the
boilerplates aren't more stable.

Getting better already, it's still full3987, no new full4748.

Maybe for 3987bis xml2rfc introduces a stable fullsh* attribute
using the latest and greatest legalese, like the nice <date />
element with no attributes at all.  It could also offer to omit
the <date /> using a default boilerplate.

At one point in time we'll be able to pick "submit" instead of
"download", and get the I-D automagically announced.  There's
an <area> element, so for 2009 there could be another button
"submit + announce + send pubreq to AD".  Maybe.  

Frank

From: fenner at gmail.com (Bill Fenner)
Date: Wed Mar  7 10:08:56 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 3/6/07, Glen Zorn (gwz) <[email-masked]> wrote:
> Bill Fenner <mailto:[email-masked]> allegedly scribbled on Tuesday,
> March 06, 2007 3:31 PM:
> > Can you add "This document produced by &rfc2629.processor;" somewhere
> > inside a <t> to make sure that you're not accidentally running a
> > different xml2rfc that's installed somewhere else on your system?
>
> I inserted this:
>
> <t> This document produced by &rfc2629.processor;</t>
>
> Which produced this:
>
> This document produced by &rfc2629.processor;

Glen,

  Please carefully check your xml2rfc invocation and make sure that
you're running the one that you think you are.  1.31 and 1.32 will
expand that entity, so you are using 1.30 or before.

compost% tclsh8.4 xml2rfc-1.30/xml2rfc.tcl xml2rfc sample-proc.xml
sample-proc-1.30.txt
compost% tclsh8.4 xml2rfc-1.31/xml2rfc.tcl xml2rfc sample-proc.xml
sample-proc-1.31.txt
compost% tclsh8.4 xml2rfc-1.32/xml2rfc.tcl xml2rfc sample-proc.xml
sample-proc-1.32.txt
compost% grep 'produced by' sample-proc-*.txt
sample-proc-1.30.txt:   This document produced by &rfc2629.processor;
sample-proc-1.31.txt:   This document produced by xml2rfc v1.31
sample-proc-1.32.txt:   This document produced by xml2rfc v1.32

The HTML version has the version number in a <meta name="generator"
for longer back than the entity has been supported, so if you're
curious to find out what version you're actually running you can use
xml2html to generate html output and look in there.

  Bill
>From ned.freed at mrochek.com  Wed Mar  7 16:18:39 2007
From: ned.freed at mrochek.com (Ned Freed)
Date: Wed Mar  7 16:19:43 2007
Subject: [xml2rfc] DTD anomaly: <section><section></section><t/></section>
In-Reply-To: "Your message dated Mon, 05 Mar 2007 13:22:02 -0500"
 <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Hi,

>   I accidentally came across a construct that's valid according to
> rfc2629.dtd but seems to have no useful semantics.

> <section title="Introduction">
> <t>Paragraph 1 of Section 1</t>
>   <section title="Subsection">
>   <t>Paragraph 1 of Section 1.1</t>
>   </section>
> <t>Semantically, this is paragraph 2 of section 1.  However, it
> renders as paragraph 2 of Section 1.1.</t>
> </section>

> xml2rfc and Julian's xslt both render the final <t> in a way that
> makes it indistinguishable (visually) from being the second paragraph
> of section 1.1.

> I'm inclined to have xml2rfc reject this - in xpath terms, if a t has
> preceding-sibling::section node, then report an error at that point.

> Any thoughts?

I've made this error a couple of times. I'd prefer to see it rejected.

				Ned
>From gwz at cisco.com  Tue Mar  6 15:11:41 2007
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Thu Mar  8 09:14:08 2007
Subject: [xml2rfc] FW: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner <mailto:[email-masked]> allegedly scribbled on Tuesday,
March 06, 2007 6:57 AM:

> On 3/6/07, Glen Zorn (gwz) <[email-masked]> wrote:
>> Hi.  I've received this lovely missive twice in the last 2 days. 
>> I've duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.
> 
> If you still have the formatted versions that were rejected, could
> you send them to me? 

Sure, in the attached msgs.

... 

>> b) make xml2rfc insert the correct boilerplate
> 
> As far as I know there's no way to get it to insert the wrong one,
> which is why I'm interested in seeing copies of your formatted files. 

I'll send the XML, too, if that will help.
> 
> Thanks,
>   Bill
-------------- next part --------------
An embedded message was scrubbed...
From: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: draft-zorn-dime-diameter-cc-app-mib-01.txt
Date: Sat, 3 Mar 2007 22:48:44 -0800
Size: 56063
Url: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/a3354eb1/attachment-0002.eml
-------------- next part --------------
An embedded message was scrubbed...
From: "Glen Zorn \(gwz\)" <[email-masked]>
Subject: draft-zorn-dime-diameter-base-protocol-mib-01.txt
Date: Sat, 3 Mar 2007 21:19:37 -0800
Size: 144620
Url: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070306/a3354eb1/attachment-0003.eml
>From john+xml at jck.com  Thu Mar  8 20:41:18 2007
From: john+xml at jck.com (John C Klensin)
Date: Thu Mar  8 17:41:28 2007
Subject: [xml2rfc] Re: DTD anomaly:
 <section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Wed, 07 Mar 2007 16:18:39 -0800 (PST), Ned Freed
<[email-masked]> wrote...

>> Hi,
> 
>>   I accidentally came across a construct that's valid
>>   according to rfc2629.dtd but seems to have no useful
>> semantics.
>...
>> xml2rfc and Julian's xslt both render the final <t> in a way
>> that makes it indistinguishable (visually) from being the
>> second paragraph of section 1.1.
> 
>> I'm inclined to have xml2rfc reject this - in xpath terms, if
>> a t has preceding-sibling::section node, then report an error
>> at that point.
> 
>> Any thoughts?
> 
> I've made this error a couple of times. I'd prefer to see it
> rejected.

Let me plead for a warning, not rejection.  The construction
actually makes perfect sense -- as Carl points out, 
  <section><t>intro stuff</t><section>...
is useful and common.  This is symmetric with it.   

The problem is in the output formatting, not the construction.
I don't have nearly the energy to try to search one out, but my
recollection is that the RFC Editor under some earlier
administration occasionally dealt with these cases by placing
the subsections at a greater indention than the primary section.
That might actually be a plausible option for HTML output.

   john

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Mar  9 01:15:55 2007
Subject: [xml2rfc] Re: DTD anomaly: <section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

John C Klensin schrieb:
> Let me plead for a warning, not rejection.  The construction
> actually makes perfect sense -- as Carl points out, 
>   <section><t>intro stuff</t><section>...
> is useful and common.  This is symmetric with it.   
> 
> The problem is in the output formatting, not the construction.
> I don't have nearly the energy to try to search one out, but my
> recollection is that the RFC Editor under some earlier
> administration occasionally dealt with these cases by placing
> the subsections at a greater indention than the primary section.
> That might actually be a plausible option for HTML output.

Two thoughts:

(1) Even if it is symmetric, I've never ever seen that kind of section 
formatting in practice (pointers?).

(2) As long as we don't have a good way to format it, let's reject it 
(unless this breaks a large number of documents, which I really doubt). 
This still leaves us the option to re-introduce it at a later point of 
time...

Best regards, Julian
>From julian.reschke at gmx.de  Fri Mar  9 15:45:46 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Mar  9 06:45:52 2007
Subject: [xml2rfc] Re: DTD anomaly:
	<section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke schrieb:
> John C Klensin schrieb:
>> Let me plead for a warning, not rejection.  The construction
>> actually makes perfect sense -- as Carl points out,   
>> <section><t>intro stuff</t><section>...
>> is useful and common.  This is symmetric with it.  
>> The problem is in the output formatting, not the construction.
>> I don't have nearly the energy to try to search one out, but my
>> recollection is that the RFC Editor under some earlier
>> administration occasionally dealt with these cases by placing
>> the subsections at a greater indention than the primary section.
>> That might actually be a plausible option for HTML output.
> 
> Two thoughts:
> 
> (1) Even if it is symmetric, I've never ever seen that kind of section 
> formatting in practice (pointers?).
> 
> (2) As long as we don't have a good way to format it, let's reject it 
> (unless this breaks a large number of documents, which I really doubt). 
> This still leaves us the option to re-introduce it at a later point of 
> time...

But then: I just checked the drafts I have over here for misplaced text 
sections, and found quite a few (one of which even authored by myself).

In general, these things are easy to fix, but for historic stuff (drafts 
that have been submitted and published), that's not really attractive. 
So making this just a warning (when strict mode not enabled) looks 
sufficient to me.

Best regards, Julian
>From fenner at gmail.com  Fri Mar  9 08:02:57 2007
From: fenner at gmail.com (Bill Fenner)
Date: Fri Mar  9 08:03:01 2007
Subject: [xml2rfc] Re: DTD anomaly:
	<section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]> <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 3/9/07, Julian Reschke <[email-masked]> wrote:
> In general, these things are easy to fix, but for historic stuff (drafts
> that have been submitted and published), that's not really attractive.
> So making this just a warning (when strict mode not enabled) looks
> sufficient to me.

That is exactly the plan.  To be precise, we're changing the DTD, so
such documents will no longer be valid, but DTD validation errors are
warnings (newly introduced in 1.33) instead of errors.  If you use
strict mode, DTD validation errors are errors (even today).

  Bill
>From john+xml at jck.com  Fri Mar  9 11:16:13 2007
From: john+xml at jck.com (John C Klensin)
Date: Fri Mar  9 08:16:21 2007
Subject: [xml2rfc] Re: DTD
 anomaly:	<section><section></section><t/></section>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 	<[email-masked]> <[email-masked]>
 <[email-masked]>
Message-ID: <[email-masked]>

--On Friday, 09 March, 2007 15:45 +0100 Julian Reschke
<[email-masked]> wrote:

> Julian Reschke schrieb:
>> John C Klensin schrieb:
>>> Let me plead for a warning, not rejection.  The construction
>>> actually makes perfect sense -- as Carl points out,   
>>> <section><t>intro stuff</t><section>...
>>> is useful and common.  This is symmetric with it.  
>>> The problem is in the output formatting, not the
>>> construction. I don't have nearly the energy to try to
>>> search one out, but my recollection is that the RFC Editor
>>> under some earlier administration occasionally dealt with
>>> these cases by placing the subsections at a greater
>>> indention than the primary section. That might actually be a
>>> plausible option for HTML output.
>> 
>> Two thoughts:
>> 
>> (1) Even if it is symmetric, I've never ever seen that kind
>> of section  formatting in practice (pointers?).

It would certainly break a few of mine.   When I've wanted to
use that construction, I've felt that the right thing to do is
go ahead and use it, ignore the XML2RFC formatting ambiguity,
and then arm-wrestle with the RFC Editor about formatting.   In
fairness, the places where I have wanted to use that
construction in recent years   are places where I really wanted
to use a numbered list with references from elsewhere to a list
entry.  In other words, I have substituted

	1.2.3 Some Section
	This is the story of a starry night.  Some of the stars
	were:
	1.2.3.1 First star
	Description of first star
	1.2.3.2 Second star
	Description of second star
	1.2.3.3 ...
	 ...
	Discussion of the star collection including a specific
	comment about the second one (See Section 1.2.3.2) ...

Where what I really wanted was

	1.2.3 Some Section
	This is the story of a starry night.  Some of the stars
	were:
	(1) First star
	     Description of first star
	(2) Second star
	     Description of second star
	(3) ...
	     ...
	Discussion of the star collection including a specific
	comment about the second one (See Item (2) above) ...

As we strengthen our list handling, this perceived requirement
may go away, noting that the list arrangement does yield the
right indention or can be manipulated to do so.

>> (2) As long as we don't have a good way to format it, let's
>> reject it  (unless this breaks a large number of documents,
>> which I really doubt).  This still leaves us the option to
>> re-introduce it at a later point of  time...
> 
> But then: I just checked the drafts I have over here for
> misplaced text sections, and found quite a few (one of which
> even authored by myself).
> 
> In general, these things are easy to fix, but for historic
> stuff (drafts that have been submitted and published), that's
> not really attractive. So making this just a warning (when
> strict mode not enabled) looks sufficient to me.

Good.  An addition advantage of a warning, at least until we get
enough of the <list> element issues resolved to eliminate what
is, for me at least, the main part of the problem, is that it
could be used by the RFC Editor as a clue that there is either
an error they need to resolve or some material that may need
special handling.

thanks and regards,
    john

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Mar  9 22:51:53 2007
Subject: [xml2rfc] Proposed extension: <iref> inside <figure>
Message-ID: <[email-masked]>

Hi,

I'd like to relax the content model of <figure>, so that it allows 
<iref> child elements.

Right now, the only way to index things in figures is to have a leading 
(or trailing) element, such as with:

   <iref item="OCTET grammar production"/>
   <figure>
     <artwork type="abnf">
       OCTET = ....
     </artwork>
   </figure>

That's not optimal, because the markup looses the information that the 
indexed item indeed is *inside* the figure, and it may lead to page 
numbers in the index to be off if xml2rfc starts a new page for the figure.

Fortunately, xml2rfc already knows how to do this, we just need to relax 
the DTD and the internal model, so that we can do:

   <figure>
     <iref item="OCTET grammar production"/>
     <artwork type="abnf">
       OCTET = ....
     </artwork>
   </figure>

Proposed changes attached below.

Best regards, Julian

---- snip ----

Index: rfc2629.dtd
===================================================================
RCS file: /var/cvsroot/xml2rfc/rfc2629.dtd,v
retrieving revision 1.19
diff -c -r1.19 rfc2629.dtd
*** rfc2629.dtd	28 Oct 2006 21:44:36 -0000	1.19
--- rfc2629.dtd	10 Mar 2007 06:50:37 -0000
***************
*** 242,248 ****
   <!ATTLIST vspace
             blankLines  %NUMBER;           "0">

! <!ELEMENT figure      (preamble?,artwork,postamble?)>
   <!ATTLIST figure
             anchor      ID                 #IMPLIED
             title       %ATEXT;            ""
--- 242,248 ----
   <!ATTLIST vspace
             blankLines  %NUMBER;           "0">

! <!ELEMENT figure      (iref*,preamble?,artwork,postamble?)>
   <!ATTLIST figure
             anchor      ID                 #IMPLIED
             title       %ATEXT;            ""
Index: xml2rfc.tcl
===================================================================
RCS file: /var/cvsroot/xml2rfc/xml2rfc.tcl,v
retrieving revision 1.21
diff -c -r1.21 xml2rfc.tcl
*** xml2rfc.tcl	17 Jan 2007 10:03:48 -0000	1.21
--- xml2rfc.tcl	10 Mar 2007 06:50:45 -0000
***************
*** 16609,16615 ****
             cref          {}                           \
             vspace        {}                           \
             spanx         {}                           \
!           figure        [list preamble          "?"  \
                                 artwork           ""   \
                                 postamble         "?"] \
             preamble      [list [list xref             \
--- 16609,16616 ----
             cref          {}                           \
             vspace        {}                           \
             spanx         {}                           \
!           figure        [list iref              "*"  \
!                               preamble          "?"  \
                                 artwork           ""   \
                                 postamble         "?"] \
             preamble      [list [list xref             \

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Sat Mar 10 05:18:19 2007
Subject: [xml2rfc] Bug in included content caching mechanism
Message-ID: <[email-masked]>

Hi.

In experimenting with the 'include' PI, I discovered that there is a bug in the 
caching mechanism used to avoid reading the contents of included files and uris more 
than once.

If prexml_find_file or prexml_find_uri identifies that the content has been already 
read it returns the text name of the cache entry rather than the content of the
entry due to a missing $ in each of lines 3400 and 3435 (see diffs below).

The bug can be demonstrated easily by including some file or uri twice and examining 
the 'xml' output.  Second and subsequent inclusions will generate something like:
      <?rfc?><?rfc linefile="1:http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>exturis(http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml)<?rfc linefile="358:/tmp/CGI82078.1"?>

xml2rfc.tcl (release 1.32) in proc prexml_find_file - Lines 3396-3401:
OLD:

     if {   [info exists extfiles([set fx $f])]
         || [info exists extfiles([set fx $f.xml])]} {
         set fnum [linefile::new_file $s $fx]
         return [concat $fnum extfiles($fx)]
     }

NEW:

     if {   [info exists extfiles([set fx $f])]
         || [info exists extfiles([set fx $f.xml])]} {
         set fnum [linefile::new_file $s $fx]
         return [concat $fnum $extfiles($fx)]
     }

xml2rfc.tcl (release 1.32) in proc prexml_find_uri - Lines 3431-3436:
OLD:

     if {   [info exists exturis([set ux $u    ])]
         || [info exists exturis([set ux $u.xml])]} {
         set fnum [linefile::new_file $s $ux]
         return [concat $fnum exturis($ux)]
     }

NEW:

     if {   [info exists exturis([set ux $u    ])]
         || [info exists exturis([set ux $u.xml])]} {
         set fnum [linefile::new_file $s $ux]
         return [concat $fnum $exturis($ux)]
     }

Regards,
Elwyn

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Mar 10 07:12:41 2007
Subject: [xml2rfc] Re: Proposed extension: <iref> inside <figure>
References: <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
> I'd like to relax the content model of <figure>, so that it allows
> <iref> child elements.

Okay.  Your DTD and code diffs look good, but please note somewhere
that you only get optional <iref>s _before_ the optional <preamble>,
or in other words only at the begin of a <figure>.

Together with Elwyn's bug fix and the <section> oddity that could be
a good start for a 1.33pre1.  

Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Mar 10 07:36:21 2007
Subject: [xml2rfc] Re: Proposed extension: <iref> inside <figure>
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
> Julian Reschke wrote:
>  
>> I'd like to relax the content model of <figure>, so that it allows
>> <iref> child elements.
> 
> Okay.  Your DTD and code diffs look good, but please note somewhere
> that you only get optional <iref>s _before_ the optional <preamble>,
> or in other words only at the begin of a <figure>.

Yep, that's intended.

> Together with Elwyn's bug fix and the <section> oddity that could be
> a good start for a 1.33pre1.  

I would love to see the paragraphs-in-list feature to be integrated as 
well...

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Sat Mar 10 08:52:53 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sat Mar 10 08:52:59 2007
Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Hi: For IETF 68, a couple of my drafts were rejected since I was using
> xml2rfc v1.31.  This version did not have the "IETF Trust"  
> boilerplate.
> Upon notification of the rejection, I went ahed and downloaded the  
> next
> release, xml2rfc v1.32.
>
> I have not yet seen my resubmitted drafts appear in the IETF archives.
> I hope they do.
>
> However, that aside, it will be good if xml2rfc.tcl tool automatically
> notified the user that a new version is available.  That way,
> people that do not subscribe to the tools-discuss mailing list know
> when to upgrade.
>
> Thanks,
>
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
>From nobody at xyzzy.claranet.de  Sat Mar 10 18:00:42 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sat Mar 10 09:02:01 2007
Subject: [xml2rfc] Re: Proposed modification to xml2rfc.tcl
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi. FYI, an article posted on the tools list, I'm not sure if all
readers here also read the IETF tools list:

Vijay K. Gurbani wrote:
 
> Hi: For IETF 68, a couple of my drafts were rejected since I was using
> xml2rfc v1.31.  This version did not have the "IETF Trust" boilerplate.
> Upon notification of the rejection, I went ahed and downloaded the next
> release, xml2rfc v1.32.
 
> I have not yet seen my resubmitted drafts appear in the IETF archives.
> I hope they do.
 
> However, that aside, it will be good if xml2rfc.tcl tool automatically
> notified the user that a new version is available.  That way,
> people that do not subscribe to the tools-discuss mailing list know
> when to upgrade.
 
> Thanks,
 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs

From: jabley at ca.afilias.info (Joe Abley)
Date: Sat Mar 10 16:51:53 2007
Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to xml2rfc.tcl
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 10-Mar-2007, at 11:52, Marshall Rose wrote:

>> However, that aside, it will be good if xml2rfc.tcl tool  
>> automatically
>> notified the user that a new version is available.  That way,
>> people that do not subscribe to the tools-discuss mailing list know
>> when to upgrade.

If such a feature were to be implemented (I certainly have no  
objection, and even if I did it's not clear that that should stop  
anybody implementing anything :-) it would be extra good if the whole  
process of phoning home didn't distract the tool from the business at  
hand in the event that it was invoked in an environment where phoning  
home was unlikely to work (in a disconnected network, behind an over- 
zealous firewall, on the subway or on a plane with no prospect of  
Internet access, etc).

Joe
>From tli at cisco.com  Sat Mar 10 20:37:44 2007
From: tli at cisco.com (Tony Li)
Date: Sat Mar 10 20:37:52 2007
Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification to
	xml2rfc.tcl
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mar 10, 2007, at 4:51 PM, Joe Abley wrote:

>
> On 10-Mar-2007, at 11:52, Marshall Rose wrote:
>
>>> However, that aside, it will be good if xml2rfc.tcl tool  
>>> automatically
>>> notified the user that a new version is available.  That way,
>>> people that do not subscribe to the tools-discuss mailing list know
>>> when to upgrade.
>
> If such a feature were to be implemented (I certainly have no  
> objection, and even if I did it's not clear that that should stop  
> anybody implementing anything :-) it would be extra good if the  
> whole process of phoning home didn't distract the tool from the  
> business at hand in the event that it was invoked in an environment  
> where phoning home was unlikely to work (in a disconnected network,  
> behind an over-zealous firewall, on the subway or on a plane with  
> no prospect of Internet access, etc).

Towards that end, could such a check be done once, at initialization  
time, and not every time a draft is processed?

Thanks,
Tony
>From gwz at cisco.com  Sat Mar 10 23:42:28 2007
From: gwz at cisco.com (Glen Zorn (gwz))
Date: Sat Mar 10 23:42:46 2007
Subject: [xml2rfc] RE: draft-zorn-dime-diameter-base-protocol-mib-01.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Glen Zorn (gwz) <> allegedly scribbled on Tuesday, March 06, 2007 5:51
AM:

> Hi.  I've received this lovely missive twice in the last 2 days. 
> I've duly processed my XML w/xml2rfc v. 1.32 using ipr=full3978.  Is
> there a magic incantation I can use to a) stop the IETF from changing
> the boilerplate every 6 months, b) make xml2rfc insert the correct
> boilerplate, c) turn xml2rfc into actual production toy or
> (preferably) d) all of the above?     
> 

It turned out that, despite checking 4 times to make sure that I was
clicking on the right version before bothering you folks I was not.
Very sorry.

...

From: fenner at gmail.com (Bill Fenner)
Date: Sun Mar 11 17:07:21 2007
Subject: [xml2rfc] Announcing 1.33pre2
Message-ID: <[email-masked]>

Greetings,

 xml2rfc 1.33pre2 has been released.  The change list isn't extensive,
but since there's been some active discussion we wanted to get this
out for people to test.

Warn of invalid XML (unless "strict" is in use, in which case invalid XML
  is an error)
<?rfc rfcedstyle="yes"?> now implies compact=yes and subcompact=no,
but  both are overridable inside the document.
The title of a figure with &gt; or other entities in the xml version (as
  required) is now dequoted for the text version.
DTD Changes:
 - Removes default of "info" for category attribute
 - Change section and appendix to disallow content after subsections

 More details at http://xml.resource.org/experimental.html

 The patches and ideas sent during the weekend aren't in this release,
but that won't prevent them from being in 1.33.

 Bill
>From john+xml at jck.com  Sun Mar 11 21:51:23 2007
From: john+xml at jck.com (John C Klensin)
Date: Sun Mar 11 17:51:33 2007
Subject: [xml2rfc] Fwd: [Tools-discuss] Proposed modification
 to xml2rfc.tcl
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Sat, 10 Mar 2007 19:51:34 -0500, Joe Abley
<[email-masked]> wrote...

> On 10-Mar-2007, at 11:52, Marshall Rose wrote:
> 
>>> However, that aside, it will be good if xml2rfc.tcl tool  
>>> automatically
>>> notified the user that a new version is available.  That way,
>>> people that do not subscribe to the tools-discuss mailing
>>> list know when to upgrade.
> 
> If such a feature were to be implemented (I certainly have no  
> objection, and even if I did it's not clear that that should
> stop   anybody implementing anything :-) it would be extra
> good if the whole   process of phoning home didn't distract
> the tool from the business at   hand in the event that it was
> invoked in an environment where phoning   home was unlikely to
> work (in a disconnected network, behind an over-  zealous
> firewall, on the subway or on a plane with no prospect of  
> Internet access, etc)

Let me try to say that a little more strongly.  At least in my
particular situation, the strongest reason for using the TCL
version, which I have put up from time to time, rather than the
online one occurs precisely in environments with no Internet
connectively (such as airplanes after the Boeing stuff shut
down).  So, while a "check for updates" function -- manual or
automatic -- would be helpful, if the system cannot establish a
connection fairly quickly I would hope it would just move on
with a minimum of fuss.

    john

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 12 03:11:07 2007
Subject: [xml2rfc] Announcing 1.33pre2
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

>> - Change section and appendix to disallow content after subsections

I have updated <http://greenbytes.de/tech/webdav/rfc2629xslt.zip> so 
that it warns about misplaced <t> elements as well.

Best regards, Julian
>From hagens at ISI.EDU  Mon Mar 19 16:12:04 2007
From: hagens at ISI.EDU (Alice Hagens)
Date: Mon Mar 19 07:13:18 2007
Subject: [xml2rfc] XML templates
Message-ID: <[email-masked]>

The RFC Editor has posted an updated version of Elwyn's template for  
creating a draft using xml2rfc (and a link to his xml2rfc tutorial  
slides from IETF 65) on www.rfc-editor.org/formatting.html.  Please  
let Elwyn or me know of any corrections or suggestions for the template.

We have also posted David Harrington's XML template for creating  
drafts that contain MIBs (draft-harrington-text-mib-doc-template).

If you know of other templates that might be of use to xml2rfc users,  
please let us know.

Thank you.

Alice Hagens
for the RFC Editor
>From mrose at dbc.mtview.ca.us  Mon Mar 19 08:55:55 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 19 07:56:03 2007
Subject: [xml2rfc] XML templates
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> The RFC Editor has posted an updated version of Elwyn's template  
> for creating a draft using xml2rfc (and a link to his xml2rfc  
> tutorial slides from IETF 65) on www.rfc-editor.org/ 
> formatting.html.  Please let Elwyn or me know of any corrections or  
> suggestions for the template.
>
> We have also posted David Harrington's XML template for creating  
> drafts that contain MIBs (draft-harrington-text-mib-doc-template).
>
> If you know of other templates that might be of use to xml2rfc  
> users, please let us know.

hi. thanks. we'll put a link to this page from the xml2rfc page. one  
thing though: the link for

	unofficial successor

is

	http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html%22

i'm not sure what the %22 is doing there at the end...

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 19 08:18:47 2007
Subject: [xml2rfc] html formatting
Message-ID: <[email-masked]>

on the ietf's tool-discuss list, it has been suggested that when html  
is produced, then pointers to rfcs should point to the html version  
and not the text version.

this seems like a reasonable enhancement.

does anyone have any strong opinions one way or another on this?

/mtr
  
>From emile.stephan at orange-ftgroup.com  Mon Mar 19 17:27:11 2007
From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN)
Date: Mon Mar 19 08:27:53 2007
Subject: [xml2rfc] 
	draft-stephan-ops-xml-mib-module-template:  xml mib module
	translation example 
Message-ID: <[email-masked]>

Hi,

I enhanced the XSL of
http://tools.ietf.org/html/draft-stephan-ops-xml-mib-module-template-00
and applied it on the PCE draft-ietf-pce-disc-mib-02-v03.xml to extract
the XML schemas for this MIB.

Regards
Emile
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xsd4MIB.zip
Type: application/x-zip-compressed
Size: 23426 bytes
Desc: xsd4MIB.zip
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070319/739d9664/xsd4MIB-0001.bin
>From julian.reschke at gmx.de  Mon Mar 19 18:25:11 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 09:25:19 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
> on the ietf's tool-discuss list, it has been suggested that when html is 
> produced, then pointers to rfcs should point to the html version and not 
> the text version.
> 
> this seems like a reasonable enhancement.
> 
> does anyone have any strong opinions one way or another on this?

Strong +1. Have been doing this in rfc2629.xslt for several months now 
(when I notices that Wikipedia does so as well).

Best regards, Julian
>From paul.hoffman at vpnc.org  Mon Mar 19 19:27:42 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Mar 19 10:27:54 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p06240806c22484652ad9@[130.129.16.219]>

At 9:18 AM -0700 3/19/07, Marshall Rose wrote:
>on the ietf's tool-discuss list, it has been suggested that when 
>html is produced, then pointers to rfcs should point to the html 
>version and not the text version.
>
>this seems like a reasonable enhancement.
>
>does anyone have any strong opinions one way or another on this?

It doesn't feel good to me given that the text version is the 
canonical one. Would people object to a dual pointer by default, such 
as:
...such as RFC 5678 (<a href='rfc5678.txt'>text</a>, <a 
href='rfc5678.html'>html</a>).

--Paul Hoffman, Director
--VPN Consortium
>From tony at att.com  Mon Mar 19 14:32:27 2007
From: tony at att.com (Tony Hansen)
Date: Mon Mar 19 10:32:15 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <p06240806c22484652ad9@[130.129.16.219]>
References: <[email-masked]>
	<p06240806c22484652ad9@[130.129.16.219]>
Message-ID: <[email-masked]>

+1

Paul Hoffman wrote:
> At 9:18 AM -0700 3/19/07, Marshall Rose wrote:
>> on the ietf's tool-discuss list, it has been suggested that when html
>> is produced, then pointers to rfcs should point to the html version
>> and not the text version.
>>
>> this seems like a reasonable enhancement.
>>
>> does anyone have any strong opinions one way or another on this?
> 
> It doesn't feel good to me given that the text version is the canonical
> one. Would people object to a dual pointer by default, such as:
> ...such as RFC 5678 (<a href='rfc5678.txt'>text</a>, <a
> href='rfc5678.html'>html</a>).

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 10:34:57 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <p06240806c22484652ad9@[130.129.16.219]>
References: <[email-masked]> <p06240806c22484652ad9@[130.129.16.219]>
Message-ID: <[email-masked]>

Paul Hoffman schrieb:
> At 9:18 AM -0700 3/19/07, Marshall Rose wrote:
>> on the ietf's tool-discuss list, it has been suggested that when html 
>> is produced, then pointers to rfcs should point to the html version 
>> and not the text version.
>>
>> this seems like a reasonable enhancement.
>>
>> does anyone have any strong opinions one way or another on this?
> 
> It doesn't feel good to me given that the text version is the canonical 
> one. Would people object to a dual pointer by default, such as:
> ...such as RFC 5678 (<a href='rfc5678.txt'>text</a>, <a 
> href='rfc5678.html'>html</a>).

I used to see it that way as well. But Wikipedia nowadays links to the 
HTML version -- I think that should tell us something :-)
>From lars.eggert at nokia.com  Mon Mar 19 19:46:01 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Mon Mar 19 10:46:17 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <p06240806c22484652ad9@[130.129.16.219]>
References: <[email-masked]>
	<p06240806c22484652ad9@[130.129.16.219]>
Message-ID: <[email-masked]>

On 2007-3-19, at 19:27, ext Paul Hoffman wrote:
> It doesn't feel good to me given that the text version is the  
> canonical one. Would people object to a dual pointer by default,  
> such as:
> ...such as RFC 5678 (<a href='rfc5678.txt'>text</a>, <a  
> href='rfc5678.html'>html</a>).

The dual link is IMO ugly, and the HTML version does link to the  
canonical text version, but is more convenient to use.

+1 for linking to the HTML

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070319/d596ff5e/smime.bin
>From carl at media.org  Mon Mar 19 11:00:47 2007
From: carl at media.org (Carl Malamud)
Date: Mon Mar 19 11:00:53 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Not all documents exist in html.  The txt is the cannonical
document, for better or for worse.  And, even if you want
html, you must check to see if it exists first.

+1 for linking to both if they exist.  I've used the dual (or
triple link) for years as a manual process using the format
tags, which yields a very nice (txt, html, pdf) set of links
at the end of the reference.

> On 2007-3-19, at 19:27, ext Paul Hoffman wrote:
> > It doesn't feel good to me given that the text version is the  
> > canonical one. Would people object to a dual pointer by default,  
> > such as:
> > ...such as RFC 5678 (<a href='rfc5678.txt'>text</a>, <a  
> > href='rfc5678.html'>html</a>).
> 
> The dual link is IMO ugly, and the HTML version does link to the  
> canonical text version, but is more convenient to use.
> 
> +1 for linking to the HTML
> 
> Lars
> 
> 

> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From mrose at dbc.mtview.ca.us  Mon Mar 19 13:07:51 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 19 12:08:02 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<p06240806c22484652ad9@[130.129.16.219]>
	<[email-masked]>
Message-ID: <[email-masked]>

> The dual link is IMO ugly, and the HTML version does link to the  
> canonical text version, but is more convenient to use.
>
> +1 for linking to the HTML

i think that the rfc editor might take issue with respect to whether  
or not an HTML version of an rfc is "canonical".

however, there is a <format/> element which allows a reference to  
indicate different formats for the same document.

this introduces some possibilities for a <reference/> element with a  
<seriesInfo name='RFC'/> but no <format/> elements:

option #1: act as if there is an implicit element for the HTML  
format. this will introduce an (HTML) at the tail end of the  
reference. the name of the document remains a hyperlink to the text  
version.

option #2: act as if there is an implicit element for the TXT format  
and make the hyperlink for the document's name point to the HTML  
version.

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 12:08:52 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Carl Malamud schrieb:
> Not all documents exist in html.  The txt is the cannonical
> document, for better or for worse.  And, even if you want
> html, you must check to see if it exists first.

Carl, we're talking about the html-ized versions of the original RFCs, 
as provided at <http://tools.ietf.org/html/rfcnnnn>. Those do always 
exist...

> +1 for linking to both if they exist.  I've used the dual (or
> triple link) for years as a manual process using the format
> tags, which yields a very nice (txt, html, pdf) set of links
> at the end of the reference.

Linking to both may be an option for the References section, but not for 
the quotation itself...

Best regards, Julian
>From julian.reschke at gmx.de  Mon Mar 19 21:55:22 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 12:55:33 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<p06240806c22484652ad9@[130.129.16.219]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
>> The dual link is IMO ugly, and the HTML version does link to the 
>> canonical text version, but is more convenient to use.
>>
>> +1 for linking to the HTML
> 
> i think that the rfc editor might take issue with respect to whether or 
> not an HTML version of an rfc is "canonical".

Well, how exactly does that concern the RFC Editor? Documents are 
published as plain text, and that one doesn't have any links anyway...

> however, there is a <format/> element which allows a reference to 
> indicate different formats for the same document.
> 
> this introduces some possibilities for a <reference/> element with a 
> <seriesInfo name='RFC'/> but no <format/> elements:
> 
> option #1: act as if there is an implicit element for the HTML format. 
> this will introduce an (HTML) at the tail end of the reference. the name 
> of the document remains a hyperlink to the text version.
> 
> option #2: act as if there is an implicit element for the TXT format and 
> make the hyperlink for the document's name point to the HTML version.

I personally see no use at all in having a visible link to the ASCII 
version. The HTML version on tools.ietf.org has a link to the TXT 
source, and that's IMHO sufficient.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Mar 19 14:08:46 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 19 13:08:56 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<p06240806c22484652ad9@[130.129.16.219]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

>>> The dual link is IMO ugly, and the HTML version does link to the  
>>> canonical text version, but is more convenient to use.
>>>
>>> +1 for linking to the HTML
>> i think that the rfc editor might take issue with respect to  
>> whether or not an HTML version of an rfc is "canonical".
>
> Well, how exactly does that concern the RFC Editor? Documents are  
> published as plain text, and that one doesn't have any links anyway...

sorry. i misread the previous posting.

> I personally see no use at all in having a visible link to the  
> ASCII version. The HTML version on tools.ietf.org has a link to the  
> TXT source, and that's IMHO sufficient.

now i am just plain confused.

there is a repository of html-ized rfcs on tools.ietf.org, which does  
what everyone wants. so the desired behavior is to this markup, which  
occurs outside of the <references/> elements,

	RFC nnnn <a href="#RFCnnnn">[xx]</a>

to change to this:

	RFC nnnn <a href="http://tools.ietf.org/html/rfcnnnn">[xx]</a>

or perhaps this:

	RFC nnnn <a href="http://tools.ietf.org/html/rfcnnnn">[<a  
href="#RFCnnnn">xx</a>]</a>

am i on message now?

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 13:16:41 2007
Subject: [xml2rfc] html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <p06240806c22484652ad9@[130.129.16.219]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
> ...
>> I personally see no use at all in having a visible link to the ASCII 
>> version. The HTML version on tools.ietf.org has a link to the TXT 
>> source, and that's IMHO sufficient.
> 
> now i am just plain confused.
> 
> there is a repository of html-ized rfcs on tools.ietf.org, which does 
> what everyone wants. so the desired behavior is to this markup, which 
> occurs outside of the <references/> elements,
> 
>     RFC nnnn <a href="#RFCnnnn">[xx]</a>
> 
> to change to this:
> 
>     RFC nnnn <a href="http://tools.ietf.org/html/rfcnnnn">[xx]</a>
> 
> or perhaps this:
> 
>     RFC nnnn <a href="http://tools.ietf.org/html/rfcnnnn">[<a 
> href="#RFCnnnn">xx</a>]</a>
> 
> am i on message now?

I personally think that the internal links *to* the references section 
should stay as they are, but the *entry* in the reference section should 
link to the HTML version. Others probably disagree. At least this is 
what I'm doing in rfc2629.xslt.

*In addition*, it would be nice if the xml2rfc language would allow to 
express the section number in addition to the reference, such as 
proposed in 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>. 
In that case, the section number itself (or the string "Section x.y") 
could be made a *direct* hyperlink into the HTML version (which has 
named anchors for sections). But that's a new feature.

Best regards, Julian

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Mar 19 14:36:31 2007
Subject: [xml2rfc] Re: html formatting
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> I used to see it that way as well. But Wikipedia nowadays links
> to the HTML version -- I think that should tell us something :-)

It tells you that "somebody" convinced two admins to adjust their
http://en.wikipedia.org/wiki/MediaWiki:Rfcurl (ditto on meta) -
after making sure that the IETF tools server offers a link to the
ASCII plain text version from the rfcmarkup HTML version.

Another nice feature of the rfcmarkup HTML is that it offers
anchors for all pages and numbered sections using exactly the
same page and section numbers as the "real" ASCII version.  I
often need URLs like

http://tools.ietf.org/html/draft-klensin-rfc2821bis-01#section-2.3.5

My simple browser insists on "draft-" and "-01", but I think
modern browsers should also find the section without this.

Frank

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Mar 19 14:54:01 2007
Subject: [xml2rfc] Re: html formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
> ...
> Another nice feature of the rfcmarkup HTML is that it offers
> anchors for all pages and numbered sections using exactly the
> same page and section numbers as the "real" ASCII version.  I
> often need URLs like
> 
> http://tools.ietf.org/html/draft-klensin-rfc2821bis-01#section-2.3.5
> ...

Indeed. That's why I added the capability to link to a specific section 
to rfc2629.xslt.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Tue Mar 20 00:04:24 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Mar 19 15:05:28 2007
Subject: [xml2rfc] Re: html formatting
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> Indeed. That's why I added the capability to link to a specific
> section to rfc2629.xslt.

Good.  The page numbers are only interesting for overlong sections,
or for unnumbered sections (e.g. appendices) not yet recognized by
rfcmarkup.  Authors should add their own anchors in the XML source
if their sections are excessively long (for direct XML to HTML).

Frank

From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 01:36:41 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
Message-ID: <[email-masked]>

Something I periodically trip over is forgetting to change the name of
the draft I'm writing from e.g. "-01" to "-02".

It would be nice if xml2rfc could optionally check

	<rfc ... docName="draft-ietf-xyz-01.txt">

against the name of the file being processed, and warn if they don't
match up through the "-02" portion of the name.

	Tony Hansen
	[email-masked]

PS. I use the online xml2rfc submission form.
>From tony at att.com  Tue Mar 20 04:48:03 2007
From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 01:38:04 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
Message-ID: <[email-masked]>

Something I periodically trip over is forgetting to change the name of
the draft I'm writing from e.g. "-01" to "-02".

It would be nice if xml2rfc could optionally check

	<rfc ... docName="draft-ietf-xyz-01.txt">

against the name of the file being processed, and warn if they don't
match up through the "-02" portion of the name.

	Tony Hansen
	[email-masked]

PS. I use the online xml2rfc submission form.
>From tony at att.com  Tue Mar 20 04:48:03 2007
From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 01:41:28 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
Message-ID: <[email-masked]>

Something I periodically trip over is forgetting to change the name of
the draft I'm writing from e.g. "-01" to "-02".

It would be nice if xml2rfc could optionally check

	<rfc ... docName="draft-ietf-xyz-01.txt">

against the name of the file being processed, and warn if they don't
match up through the "-02" portion of the name.

	Tony Hansen
	[email-masked]

PS. I use the online xml2rfc submission form.
>From julian.reschke at gmx.de  Tue Mar 20 10:47:17 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 20 01:47:37 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tony Hansen schrieb:
> Something I periodically trip over is forgetting to change the name of
> the draft I'm writing from e.g. "-01" to "-02".
> 
> It would be nice if xml2rfc could optionally check
> 
> 	<rfc ... docName="draft-ietf-xyz-01.txt">
> 
> against the name of the file being processed, and warn if they don't
> match up through the "-02" portion of the name.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> PS. I use the online xml2rfc submission form.

Nit: the docName shouldn't include the extension, right?

Best regards, Julian

From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 01:57:11 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
Message-ID: <[email-masked]>

Something I periodically trip over is forgetting to change the name of
the draft I'm writing from e.g. "-01" to "-02".

It would be nice if xml2rfc could optionally check

	<rfc ... docName="draft-ietf-xyz-01.txt">

against the name of the file being processed, and warn if they don't
match up through the "-02" portion of the name.

	Tony Hansen
	[email-masked]

PS. I use the online xml2rfc submission form.
>From elwynd at googlemail.com  Tue Mar 20 12:51:23 2007
From: elwynd at googlemail.com (Elwyn Davies)
Date: Tue Mar 20 04:50:25 2007
Subject: [xml2rfc] 
	Making a single include work with either local file or web
Message-ID: <[email-masked]>

Hi.

In working with Alice on the template, I came to the coclusion that it 
would be very convenient if I could just put some trailing part of the 
file name in an include PI and have the same xml source work in two 
different environments:
- with local files
- with files retrieved from the web.

One solution appears to be allowing the XML_LIBRARY environment variable 
to contain both local paths and the head of an http URI.
There are AFAICS a couple of issues with this:
- overloading of : in the Unix environment (directory separator and URI 
meta character).  Seems that this could be easily worked round by 
treating http:// as a 'metacharacter' different from a 'naked' :.
- ensuring that processors don't hang up for excessive amounts of time 
trying to access a nonexistent URI got by combining the wrong (remote) 
head and tail.

If this could be achieved it would avoid having to adapt files 
before/after sending them to co-authors or the RFC Editor where a 
different environment may be in use which would be convenient.

Regards,
Elwyn
>From dwing at cisco.com  Tue Mar 20 14:42:59 2007
From: dwing at cisco.com (Dan Wing)
Date: Tue Mar 20 05:43:08 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

It already complains if you leave off the ".txt".

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Hansen
> Sent: Tuesday, March 20, 2007 9:48 AM
> To: xml2rfc mailing list
> Subject: [xml2rfc] minor nitlet I'd like flagged
> 
> Something I periodically trip over is forgetting to change the name of
> the draft I'm writing from e.g. "-01" to "-02".
> 
> It would be nice if xml2rfc could optionally check
> 
> 	<rfc ... docName="draft-ietf-xyz-01.txt">
> 
> against the name of the file being processed, and warn if they don't
> match up through the "-02" portion of the name.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> PS. I use the online xml2rfc submission form.
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From tony at att.com  Tue Mar 20 10:11:31 2007
From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 06:11:29 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Honest officer, I really didn't send this message 4 times!

Seriously, I don't know why so many copies of my message have shown up
on the list. Sorry.

	Tony

Tony Hansen wrote:
> Something I periodically trip over is forgetting to change the name of
> the draft I'm writing from e.g. "-01" to "-02".
> 
> It would be nice if xml2rfc could optionally check
> 
> 	<rfc ... docName="draft-ietf-xyz-01.txt">
> 
> against the name of the file being processed, and warn if they don't
> match up through the "-02" portion of the name.
> 
> 	Tony Hansen
> 	[email-masked]
> 
> PS. I use the online xml2rfc submission form.
>From tony at att.com  Tue Mar 20 10:54:29 2007
From: tony at att.com (Tony Hansen)
Date: Tue Mar 20 06:54:21 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
>
> Nit: the docName shouldn't include the extension, right?

Well, apparently the string is actually opaque as far as xml2rfc is
concerned. It appears that whatever you put in there will be spit out
immediately after the title.

Of the 1908 current internet-drafts, 1193 use .txt and 715 do not.

But this is side stepping my nitlet:

>> Something I periodically trip over is forgetting to change the name of
>> the draft I'm writing from e.g. "-01" to "-02".
>>
>> It would be nice if xml2rfc could optionally check
>>
>>     <rfc ... docName="draft-ietf-xyz-01.txt">
>>
>> against the name of the file being processed, and warn if they don't
>> match up through the "-02" portion of the name.

	Tony Hansen
	[email-masked]
>From mrose at dbc.mtview.ca.us  Tue Mar 20 12:37:55 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Mar 20 11:38:00 2007
Subject: [xml2rfc]  Making a single include work with either local file or
	web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> One solution appears to be allowing the XML_LIBRARY environment  
> variable to contain both local paths and the head of an http URI.
> There are AFAICS a couple of issues with this:
> - overloading of : in the Unix environment (directory separator and  
> URI meta character).  Seems that this could be easily worked round  
> by treating http:// as a 'metacharacter' different from a 'naked' :.
> - ensuring that processors don't hang up for excessive amounts of  
> time trying to access a nonexistent URI got by combining the wrong  
> (remote) head and tail.

give me an example of what your search path might look like. don't  
bother with the separators, e.g., are you thinking:

	.
	~/lib/rfcs
	http://xml.resource.org/public/rfc/bibxml

also, give me an example what what your references look like now.

thanks!

/mtr

From: elwynd at googlemail.com (Elwyn Davies)
Date: Tue Mar 20 16:46:25 2007
Subject: [xml2rfc]  Making a single include work with either local file or web
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> One solution appears to be allowing the XML_LIBRARY environment 
>> variable to contain both local paths and the head of an http URI.
>> There are AFAICS a couple of issues with this:
>> - overloading of : in the Unix environment (directory separator and 
>> URI meta character).  Seems that this could be easily worked round by 
>> treating http:// as a 'metacharacter' different from a 'naked' :.
>> - ensuring that processors don't hang up for excessive amounts of 
>> time trying to access a nonexistent URI got by combining the wrong 
>> (remote) head and tail.
>
> give me an example of what your search path might look like. don't 
> bother with the separators, e.g., are you thinking:
>
>     .
>     ~/lib/rfcs
>     http://xml.resource.org/public/rfc/bibxml
>
> also, give me an example what what your references look like now.
>
> thanks!
>
> /mtr

Hi, Marshall.

There are a number of scenarios which seem sensible:
1, Image of  remote dirs on local disk + current dir:
  include="reference.RFC.1122.xml"
  include="reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 ~/lib/bibxml
 ~/lib/bibxml3

2. Alternative arrangement of downloaded files
  include="reference.RFC.1122.xml"
  include="reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 ~/lib/rfc
 ~/lib/i-d

3. Single local dir for downloaded files
  include="rfc/reference.RFC.1122.xml"
  include="i-d/reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 ~/lib/bibxml_root   /* with subdirs rfc and i-d for RFCs and I-Ds */

4. Remote access to I-Ds plus local copy of RFCs and extra xml locally.
  include="reference.RFC.1122.xml"
  include="reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 ~/lib/bibxml
 http://xml.resource.org/public/rfc/bibxml3

4. Single remote root for references and extra xml locally
  include="bibxml/reference.RFC.1122.xml"
  include="bibxml3/reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 http://xml.resource.org/public/rfc

5. Get I-Ds preferentially from remote
  include="reference.RFC.1122.xml"
  include="reference.I-D.savola-v6ops-transarch.xml"
  include="extra_piece.xml"
XML_LIBRARY:
 .
 http://xml.resource.org/public/rfc/bibxml3
 ~/lib/bibxml
 ~/lib/bibxml3

Regards,
Elwyn

>
>

From: emile.stephan at orange-ftgroup.com (STEPHAN Emile RD-CORE-LAN)
Date: Wed Mar 21 07:24:40 2007
Subject: [xml2rfc] volonteers to work on 100% vanilla  XML MIB template 
Message-ID: <[email-masked]>

Hi,

During the meeting I have comments regarding the loosely way my XML
template are defined.

It is clear that XML templates proposed in
draft-stephan-ops-xml-mib-module-templates are not elegant. I did it in
that way to minimize the change in RFC2629, xml2rfc and xml2rfc-xxe. I
did it in that way too, to illustrate that there is absolutely nothing
to address the lack of datamodel for Netconf. 

Please contact me if you are interested
	To handcraft a XSD of the well knwn TC,
	To work on an sort of update of RFC2629 with ground truth XML
SMI template;

Regards
Emile

From: dbharrington at comcast.net (David B Harrington)
Date: Wed Mar 21 18:33:54 2007
Subject: [xml2rfc] XML templates
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Alice,

I looked a bit closer at the template you posted.
The template posted is my XML template
(draft-harrington-xml-mib-doc-template), which is 
different than my text template (available in
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-harrington-tex
t-mib-doc-template-02.txt).

The XML file requires rfc2629.dtd to be in the same directory (as does
Elwyn's).

dbh
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alice Hagens
> Sent: Monday, March 19, 2007 4:12 PM
> To: [email-masked]
> Cc: RFC Editor
> Subject: [xml2rfc] XML templates
> 
> The RFC Editor has posted an updated version of Elwyn's template for

> creating a draft using xml2rfc (and a link to his xml2rfc tutorial  
> slides from IETF 65) on www.rfc-editor.org/formatting.html.  Please

> let Elwyn or me know of any corrections or suggestions for 
> the template.
> 
> We have also posted David Harrington's XML template for creating  
> drafts that contain MIBs (draft-harrington-text-mib-doc-template).
> 
> If you know of other templates that might be of use to 
> xml2rfc users,  
> please let us know.
> 
> Thank you.
> 
> Alice Hagens
> for the RFC Editor
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar 22 16:58:09 2007
Subject: [xml2rfc]  Making a single include work with either local file or web
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

elwyn - thanks.

all - does anyone know of a syntax for a search path for both local  
directories and urls?

i am concerned about using ':' for two different purposes (at last on  
non-windows boxes).

/mtr

From: jabley at ca.afilias.info (Joe Abley)
Date: Fri Mar 23 07:50:55 2007
Subject: [xml2rfc]  Making a single include work with either local file or web
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 23-Mar-2007, at 01:57, Marshall Rose wrote:

> elwyn - thanks.
>
> all - does anyone know of a syntax for a search path for both local  
> directories and urls?
>
> i am concerned about using ':' for two different purposes (at last  
> on non-windows boxes).

On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might  
be interpreted as either "D:\RFC", or the directory "D" in the  
current working directory and the directory "\RFC".

Joe

From: elwynd at googlemail.com (Elwyn Davies)
Date: Fri Mar 23 14:07:23 2007
Subject: [xml2rfc]  Making a single include work with either local file or web
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Joe Abley wrote:
>
> On 23-Mar-2007, at 01:57, Marshall Rose wrote:
>
>> elwyn - thanks.
>>
>> all - does anyone know of a syntax for a search path for both local 
>> directories and urls?
>>
>> i am concerned about using ':' for two different purposes (at last on 
>> non-windows boxes).
>
> On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might 
> be interpreted as either "D:\RFC", or the directory "D" in the current 
> working directory and the directory "\RFC".
On windows boxes ; is used to separate directories gfor exactly yhis reason.

If we restrict ourselves to using 'absolute' URLs, the URL is expected 
to start http:// which can be distinguished unambiguously from C:\ (or 
C:/) on Windows and <dir>:<dir> .  Yes, it overloads the : but the 
context seems pretty conclusive to me.

/Elwyn
>
>
> Joe
>
>

From: carl at media.org (Carl Malamud)
Date: Sat Mar 24 02:44:42 2007
Subject: [xml2rfc]  Making a single include work with either local file or web
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hmmm ... C:\FOO isn't a URL, but if you prefix it with file:
you could easily distinguish it from a url that starts with
http: and could thus mix both forms of URLs in a single list
to construct a search path.

Carl

> Joe Abley wrote:
> >
> > On 23-Mar-2007, at 01:57, Marshall Rose wrote:
> >
> >> elwyn - thanks.
> >>
> >> all - does anyone know of a syntax for a search path for both local 
> >> directories and urls?
> >>
> >> i am concerned about using ':' for two different purposes (at last on 
> >> non-windows boxes).
> >
> > On Windows boxes, too, I think. The end of "C:\FOO:\BAR:D:\RFC" might 
> > be interpreted as either "D:\RFC", or the directory "D" in the current 
> > working directory and the directory "\RFC".
> On windows boxes ; is used to separate directories gfor exactly yhis reason.
> 
> If we restrict ourselves to using 'absolute' URLs, the URL is expected 
> to start http:// which can be distinguished unambiguously from C:\ (or 
> C:/) on Windows and <dir>:<dir> .  Yes, it overloads the : but the 
> context seems pretty conclusive to me.
> 
> /Elwyn
> >
> >
> > Joe
> >
> >
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From julian.reschke at gmx.de  Sat Mar 24 13:31:05 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Mar 24 04:31:12 2007
Subject: [xml2rfc]  Making a single include work with either local file
 or	web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hm,

is this whole discussion about the include PI?

In which case, I strongly suggest to deprecate it (it's incompatible 
with the DTD). If we really need a second mechanism for including 
references, let's *please* define something better (*).

Best regards, Julian

(*) Not breaking XML validity, allowing authors to set the anchor id 
themselves...
>From elwynd at googlemail.com  Sat Mar 24 13:42:17 2007
From: elwynd at googlemail.com (Elwyn Davies)
Date: Sat Mar 24 05:41:19 2007
Subject: [xml2rfc]  Making a single include work with either local file
 or	web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> Hm,
>
> is this whole discussion about the include PI?
Not necessarily:
I am trying to get to the position where a given xml2rfc source can 
retrieve references either from a remote source or a local source 
without modifing the core xml2rfc source.  For the include PI at least 
this involves altering the semantics of the XML_LIBRARY environment 
variable.  I am unclear whether the entity references can do something 
similar.

>
> In which case, I strongly suggest to deprecate it (it's incompatible 
> with the DTD). If we really need a second mechanism for including 
> references, let's *please* define something better (*).
I would be happy if we needed to define something extra and better that 
would allow entities to be populated alternatively from the web or from 
a local file or some other way to include source (be it references or 
pieces of the body) from subsidiary files or urls.  What I *don't* want 
is a second mechanism so that I have to choose in advance whether my 
entity is populated remotely or locally, or alternatively edit the source.

/Elwyn
>
>
> Best regards, Julian
>
> (*) Not breaking XML validity, allowing authors to set the anchor id 
> themselves...
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From julian.reschke at gmx.de  Sat Mar 24 14:55:08 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Mar 24 05:55:18 2007
Subject: [xml2rfc]  Making a single include work with either local file
 or	web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies schrieb:
> 
> 
> Julian Reschke wrote:
>> Hm,
>>
>> is this whole discussion about the include PI?
> Not necessarily:
> I am trying to get to the position where a given xml2rfc source can 
> retrieve references either from a remote source or a local source 
> without modifing the core xml2rfc source.  For the include PI at least 
> this involves altering the semantics of the XML_LIBRARY environment 
> variable.  I am unclear whether the entity references can do something 
> similar.

It depends on the xml2rfc processor; for xml2rfc itself I think it can 
be set as well.

>> In which case, I strongly suggest to deprecate it (it's incompatible 
>> with the DTD). If we really need a second mechanism for including 
>> references, let's *please* define something better (*).
> I would be happy if we needed to define something extra and better that 
> would allow entities to be populated alternatively from the web or from 
> a local file or some other way to include source (be it references or 
> pieces of the body) from subsidiary files or urls.  What I *don't* want 
> is a second mechanism so that I have to choose in advance whether my 
> entity is populated remotely or locally, or alternatively edit the source.

Well, are we looking for a *generic* inclusion mechanism, or just for 
references?

For generic inclusions, the source file won't be DTD-valid anymore (in 
general), thus DTD validation must occur after inclusion. If that's what 
we want, I'd suggest to pick something that's already out there, such as 
XInclude (<http://www.w3.org/TR/xinclude/>), for wich xsltproc IMHO has 
builtin support.

I know I'm repeating myself, but I personally think that using 
inclusions for references may be ok during authoring, it's a dreadful 
idea for archiving. So the RFC Editor really should get rid of all 
reference inclusions during the publication phase.

Best regards, Julian
>From jabley at ca.afilias.info  Sat Mar 24 19:50:35 2007
From: jabley at ca.afilias.info (Joe Abley)
Date: Sat Mar 24 10:50:49 2007
Subject: [xml2rfc]  Making a single include work with either local file or
	web
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 23-Mar-2007, at 23:08, Elwyn Davies wrote:

> If we restrict ourselves to using 'absolute' URLs, the URL is  
> expected to start http:// which can be distinguished unambiguously  
> from C:\ (or C:/) on Windows and <dir>:<dir> .

Personally, I like the idea of being able to use relative paths when  
referring to files. This is useful in Makefiles which are used to  
render C source as executables; I don't see why it would be less  
useful rendering RFC2629 source as text.

This is certainly not what I would call a "must have", however.

Joe

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Mar 26 08:17:09 2007
Subject: [xml2rfc] Re: Problems with xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm seeing xml.resource.org timing out today, and it seems consistent
> on one of the two returned IPv4 addresses I see for it  
> (192.20.225.40).

the server broke and is being rebuilt. we'll remove the A RR for that  
ip address until it's fixed.

/mtr

From: tony at att.com (Tony Hansen)
Date: Mon Mar 26 13:45:47 2007
Subject: [xml2rfc] xml2rfc.cgi, processing directives and <cref>
Message-ID: <[email-masked]>

I was having a conversation the other day with someone about using
<cref> and we came up with an idea I'd like to explore. The issue is
that if you'd like to sometimes have <cref>s be visible, and other times
not, you need to edit the source file to change the processing
directive. He recalled one time he accidentally submitted an I-D with
the <cref>s included.

So our idea is to be able to override processing directives via command
line arguments to xml2rfc.cgi. For U**x hacks, this would be similar to
how makefile variables can have their values overridden on the command
line. Instead of doing this on the default form found on
http://xml.resource.org, it could be done using an "Advanced" form that
allowed you to specify the values of various processing directives, with
the default value being "". For example, you might see this in the form

	Include <cref> in output: * default o yes o no

This could transform into one of these values:

	picomments=
	picomments=yes
	picomments=no

The first says to use whatever value is in the file, and would be
equivalent to not specifying the parameter. The latter two would provide
the given value to the processing directive, as in:

	<?rfc comments="no"?>

I never use the tcl command directly, but I could see how this could
translate to use there as well.

Thoughts?

	Tony Hansen
	[email-masked]
>From tony at att.com  Mon Mar 26 17:57:47 2007
From: tony at att.com (Tony Hansen)
Date: Mon Mar 26 13:57:33 2007
Subject: [xml2rfc] <cref>'s and formatting
Message-ID: <[email-masked]>

Another issue that came up with my conversation the other day about
using <cref>s, is that formatting commands are totally ignored within
the <cref>. All you ever get is a blob of unending text. You can't get
newlines or white space or *anything*, much less doing anything else
remotely interesting.

I'd like to see the DTD and processing model modified to support
formatting. <cref> could possibly be made equivalent to <t> for all
intents, except that it's contents are conditionally output.

	Tony Hansen
	[email-masked]
>From julian.reschke at gmx.de  Tue Mar 27 10:11:54 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Mar 27 00:12:17 2007
Subject: [xml2rfc] xml2rfc.cgi, processing directives and <cref>
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Tony Hansen schrieb:
> I was having a conversation the other day with someone about using
> <cref> and we came up with an idea I'd like to explore. The issue is
> that if you'd like to sometimes have <cref>s be visible, and other times
> not, you need to edit the source file to change the processing
> directive. He recalled one time he accidentally submitted an I-D with
> the <cref>s included.
> 
> So our idea is to be able to override processing directives via command
> line arguments to xml2rfc.cgi. For U**x hacks, this would be similar to
> how makefile variables can have their values overridden on the command
> line. Instead of doing this on the default form found on
> http://xml.resource.org, it could be done using an "Advanced" form that
> allowed you to specify the values of various processing directives, with
> the default value being "". For example, you might see this in the form
> ...

+1. This is similar to what I do in rfc2629.xslt with XSLT parameters.

Best regards, Julian
>From lars.eggert at nokia.com  Thu Mar 29 12:57:59 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Mar 29 01:58:45 2007
Subject: [xml2rfc] xml2rfc for IONs
Message-ID: <[email-masked]>

Hi,

I'm currently editing an ION, using the steps on http:// 
www1.tools.ietf.org/group/iesg/trac/wiki/IonIzation, in particular,  
the template at https://www1.tools.ietf.org/svn/group/iesg/ions/ 
drafts/ion-ion-xml-template.xml

When generating HTML, the output looks OK.

Personally, I'd prefer text IONs, because they work better with  
email. The generated text looks basically OK; the only small problem  
is that the footer line starts with ", et al.", because no author is  
specified.

Can xml2rfc lean to suppress the ", et al." when there is no author?

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/65ac03a3/smime.bin
>From simithn at yahoo.com  Thu Mar 29 14:11:46 2007
From: simithn at yahoo.com (simith nambiar)
Date: Thu Mar 29 05:11:50 2007
Subject: [xml2rfc] Numbering references section.
Message-ID: <[email-masked]>

Hello all,
                I'am a newbie to xml2rfc, i have a question regarding the numbering of
xml2rfc for the References section.

This is what i'am doing in the xml file ( a part of it is shown ) .

=======================================================

        <references title='Normative References'>
            &rfc2119;  &rfc3515;  &rfc3261;  &rfc3688;
            
        </references>

========================================================

I'am getting these references correctly, but there are no numbers against each of the RFC, please can someone tell what has to be added to get the numbering for this section.

Thank you.

Cheers,
Simith

---------------------------------
 Here?s a new way to find what you're looking for - Yahoo! Answers 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/d468d8bb/attachment.htm
>From simithn at yahoo.com  Thu Mar 29 14:22:09 2007
From: simithn at yahoo.com (simith nambiar)
Date: Thu Mar 29 05:22:12 2007
Subject: [xml2rfc] Numbering references section.
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi All,
           I forgot to mention , iam using the web interface at http://xml.resource.org/  for the XML to ID conversion.

Cheers,
Simith

simith nambiar <[email-masked]> wrote: Hello all,
                I'am a newbie to xml2rfc, i have a question regarding the numbering of
xml2rfc for the References section.

This is what i'am doing in the xml file ( a part of it is shown ) .

=======================================================

        <references title='Normative References'>
            &rfc2119;  &rfc3515;  &rfc3261;  &rfc3688;
            
        </references>

========================================================

I'am getting these references correctly, but there are no numbers against each of the RFC, please can someone tell what has to be added to get the numbering for this section.

Thank  you.

Cheers,
Simith

---------------------------------
  Here?s a new way to find what you're looking for - Yahoo! Answers _______________________________________________
xml2rfc mailing list
[email-masked]
http://lists.xml.resource.org/mailman/listinfo/xml2rfc

Simith Nambiar

=====================================================================
Twenty years from now you will be more disappointed by the things you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbor. Catch the trade winds in your sails. 
Explore. Dream. Discover.

 - Mark Twain.
======================================================================
 				
---------------------------------
 Here?s a new way to find what you're looking for - Yahoo! Answers 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/88630bc3/attachment.htm
>From julian.reschke at gmx.de  Thu Mar 29 15:25:15 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar 29 05:25:27 2007
Subject: [xml2rfc] Numbering references section.
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

simith nambiar schrieb:
> Hello all,
>                 I'am a newbie to xml2rfc, i have a question regarding 
> the numbering of
> xml2rfc for the References section.
> 
> This is what i'am doing in the xml file ( a part of it is shown ) .
> 
> =======================================================
> 
>         <references title='Normative References'>
>             &rfc2119;  &rfc3515;  &rfc3261;  &rfc3688;
>            
>         </references>
> 
> ========================================================
> 
> I'am getting these references correctly, but there are no numbers 
> against each of the RFC, please can someone tell what has to be added to 
> get the numbering for this section.
> 
> Thank you.

I'm not sure what the issue is...

1) The section number for the section "Normative References" missing? 
That would be a bug.

2) The references not being numbered? That depends on the "symrefs" 
processing instruction (see 
<http://xml.resource.org/authoring/README.html#processing.instructions>). 
Note that the RFC Editor IMHO prefers symbolic references over numbered 
ones (and so do I :-).

Best regards, Julian
>From simithn at yahoo.com  Thu Mar 29 14:38:09 2007
From: simithn at yahoo.com (simith nambiar)
Date: Thu Mar 29 05:38:13 2007
Subject: [xml2rfc] Numbering references section.
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke <[email-masked]> wrote: simith nambiar schrieb:
> Hello all,
>                 I'am a newbie to xml2rfc, i have a question regarding 
> the numbering of
> xml2rfc for the References section.
> 
> This is what i'am doing in the xml file ( a part of it is shown ) .
> 
> =======================================================
> 
>         
>             &rfc2119;  &rfc3515;  &rfc3261;  &rfc3688;
>            
>         
> 
> ========================================================
> 
> I'am getting these references correctly, but there are no numbers 
> against each of the RFC, please can someone tell what has to be added to 
> get the numbering for this section.
> 
> Thank you.

I'm not sure what the issue is...

1) The section number for the section "Normative References" missing? 
That would be a bug.

2) The references not being numbered? That depends on the "symrefs" 
processing instruction (see 
). 
Note that the RFC Editor IMHO prefers symbolic references over numbered 
ones (and so do I :-).

Hello Julian,
                      i found that the xml file has a <?rfc symrefs="yes" ?> , i changed it to no , now i see the numbers :-)

Thank you for pointing out.

Best regards,
Simith

 				
---------------------------------
 Here?s a new way to find what you're looking for - Yahoo! Answers 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070329/486f68fc/attachment.htm
>From julian.reschke at gmx.de  Thu Mar 29 15:50:47 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Mar 29 05:50:57 2007
Subject: [xml2rfc] Numbering references section.
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

simith nambiar schrieb:
>     Hello Julian,
>                           i found that the xml file has a <?rfc
>     symrefs="yes" ?> , i changed it to no , now i see the numbers :-)
> 
>     Thank you for pointing out.

Again, AFAIK the recommendation for RFCs is to actually use symbolic 
references.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Thu Mar 29 17:19:41 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Mar 29 07:20:34 2007
Subject: [xml2rfc] Re: xml2rfc for IONs
References: <[email-masked]>
Message-ID: <[email-masked]>

Lars Eggert wrote:
 
> I'd prefer text IONs, because they work better with email.

You can use the text or maybe better the unpaginated output 
of xml2rfc if you don't need UTF-8 or meta data (keywords).

> Can xml2rfc lean to suppress the ", et al." when there is
> no author?

The template is apparently no "valid" xml2rfc input anyway,
therefore adding a line...

    <author surname="IETF"><organization /></author>

...just below the <title> element doesn't make it worse as
it is.  With unpaginated output there are no page headers.

Frank

From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu Mar 29 16:25:45 2007
Subject: [xml2rfc] Re: Problems with xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
> the server broke and is being rebuilt. we'll remove the A RR for that ip 
> address until it's fixed.

It occurs to me that xml2rfc has become important enough to the IETF to 
warrant at least having a mirrored copy of the site be maintained by the IETF 
secretariat.

With the IETF Tools Team, such things are easier to pursue, these days, if 
folks think it a useful idea.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From mrose at dbc.mtview.ca.us  Thu Mar 29 17:30:46 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Mar 29 16:30:53 2007
Subject: [xml2rfc] Re: Problems with xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> It occurs to me that xml2rfc has become important enough to the  
> IETF to warrant at least having a mirrored copy of the site be  
> maintained by the IETF secretariat.
>
> With the IETF Tools Team, such things are easier to pursue, these  
> days, if folks think it a useful idea.

fine by me. would whoever is responsible for such things contact bill  
and myself.

/mtr

From: tony at att.com (Tony Hansen)
Date: Thu Mar 29 18:19:28 2007
Subject: [xml2rfc] Re: Problems with xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

That would be Henrik. I've CC'd him.

	Tony

Marshall Rose wrote:
>> It occurs to me that xml2rfc has become important enough to the IETF
>> to warrant at least having a mirrored copy of the site be maintained
>> by the IETF secretariat.
>>
>> With the IETF Tools Team, such things are easier to pursue, these
>> days, if folks think it a useful idea.
> 
> fine by me. would whoever is responsible for such things contact bill
> and myself.

From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Thu Mar 29 22:26:28 2007
Subject: [xml2rfc] xml2rfc for IONs
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> Personally, I'd prefer text IONs, because they work better with email. 

Clearly, IONs being officially an experiment, the current formatting
options can be discussed (but not here, I guess). The idea was simplicity.

    Brian

On 2007-03-29 11:57, Lars Eggert wrote:
> Hi,
> 
> I'm currently editing an ION, using the steps on 
> http://www1.tools.ietf.org/group/iesg/trac/wiki/IonIzation, in 
> particular, the template at 
> https://www1.tools.ietf.org/svn/group/iesg/ions/drafts/ion-ion-xml-template.xml 
> 
> 
> When generating HTML, the output looks OK.
> 
> Personally, I'd prefer text IONs, because they work better with email. 
> The generated text looks basically OK; the only small problem is that 
> the footer line starts with ", et al.", because no author is specified.
> 
> Can xml2rfc lean to suppress the ", et al." when there is no author?
> 
> Lars
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From lars.eggert at nokia.com  Fri Mar 30 09:46:37 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Mar 29 22:47:25 2007
Subject: [xml2rfc] xml2rfc for IONs
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 2007-3-30, at 9:26, ext Brian E Carpenter wrote:
>> Personally, I'd prefer text IONs, because they work better with  
>> email.
>
> Clearly, IONs being officially an experiment, the current formatting
> options can be discussed (but not here, I guess). The idea was  
> simplicity.

Let me restate that as "I'd prefer text IONs generated by xml2rfc" -  
I like being able to generate HTML from the same source. (Since  
formatting doesn't matter, xml2rfc's text format should be fine, and  
it is simple to generate.)

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070330/9c476b81/smime.bin
>From henrik at levkowetz.com  Fri Mar 30 09:53:13 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Mar 29 23:53:21 2007
Subject: [xml2rfc] Re: Problems with xml.resource.org
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

on 2007-03-30 02:30 Marshall Rose said the following:
>
[crocker]:
>> It occurs to me that xml2rfc has become important enough to the  
>> IETF to warrant at least having a mirrored copy of the site be  
>> maintained by the IETF secretariat.
>>
>> With the IETF Tools Team, such things are easier to pursue, these  
>> days, if folks think it a useful idea.
> 
> fine by me. would whoever is responsible for such things contact bill  
> and myself.

Done, off-list.

	Henrik
>From john+xml at jck.com  Fri Mar 30 17:31:10 2007
From: john+xml at jck.com (John C Klensin)
Date: Fri Mar 30 13:31:18 2007
Subject: [xml2rfc] Re: minor nitlet I'd like flagged
Message-ID: <[email-masked]>

--On Tuesday, 20 March, 2007 04:48:03 -0400 Tony Hansen
<[email-masked]> wrote...

> Something I periodically trip over is forgetting to change the
> name of the draft I'm writing from e.g. "-01" to "-02".
> 
> It would be nice if xml2rfc could optionally check
> 
> 	<rfc ... docName="draft-ietf-xyz-01.txt">
> 
> against the name of the file being processed, and warn if they
> don't match up through the "-02" portion of the name.

If this is done, please be sure it is optional and easily turned
off.  Some of us use naming conventions for intermediate
versions that this sort of check could really foul up.

   john

From: fenner at gmail.com (Bill Fenner)
Date: Fri Mar 30 15:18:19 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 3/20/07, Tony Hansen <[email-masked]> wrote:
> Something I periodically trip over is forgetting to change the name of
> the draft I'm writing from e.g. "-01" to "-02".
>
> It would be nice if xml2rfc could optionally check
>
>         <rfc ... docName="draft-ietf-xyz-01.txt">
>
> against the name of the file being processed, and warn if they don't
> match up through the "-02" portion of the name.

Just want to check on this, since it seems that different people have
different usage models.  I tend to name things with short names that
have no relationship to the output file, e.g.,
draft-fenner-iana-exp-2780 was created by iana-experimental.xml .  Are
you proposing that with this usage model, the warning should always
trigger?

> PS. I use the online xml2rfc submission form.

This is actually a sticky wicket: the online converter can return
status or the converted file, but not both, so it chooses to ignore
warnings in favor of supplying the converted file.

Certainly it'd be possible to return an HTML status page that uses an
http refresh header to download the converted document, but I'm not
sure making that change would make us many friends (especially since
right now you can easily script the online conversion).

  Bill
>From fenner at gmail.com  Fri Mar 30 16:21:55 2007
From: fenner at gmail.com (Bill Fenner)
Date: Fri Mar 30 15:22:02 2007
Subject: [xml2rfc] Announcing 1.33pre3
Message-ID: <[email-masked]>

Greetings,

xml2rfc 1.33pre3 has been released. Changes since 1.33pre2 include:

DTD Change:
  Permit iref in figure
Checks version when run and warns if there is a newer version available
Improved error messages when:
  Anchor omitted from reference when using symrefs
  xref points to unknown target
TOC is permitted to begin below the top 1/3 of the page if it'll fit
and rfcedstyle is true
Links to RFCs are to the tools.ietf.org HTML version.

More details at http://xml.resource.org/experimental.html

  Bill
>From Nicolas.Williams at sun.com  Fri Mar 30 21:14:13 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat Mar 31 13:03:03 2007
Subject: [xml2rfc] Entities broken lately
Message-ID: <[email-masked]>

xml2rfc 1.31 and 1.32 does not properly deal with ENTITYs in the
attached I-D.  It does not include the ENTITYs where they are referenced
and does not warn.

Yes, I should format the text in those ENTITYs as XML, but this is a
longish I-D that I wrote before I started using xml2rfc and the
conversion was tedious.  Relying on ENTITYs worked for a while, but now
does not work anymore -- the last version of xml2rfc that processed this
I-D correctly was 1.30.

Nico
-- 
-------------- next part --------------
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 SYSTEM '~/public_html/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3066 SYSTEM '~/public_html/bibxml/reference.RFC.3066.xml'>
    <!ENTITY rfc3244 SYSTEM '~/public_html/bibxml/reference.RFC.3244.xml'>
    <!ENTITY rfc4120 SYSTEM '~/public_html/bibxml/reference.RFC.4120.xml'>
    <!ENTITY x680 SYSTEM '~/public_html/bibxml/reference.CCITT.X680.2002.xml'>
    <!ENTITY x690 SYSTEM '~/public_html/bibxml/reference.CCITT.X690.2002.xml'>
]>

<!--
	To make it easier to re-format from the original raw text we use
	XML entities (text macros) to drop the old, pre-formatted (but
	not paginated) operation description text, one macro
	per-operation.

	These are internal entities, meaning the text is all in the same
	doc, but we could make these external entities, i.e., each one
	in its own file (perhaps that would eliminate the need to escape
	angle brackets, ampersands and single quotes in the text).
-->

    <!ENTITY null '
NAME

   null - Null or "ping" operation

DESCRIPTION

   The null request is intended for use with TCP; its purpose is
   similar to RPC null procedures and is akin to a "ping" operation.

ERRORS

   None.
   '>

   <!ENTITY change-pw '
NAME

   change-pw - Change password operation

SYNOPSIS

   Req-change-pw(old-pw, [languages], [new-pw],
                 [commit], [etypes]) -&gt;
      Rep-change-pw([info-text], [new-pw], [etypes]) |
      Err-change-pw([help-text], error code, [error info])

DESCRIPTION

   Change a principal&#39;s password.

   The change password request has one required, three optional and
   one defaulted arguments: "old-pw" (required), "languages,"
   "new-pw", "commit" (defaults to "TRUE") and "etypes",
   corresponding to the target principal&#39;s old password, its
   preferred languages, its new password, a boolean indicating
   whether or not to make the new long-term key available for
   immediate use, and the desired enctypes for the new long-term
   keys.

   The server MUST validate the old password and MUST check the
   quality of the new password, if sent, according the password
   quality policy associated with the target principal.

   If the old and new passwords in the request are the same strings,
   and the principal is not currently required to change its
   password, then the server MAY permit the password change as way to
   change a principal&#39;s enctypes and string-to-key parameters.  This
   feature provides a way to, for example, add enctypes to a
   principals&#39; password-derived long-term keys without forcing a
   password change following an upgrade to the KDC that adds support
   for new enctypes.

   A client MAY request that the server generate a new password by
   excluding the new password from its request, in which case the
   server MUST either generate a new password or respond with an
   error indicating that it does not support this feature.

   Server-generated passwords MUST meet the target principal&#39;s
   password quality policy.  It is RECOMMENDED that server-generated
   passwords be user-friendly, that is, memorable and that the target
   principal&#39;s preferred languages be taken into account by the
   password generation alogrithm used by the server.

   Uncommitted password changes are commited using the commit-keys
   operation.

RETURN

   Upon successful password changes the server responds with a
   Rep-change-pw.  The fields of Rep-change-pw are all optional and
   include:

      - &#39;info-text&#39; which the server can use to send a message to the
        user such as "Your new password will expire in 90 days," for
        example.

      - &#39;new-pw&#39; which the server MUST include if the client
        requested that the server generate a new password; generated
        passwords MUST pass the target principal&#39;s password quality
        policy.

      - &#39;etypes&#39; which the server MAY include to indicate which types
        of long-term keys it created for the target principal and
        which the server MUST include if the client specified a set
        of enctypes in its request.

ERRORS

   The server may respond to change password requests with protocol
   or operation errors.

   All operation errors include an optional &#39;help-text&#39; field by
   which the server can describe the error in a human-readable,
   localizaed string.

   Change password error codes include:

      - generic-error

      - old-pw-incorrect

      - wont-generate-new-pw

        The server will not generate a new password for this
        principal or does not support password generation in general.

      - new-pw-rejected-generic

        The client&#39;s proposed new password failed the target
        principal&#39;s password quality policy.

        The server MUST include a description of the password quality
        policy or aspect of it that the client&#39;s proposed new
        password failed to meet.

        The server MAY generate and send a new password that the
        client can then use as a new password and which is guaranteed
        to pass the target principal&#39;s current password quality
        policy.

        The server MAY include a set of policy error code hints.

      - etype-not-supported

        The client requested an enctype that the KDC does not
        support.
    '>

    <!ENTITY set-pw '
NAME

   set-pw - Set password operation

SYNOPSIS

   Req-set-pw([languages], [new-pw], [commit], [etypes]) -&gt;
      Rep-set-pw([info-text], [new-pw], [etypes]) |
      Err-set-pw([help-text], error code, [error info])

DESCRIPTION

   Administratively set a principal&#39;s password.

   The set password request has three optional and one defaulted
   arguments: "languages", "new-pw," "commit" (defaulted to "TRUE")
   and "etypes", corresponding to the target principal&#39;s preferred
   languages, new password, a boolean indicating whether or not to
   make the new long-term key available for immediate use, and the
   desired enctypes for the new long-term keys.

   The server MUST check the quality of the new password, if sent,
   according the password quality policy associated with the target
   principal.

   The server SHOULD require that the client use the change-pw
   operation instead of set-pw when the client principal and the
   target principal are the same.

   A client MAY request that the server generate a new password by
   excluding the new password from its request, in which case the
   server MUST either generate a new password or respond with an
   error indicating that it does not support this feature.

   Server-generated passwords MUST meet the target principal&#39;s
   password quality policy.  It is RECOMMENDED that server-generated
   passwords be user-friendly, that is, memorable and that the target
   principal&#39;s preferred languages be taken into account by the
   password generation alogrithm used by the server.

RETURN

   Upon successfully setting a password the server responds with a
   Rep-set-pw.  The fields of Rep-set-pw are all optional and
   include:

      - &#39;info-text&#39; which the server can use to send a message to the
        user such as "Your new password will expire in 90 days," for
        example.

      - &#39;new-pw&#39; which the server MUST include if the client
        requested that the server generate a new password; generated
        passwords MUST pass the target principal&#39;s password quality
        policy.

      - &#39;etypes&#39; which the server MAY include to indicate which types
        of long-term keys it created for the target principal and
        which the server MUST include if the client specified a set
        of enctypes in its request.

ERRORS

   The server may respond to set password requests with protocol or
   operation errors.

   All operation errors include an optional &#39;help-text&#39; field by
   which the server can describe the error in a human-readable,
   localizaed string.

   Set password error codes include:

      - generic-error

      - use-change-pw

        The server demands that the client use the change-pw
        operation for the target principal of the set-pw request.

      - wont-generate-new-pw

        The server will not generate a new password for this
        principal or does not support password generation in general.

      - new-pw-rejected-generic

        The client&#39;s proposed new password failed the target
        principal&#39;s password quality policy.

        The server MUST include a description of the password quality
        policy or aspect of it that the client&#39;s proposed new
        password failed to meet.

        The server MAY generate and send a new password that the
        client can then use as a new password and which is guaranteed
        to pass the target principal&#39;s current password quality
        policy.

        The server MAY include a set of policy error code hints.

      - etype-not-supported

        The client requested an enctype that the KDC does not
        support.
    '>

    <!ENTITY set-keys '
NAME

   set-keys - Set a principal&#39;s long-term keys

SYNOPSIS

   Req-set-keys(new-keys, commit?, [isupport]) -&gt;
      Rep-set-keys([info-text], kvno, aliases, [isupport])

DESCRIPTION

   The set-keys request consists of two required fields and one
   optional field: "new-keys", "commit" (a boolean field - see below)
   and "isupport", an optional field for indicating to the KDC what
   Kerberos V features are supported by the target principal.

   When "commit" is true the KDC makes the new keys available for
   issueing tickets encrypted in them immediately.  Otherwise the
   client MUST follow up with a commit-keys request to make the keys
   available.  This feature is useful for changing keys shared by
   multiple hosts, in clustered services, for example, in an atomic
   manner.

   If a principal has keys are awaiting commitment when a new
   set-keys request for that principal s made then the KDC MUST
   overwrite the deferred keys.

RETURN

   For successful set-keys operations the server returns:

      - Informational text, optional.

      - The new kvno for the target principal.

      - A list of aliases of the target principal known to the KDC
        (optional).

      - The set of Kerberos V features supported by the KDC
        (optional).

ERRORS

   The server may respond with the following errors:

      - generic
      - deferred-commit-no-support
      - etype-no-support
    '>

    <!ENTITY gen-keys '
NAME

   gen-keys - Generate long-term keys for a principal

SYNOPSIS

   Req-gen-keys(etypes, [entropy], commit?, [isupport]) -&gt;
      Rep-set-keys([info-text], key, kvno, aliases, [isupport])

DESCRIPTION

   The gen-keys is similar to the set-keys request but differs in
   that the server generates keys of client-requested enctypes,
   rather than the client providing specific keys.

   The gen-keys request consists of two required fields and two
   optional fields: "etypes" (the enctypes of the new keys),
   "entropy", "commit" and "isupport".

   If a principal has keys are awaiting commitment when a new
   set-keys request for that principal s made then the KDC MUST
   overwrite the deferred keys.

RETURN

   For successful set-keys operations the server returns:

      - Informational text, optional.

      - The new kvno for the target principal.

      - The new key (only one is needed).

      - A list of aliases of the target principal known to the KDC
        (optional).

      - The set of Kerberos V features supported by the KDC
        (optional).

ERRORS

   The server may respond with the following errors:

      - generic
      - deferred-commit-no-support
      - etype-no-support
    '>

    <!ENTITY get-keys '
NAME

   get-keys - Retrieve a principal&#39;s uncommitted keys

SYNOPSIS

   Req-get-keys(kvno) -&gt;
      Rep-get-keys([info-text], keys, aliases, [isupport]) |
      Err-get-keys([help-text], error code, [error info])

DESCRIPTION

   This request allows a client to get the keys set or generated in a
   previous set-keys or gen-keys request with deferred commitment.

RETURN

   If the target principal and kvno correspond to uncommitted keys
   the server MUST respond with the actual keys that would be set by
   a subsequent commit-keys request.  Otherwise the server MUST
   respond with an error (meaning that this operation cannot be used
   to extract keys from the KDC that may be in use).

ERRORS

      - generic
      - kvno-committed
      - no-such-kvno
    '>

    <!ENTITY commit-keys '
NAME

   commit-keys - Commit a principal&#39;s new long-term keys

SYNOPSIS

   Req-commit-keys(kvno) -&gt;
      Rep-commit-keys() |
      Err-commit-keys([help-text], error code, [error info])

DESCRIPTION

   The commit-keys operation allows a client to bring a principal&#39;s
   new keys into use at the KDC.

   Clients should make a commit-keys request corresponding to a
   deferred commitment set-keys/gen-keys operation as soon as the
   local key database for the target principal is updated.

   The target principal name and the kvno MUST match those from a
   prior set-keys or gen-keys operation.

   Servers MAY expire delayed key commitments at will.  Servers
   SHOULD expire uncommitted new keys after a reasonable amount of
   time (600 seconds is RECOMMENDED).

   Servers MUST respond to new set-keys requests for principals with
   pending, uncommitted new keys by expiring the uncommitted new keys
   and proceeding as if there had been no expired new keys.

ERRORS

   - generic
   - op-kvno-expired
   - op-kvno-unknown
   - new-keys-conflict (A set-keys or gen-keys request succeeded
                        subsequent to the request that matches this
                        {principal, kvno} tuple.)
    '>

    <!ENTITY get-pw-policy '
NAME

   get-pw-policy - Retrieve a principal&#39;s password policy

SYNOPSIS

   Req-get-pw-policy() -&gt;
      Rep-get-pw-policy([policy name], [policy description])

DESCRIPTION

   Returns a description of the target principal&#39;s associated
   password quality policy, if any, as a list of localized
   UTF8String values.

   Clients can use this operation in conjunction with the change-pw
   operation to obtain text that can be displayed to the user before
   the user actually enters a new password.

   It is common for sites to set policies with respect to password
   quality.  It is beyond the scope of this document to describe such
   policies.  Management of password quality policies&#39; actual content
   is also beyond the scope of this protocol.

ERRORS

   No operation errors are defined.

   '>

   <!ENTITY get-princ-aliases '
NAME

   get-princ-aliases - Retrieve a principal&#39;s aliases

SYNOPSIS

   Req-get-princ-aliases() -&gt;
      Rep-get-princ-aliases(aliases)

DESCRIPTION

   Returns a list of aliases of the target principal.

ERRORS

   No operation-specific errors.
   '>

   <!ENTITY get-realm-krb5-support '
NAME

   get-realm-krb5-support - List features supported by the realm

SYNOPSIS

   Req-get-realm-krb5-support() -&gt;
      Rep-get-realm-krb5-support(isupport)

DESCRIPTION

   Returns set of Kerberos V features support by the target
   principal&#39;s realm&#39;s KDCs.

ERRORS

   No operation-specific errors.
   '>

   <!ENTITY get-s2kparams '
NAME

   get-s2kparams

SYNOPSIS

   Req-get-s2kparams() -&gt;
      Rep-get-s2kparams(princ-s2kparams)

DESCRIPTION

   Returns the string2key parameters for the principal&#39;s current
   password-derived long-term keys, if any (if there are none then
   the principal does not have a password-derived long-term key).

ERRORS

   No operation-specific errors.
   '>
    <!ENTITY asn1module '
DEFINITIONS EXPLICIT TAGS ::= BEGIN
-- 
-- Note:  EXPLICIT tagging is in use by default throughout this
--        module.

-- From [clarifications] with modifications
PrincipalName            ::= SEQUENCE {
     name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
}
Realm                    ::= UTF8String (IA5String, ...)
Salt                     ::= UTF8String (IA5String, ...)
Password                 ::= UTF8String (IA5String, ...)

-- NOTE WELL: Principal and realm names MUST be constrained by the
--            specification of the version of Kerberos V used by the
--            client.

-- 
-- [Perhaps PrincipalName should be a SEQUENCE of an optional name
--  type and a UTF8String, for simplicity.]

-- From [clarifications]
Int32            ::= INTEGER (-2147483648..2147483647)
UInt32           ::= INTEGER (0..4294967295)

-- Based on [clarifications]
Etype            ::= Int32
Etype-Info-Entry ::= SEQUENCE {
     etype           [0] Etype,
     salt            [1] Salt OPTIONAL,
     s2kparams       [2] OCTET STRING OPTIONAL
}
Key              ::= SEQUENCE {
     enc-type        [0] Etype,        -- from Kerberos
     key             [1] OCTET STRING
}

Language-Tag     ::= UTF8String -- Constrained by [RFC3066]

-- Empty, extensible SEQUENCEs are legal ASN.1
Extensible-NULL  ::= SEQUENCE {
     ...
}

-- Kerberos clients negotiate some parameters relating to their peers
-- indirectly through the KDC.  Today this is true of ticket session
-- key enctypes, but in the future this indirect negotiation may also
-- occur with respect to the minor version of Kerberos V to be used
-- between clients and servers.  Additionally, KDCs may need to know
-- what authorization-data types are supported by service principals,
-- both, for compatibility with legacy software and for optimization.
--
-- Thesefore it is important for KDCs to know what features of
-- Kerberos V each service principal supports.
--
-- In version 2.0 of this protocol the clients and servers may notify
-- each other of their support for:
--
--  - enctypes
--  - authorization data types
--  - transited encoding data types
--
-- All authorization-data types defined in [clarifications] are
-- assumed to be supported if the minor version is 1 and do not need
-- to be included in the ad-type list.
--
-- Int32 is used for enctype and transited encoding data type
-- identifiers.

--
-- An extensible CHOICE of Int32 is used for authorization data
-- types.

KerberosV-TR-ID             ::= Int32

KerberosV-AD-ID             ::= CHOICE {
     ad-int                [0] Int32,
     ...
}

KerberosVSupportNego        ::= SEQUENCE {
     enc-types       [0] SEQUENCE OF Etype,
     ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
                                 -- authorization data types
     tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL
                                 -- transited encoding types
}

Request                     ::= [APPLICATION 0] SEQUENCE {
     pvno-minor      [0] INTEGER DEFAULT 0,
     languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
             -- Should be defaulted to the SEQUENCE of "i-default"
     targ-name       [2] PrincipalName OPTIONAL,
     targ-realm      [3] Realm OPTIONAL,
             -- If targ-name/realm are missing then the request
             -- applies to the principal of the client
     dry-run         [4] BOOLEAN DEFAULT FALSE,
     operation       [5] Op-req,
     ...
}

Response                    ::= [APPLICATION 1] SEQUENCE {
     pvno-minor      [0] INTEGER DEFAULT 0,
     language        [1] Language-Tag DEFAULT "i-default",
     result          [2] Op-rep,
     ...
}

Error-Response              ::= [APPLICATION 2] SEQUENCE {
     pvno-minor      [0] INTEGER DEFAULT 0,
     language        [1] Language-Tag DEFAULT "i-default",
     error-code      [2] ProtocolErrorCode,
     help-text       [3] UTF8String OPTIONAL,
     op-error        [4] Op-err OPTIONAL,
     ...
}

Op-req                      ::= CHOICE {
     null                     [0] Req-null,
     change-pw                [1] Req-change-pw,
     set-pw                   [2] Req-set-pw,
     set-keys                 [3] Req-set-keys,
     gen-keys                 [4] Req-gen-keys,
     get-keys                 [5] Req-get-keys,
     commit-keys              [6] Req-commit-keys,
     get-pw-policy            [7] Req-get-pw-policy,
     get-princ-aliases        [8] Req-get-princ-aliases,
     get-realm-krb5-support   [9] Req-get-realm-krb5-support,
     get-s2kparams            [10] Req-get-s2kparams,
     ...
}

Op-rep                     ::= CHOICE {
     null                    [0] Rep-null,
     change-pw               [1] Rep-change-pw,
     set-pw                  [2] Rep-set-pw,
     set-keys                [3] Rep-set-keys,
     gen-keys                [4] Req-gen-keys,
     get-keys                [5] Req-get-keys,
     commit-keys             [6] Rep-commit-keys,
     get-pw-policy           [7] Rep-get-pw-policy,
     get-princ-aliases       [8] Rep-get-princ-aliases,
     get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
     get-s2kparams           [10] Rep-get-s2kparams,
     ...
}

Op-err        ::= CHOICE {
     null                    [0] Err-null,
     change-pw               [1] Err-change-pw,
     set-pw                  [2] Err-set-pw,
     set-keys                [3] Err-set-keys,
     gen-keys                [4] Err-gen-keys,
     get-keys                [5] Err-get-keys,
     commit-keys             [6] Err-commit-keys,
     get-pw-policy           [7] Err-get-pw-policy,
     get-princ-aliases       [8] Err-get-princ-aliases,
     get-realm-krb5-support  [9] Err-get-realm-krb5-support,
     get-s2kparams           [10] Err-get-s2kparams,
     ...
}

ProtocolErrorCode           ::= ENUM {
     proto-format-error,
     proto-unsupported-major-version,
     proto-unsupported-minor-version,
     proto-unsupported-operation,      -- Request CHOICE tag unknown
     proto-generic-see-op-error,       -- See Op-error
     proto-wrong-service-principal,    -- Use kadmin/setpw
     proto-re-authentication-required,
     proto-initial-ticket-required,
     proto-client-and-target-realm-mismatch,
     proto-target-principal-unknown,
     proto-authorization-failed,
     proto-dry-run-not-permitted,
     proto-fresh-ticket-required,
     ...
}

-- These codes are hints for clients, primarily for when they are
-- used for changing the passwords of automated principals; error
-- replies carry password quality policy help text that is more
-- appropriate for clients to display to users.
PW-Quality-Codes        ::= ENUM {
     pwq-generic,
     pwq-too-soon,
     pwq-history,
     pwq-too-short,
     pwq-dictionary-words,
     pwq-prohibited-codepoints,
     pwq-need-more-char-classes,
     ...
}

--
-- Requests and responses
--

-- NULL request, much like ONC RPC&#39;s NULL procedure - NOT extensible
Req-null    ::= NULL

Rep-null    ::= NULL

Err-null    ::= NULL

-- Change password
Req-change-pw        ::= SEQUENCE {
     old-pw            [0] Password,
     new-pw            [1] Password OPTIONAL,
     commit            [2] BOOLEAN DEFAULT TRUE,
     etypes            [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}

Rep-change-pw        ::= SEQUENCE {
     info-text         [0] UTF8String OPTIONAL,
     new-pw            [1] Password OPTIONAL,
                         -- generated by the server if present
                         -- (and requested by the client)
     etypes            [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}

Err-change-pw        ::= SEQUENCE {
     help-text         [0] UTF8String OPTIONAL,
     error             [1] CHOICE {
         op-generic-error           [0] Extensible-NULL,
         op-old-pw-incorrect        [1] Extensible-NULL,
         op-wont-generate-new-pw    [2] Extensible-NULL,
         op-new-pw-rejected-generic [3] SEQUENCE {
                 policy                  [1] SEQUENCE OF UTF8String,
                 suggested-pw            [2] Password OPTIONAL,
                 policy-codes            [3] SET OF PW-Quality-Codes
                                                 OPTIONAL
         }
         op-etype-not-supported     [4] SEQUENCE {
                 supported-etypes   [1] SEQUENCE OF Etype
         }
     }
}

-- Set password
Req-set-pw        ::= SEQUENCE {
     languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
     new-pw                [1] Password OPTIONAL,
     commit                [2] BOOLEAN DEFAULT TRUE,
     etypes                [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
}

Rep-set-pw        ::= SEQUENCE {
     info-text        [0] UTF8String OPTIONAL,
     new-pw                [1] Password OPTIONAL,
                             -- generated by the server if present
                             -- (and requested by the client)
     etypes                [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
}

Err-set-pw        ::= Err-change-pw

-- Set keys
Req-set-keys      ::= SEQUENCE {
     keys            [0] SEQUENCE OF Key,
     commit          [1] BOOLEAN DEFAULT TRUE,
                             -- TRUE  -&gt; install keys now
                             -- 
                             -- FALSE -&gt; require set-keys-commit
                             --          before issuing tickets
                             --          encrypted with these keys.
                             -- 
                             -- See commit-keys op
     isupport        [2] KerberosVSupportNego OPTIONAL
                             -- For future Kerberos V extensions KDCs
                             -- may need to know what krb5 version is
                             -- supported by individual service
                             -- principals.  This field provides a
                             -- way to tell the KDC what version of
                             -- Kerberos V the target principal
                             -- supports.
}

Rep-set-keys        ::= SEQUENCE {
     info-text        [0] UTF8String OPTIONAL,
     kvno             [1] UInt32,
     aliases          [2] SEQUENCE OF SEQUENCE {
             name     [0] PrincipalName,
             realm    [1] Realm OPTIONAL
     },
     isupport         [3] KerberosVSupportNego OPTIONAL
     -- Should there be ETYPE-INFO2 stuff here?
}

Err-set-keys        ::= SEQUENCE {
     help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
     error         [1] CHOICE {
             op-generic                    [0] Extensible-NULL,
             op-deferred-commit-no-support [1] Extensible-NULL,
             op-etype-no-support           [2] SEQUENCE OF {
                     supported-etypes      [1] SEQUENCE OF Etype
             }
     }
}

-- Generate keys
Req-gen-keys        ::= SEQUENCE {
     etypes           [0] SEQUENCE (1..MAX) OF Etype,
     entropy          [1] OCTET STRING OPTIONAL,
     commit           [2] BOOLEAN DEFAULT TRUE,
                             -- TRUE  -&gt; install keys now
                             -- 
                             -- FALSE -&gt; require set-keys-commit
                             --          before issuing tickets
                             --          encrypted with these keys.
                             -- 
                             -- See commit-keys op
     isupport         [3] KerberosVSupportNego OPTIONAL
                             -- For future Kerberos V extensions KDCs
                             -- may need to know what krb5 version is
                             -- supported by individual service
                             -- principals.  This field provides a
                             -- way to tell the KDC what version of
                             -- Kerberos V the target principal
                             -- supports.
}

Rep-gen-keys        ::= SEQUENCE {
     info-text        [0] UTF8String OPTIONAL,
     kvno             [1] UInt32,
     key              [2] Key,
     aliases          [3] SEQUENCE OF SEQUENCE {
             name          [0] PrincipalName,
             realm         [1] Realm OPTIONAL
     },
     isupport         [4] KerberosVSupportNego OPTIONAL
     -- Should there be ETYPE-INFO2 stuff here?
}

Err-gen-keys        ::= Err-set-keys

-- Get un-committed key request
Req-get-keys        ::= SEQUENCE {
     kvno             [0] UInt32
}

Rep-get-keys        ::= SEQUENCE {
     info-text        [0] UTF8String OPTIONAL,
     keys             [1] SEQUENCE OF Key,
     aliases          [2] SEQUENCE OF SEQUENCE {
             name          [0] PrincipalName,
             realm         [1] Realm OPTIONAL
     },
     isupport         [3] KerberosVSupportNego OPTIONAL
     -- Should there be ETYPE-INFO2 stuff here?
}

Err-get-keys      ::= SEQUENCE {
     help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
     error          [1] CHOICE {
             op-generic         [0] Extensible-NULL,
             op-kvno-committed  [1] Extensible-NULL,
             op-no-such-kvno    [1] Extensible-NULL
     }
}

-- Commit a set keys request
Req-commit-keys ::= SEQUENCE {
     kvno         [0] UInt32
}

Rep-commit-keys ::= Extensible-NULL

Err-commit-keys ::= SEQUENCE {
     help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
     error        [1] CHOICE {
             op-generic           [0] Extensible-NULL,
             op-kvno-expired      [1] Extensible-NULL,
                 -- The client took too long to respond.
             op-kvno-unknown      [2] Extensible-NULL,
                 -- The targ princ/kvno is invalid or unknown to the
                 -- server (perhaps it lost track of state)
             op-new-keys-conflict [3] Extensible-NULL
                 -- A new-keys/commit-keys request subsequent to the
                 -- new-keys that produced the kvno has completed
                 -- and incremented the principal&#39;s kvno
     }
}

-- Get password policy
Req-get-pw-policy   ::= Extensible-NULL

Rep-get-pw-policy   ::= SEQUENCE {
     policy-name      [0] UTF8String OPTIONAL,
     description      [1] SEQUENCE OF UTF8String OPTIONAL
}

Err-get-pw-policy   ::= Extensible-NULL

-- Get principal aliases
Req-get-princ-aliases        ::= Extensible-NULL

Rep-get-princ-aliases        ::= SEQUENCE {
     help-text    [0] UTF8String OPTIONAL,
     aliases      [1] SEQUENCE OF SEQUENCE {
             name      [0] PrincipalName,
             realm     [1] Realm OPTIONAL
     }
}

Err-get-princ-aliases        ::= Extensible-NULL

-- Get list of enctypes supported by KDC for new keys
Req-get-realm-krb5-support   ::= Extensible-NULL

Rep-get-realm-krb5-support   ::= SEQUENCE {
     isupport        [0] KerberosVSupportNego
                             -- Version of Kerberos V supported by
                             -- the target realm.
}

Err-get-realm-krb5-support   ::= Extensible-NULL

-- Get s2kparams
Req-get-s2kparams            ::= Extensible-NULL

Rep-get-s2kparams            ::= SEQUENCE {
     help-text       [0] UTF8String OPTIONAL,
     s2kparams       [1] SEQUENCE OF Etype-Info-Entry
}

Err-get-s2kparams            ::= Extensible-NULL

END
   '>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc tocindent="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

<rfc ipr="full3978" docName="draft-ietf-krb-wg-kerberos-set-passwd-06.txt">
    <front>
	<title abbrev="Kerberos Set/Change Password v2">Kerberos
	    Set/Change Key/Password Protocol Version 2</title>
	<author initials='N.' surname="Williams" fullname='Nicolas
	    Williams'>
	    <organization abbrev="Sun">Sun Microsystems</organization>
	    <address>
		<postal>
		    <street>5300 Riata Trace Ct</street>
		    <city>Austin</city> <region>TX</region>
		    <code>78727</code> <country>US</country>
		</postal>
		<email>[email-masked]</email>
	    </address>
        </author>
        <date month="March" year="2007"/>
	<area>Security</area>
	<workgroup>NETWORK WORKING GROUP</workgroup>
	<keyword>Internet-Draft</keyword>
	<abstract>
	    <t>This document specifies an extensible protocol for
		setting keys and changing the passwords of Kerberos V
		principals.</t>
	</abstract>
    </front>

    <middle>
	<section title="Conventions used in this document">
            <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
            and "OPTIONAL" in this document are to be interpreted as
            described in <xref target="RFC2119"/>.</t>
        </section>
        <section title="Introduction">
	    <t>Up to this point Kerberos V has lacked a single, standard protocol
		for changing passwords and keys.  While several vendor-specific
		protocols exist for changing Kerberos passwords/keys, none are
		properly internationalized and all are incomplete in one respect or
		another and none are sufficiently extensible to cope with new
		features that may be added to Kerberos V at some future time.</t>
	    <t>This document defines a protocol that is somewhat backward-compatible
		with the "kpasswd" protocol defined in <xref
		    target="RFC3244"/> that uses more or
		less the same protocol framing.</t>
	    <t>This new protocol is designed to be extensible and properly
		internationalized.</t>
        </section>

	<section title="The Protocol">
	    <t>The structure of the protocol is quite similar to that of
		typical RPC protocols.  Each transaction consists of a
		data structure specific to an operation which is then
		wrapped in a data structure which is general to all
		operations of the protocol.  These data structures are
		defined with the Abstract Syntax Notation 1 (ASN.1)
		<xref target="CCITT.X680.2002"/> and they are encoded
		using the Distinguished Encoding Rules (DER) <xref
		    target="CCITT.X690.2002"/>.</t>
	    <t>All protocol data is wrapped KRB-PRIV messages, or, in
		some cases, a KRB-ERROR, and framed in a header that is
		backwards compatible with <xref target="RFC3244"/>.</t>

	    <section title="Transports ">

		<t>The service supports only connection-oriented
		    transports, specifically TCP, and SHOULD accept
		    requests on TCP port 464, the same as in <xref
			target="RFC3244"/>.</t>

		<section anchor="protocol_framing" title="Protocol Framing">

		    <t>Requests and responses are exchanged using the
			same framing as in <xref target="RFC3244"/>, but
			with the following differences:

			<list style='symbols'>
			    <t>the protocol number field MUST be set to
				0x2 (not 0xff80 or 0x1)</t>

			    <t>the 'AP-REQ length' field of the request
				can be set to 0x0, in which case the
				'AP-REQ' field of the request is
				excluded</t>

			    <t>the 'KRB-PRIV' field of the request and
				reply is mutually
				exclusive with the 'AP-REQ' field of the
				request</t>

			    <t>the 'AP-REP length' field of the reply
				can be set to 0x0, in which case the
				'AP-REP' field of the reply is
				excluded</t>

			    <t>all errors MUST be sent in a KRB-PRIV if
				the client's AP-REQ can
				be or has been accepted by the
				server</t>

			    <t>any KRB-ERROR messages are framed and
				sent in the 'AP-REP' field of the
				reply</t>
			</list>
		    </t>

		    <t>The initial message from the client MUST carry an
			AP-REQ and the response to any request bearing
			an AP-REQ MUST carry an AP-REP or MUST be a
			KRB-ERROR.</t>
		    <t>Subsequent messages exchanged on the same TCP
			connection MAY involve Kerberos V AP exchanges,
			but generally the client SHOULD NOT initiate a
			new AP exchange except when it desires to
			authenticate as a different principal, when the
			ticket last used for authentication expires or
			when the server responds with an error
			indicating that the client must
			re-authenticate.</t>

		</section>
	    </section>
	    <section title="Protocol Version Negotiation">

		<t>There are several major versions of this protocol.  Version 2 also
		    introduces a notion of protocol minor versions for use in negotiating
		    protocol extensions.  As of this time only one minor version is
		    defined for major version 2: minor version 0, defined herein.</t>

		<section title="Protocol Major Version Negotiation">

		    <t>Version 2 clients that also support other versions, such as 0xff80,
			as in <xref target="RFC3244"/>, SHOULD attempt to use version 2 of the protocol
			first.</t>

		    <t>Servers which do not support version 2 of this protocol typically
			include their preferred version number in the reply and/or may
			include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
			status code of KRB5_KPASSWD_MALFORMED.</t>

		    <t>Note that some <xref target="RFC3244"/> server implementations close the TCP
			connection without returning any other response.  Note also that
			there is no integrity protection for the major version number in the
			protocol framing or for any data in a KRB-ERROR.</t>

		    <t>As a result change password protocol major version negotiation is
			subject to downgrade attacks.  Therefore major version negotiation is
			NOT RECOMMENDED.</t>

		    <t>Where the server indicates that it does not support version 2, the
			client MAY, but SHOULD NOT, unless configured to do so, fall back on
			another major version of this protocol.</t>

		    <t>Version 2 servers MAY respond to non-v2 requests using whatever
			response is appropriate for the versions used by the clients, but if
			a server does not do this or know how to do this then it MUST respond
			with an error framed as in <xref
			    target="protocol_framing"/>, using an AP-REP and KRB-PRIV
			if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
			using a ProtocolErrorCode value of unsupported-major-version.</t>

		    <t>It is expected that implementations of as yet unspecified future
			major versions of this protocol will be required to support version 2
			integrity protected error replies for properly indicating no support
			for version 2 of the protocl.  We also hope that no further major
			versions of this protocol will be needed.</t>

		</section>

		<section anchor="minor_version_nego" title="Protocol Minor Version Negotiation">

		    <t>Version 2 clients are free to use whatever protocol minor version and
			message extensions are available to them in their initial messages to
			version 2 servers, provided that the minor versions (other than 0)
			have been defined through IETF documents.</t>

		    <t>Version 2 servers MUST answer with the highest protocol minor version
			number supported by the server and the client.</t>

		    <t>Version 2 clients MUST use the protocol minor version used in a
			server's reply for any subsequent messages in the same TCP
			session.</t>

		    <t>See <xref target="protocol_extensibility"/> for further description of the protocol's
			extensibility and its relation to protocol minor versions and the
			negotiation thereof.</t>
		</section>
	    </section>
	    <section anchor="use_of_krb5" title="Use of Kerberos V and Key Exchange">

		<t>This protocol makes use of messages defined in <xref
			target="RFC4120"/>.  Specifically, AP-REQ,
		    AP-REP, KRB-ERROR and KRB-PRIV.</t>

		<t>All operations are to be performed by the server on behalf of the
		    client principal.</t>

		<t>Clients SHOULD use "kadmin/setpw" as the principal name of the server
		    for all requests except when changing the client principal's own
		    expired password, for which they should use "kadmin/changepw".  The 
		    "kadmin/changepw" service exists to allow KDCs to limit principals
		    with expired passwords to getting initial tickets to the password
		    changing service only and only for changing expired passwords.</t>

		<t>Servers MUST limit clients that used the "kadmin/changepw" service
		    principal name to changing the password of the client
		    principal.</t>

		<t>The client MUST request mutual authentication and the client MUST
		    MUST request the use of sequence numbers.</t>

		<t>Servers MAY force the use of INITIAL or fresh tickets
		    for any requests -- see <xref target="operations"/>.
		    Traditionally users with expired passwords are
		    allowed only INITIAL tickets for the password
		    changing server, therefore clients MUST support the
		    use of INITIAL tickets.</t>

		<t>Servers MUST specify a sub-session key.</t>

		<t>The encrypted part of KRB-PRIVs MUST be encrypted with the server's
		    sub-session key and key usage 20 (client->server) or 21
		    (server->client).</t>

		<t>After each new AP exchange the client and server MUST destroy the
		    session keys, if any, resulting from the previous AP
		    exchange.</t>
	    </section>

	    <section title="Use of ASN.1">
		<t>This protocol's messages are defined in ASN.1, using
		    only features from <xref target="CCITT.X680.2002"/>.
		    All ASN.1 types defined herein are to be encoded in
		    DER <xref target="CCITT.X690.2002"/>.  A complete
		    ASN.1 module is given in <xref
			target="asn1_module"/>.</t>
		<t>The DER encoding of the ASN.1 PDUs are exchanged
		    wrapped in a KRB-PRIV as described above and/or as
		    e-data in KRB-ERROR messages.</t>
	    </section>

	    <section title="Internationalization">

		<t>This protocol's request PDU carries an optional field indicating the
		    languages spoken by the client user; the client SHOULD send its list
		    of spoken languages to the server (once per-TCP session).</t>

		<t>The server SHOULD localize all strings intended for display to users
		    to a language in common with the languages spoken by the client
		    user.</t>

		<t>Strings for Kerberos principal and realm names used in this protocol
		    are be constrained as per <xref target="RFC4120"/>.</t>

		<section title="Normalization Forms for UTF-8 Strings">

		    <t>Because Kerberos V <xref target="RFC4120"/> restricts principal names, realm
			names and passwords to IA5String, this protocol uses UTF8String with
			an extensible constraint to IA5String.</t>

		    <t>Future versions of Kerberos may relax this constraint; if so then a
			minor version of this protocol should relax this constraint
			accordingly.</t>

		</section>
		<section title="Language Negotiation">
		    <t>The server MUST pick a language from the client's
			input list or the default language tag (see
			<xref target="RFC3066"/>) for text in its
			responses which is meant for the user to
			read.</t>
		    <t>The server SHOULD use a language selection
			algorithm such that consideration is first given
			to exact matches between the client's spoken
			languages and the server's available locales,
			followed by "fuzzy" matches where only the first
			sub-tags of the client's language tag list are
			used for matching against the servers available
			locales.</t>
		    <t>Servers MUST cache the optional language tag
			lists from prior requests for use with
			subsequent requests that exclude the language
			tag list.  Clients MAY expect such server
			behaviour and send the language tag lists only
			once per-TCP session.  Clients SHOULD send the
			server the language tag list at least once.</t>
		    <t>When the server has a message catalog for one of
			the client's spoken languages the server SHOULD
			localize any text strings intended for display
			to users.</t>
		</section>
	    </section>

	    <section anchor="protocol_extensibility" title="Protocol Extensibility">
		<t>The protocol is defined in ASN.1 and uses extensibility markers
		    throughout.  As such, the module presented herein can be extended
		    within the framework of <xref target="CCITT.X680.2002"/>.</t>
		<t>Typed holes are not used in this protocol as it is very simple and
		    does not require the ability to deal with abstract data types defined
		    in different layers.  For this reason, the only way to extend this
		    protocol is by extending the ASN.1 module within the framework of the
		    IETF; all future extensions to this protocol have to be defined in
		    IETF documents unless otherwise specified in a future IETF revision
		    of this protocol.</t>
		<t>A protocol minor version number is used to negotiate
		    use of extensions.  See <xref
			target="minor_version_nego"/> for the minor
		    version negotiation.</t>
		<t>Servers SHOULD ignore unknown additions to the ASN.1 types, in
		    initial requests, where the syntax allows them, except for extensions
		    to the "Op-req" type, which MUST result in an error.</t>
		<t>Servers MUST respond with an error (ProtocolErrorCode value of
		    proto-unsupported-operation) to clients that use
		    operations unknown to the server.</t>
	    </section>

	    <section title="Protocol Subsets">
		<t>The structure of the protocol is such that the ASN.1 syntaxes for the
		    various operations supported by the protocol are independent of the
		    each other.  Client and server implementations MAY implement subsets
		    of the overall protocol by removing some alternatives to the Op-req,
		    Op-rep and Op-err CHOICEs from the ASN.1 module
		    given in <xref target="asn1_module"/>.</t>
		<t>For example, it should be possible to have a password-change only
		    client that cannot set principal's keys - and vice versa.</t>
	    </section>
	</section>

	<section title="Protocol Elements">

	    <t>The protocol as defined herein supports the following operations
		relating to the management of Kerberos principal's passwords or
		keys:

		<list style='symbols'>
		    <t>change password (or enctypes and string-to-key parameters)</t>
		    <t>set password (administrative)</t>
		    <t>set new keys</t>
		    <t>generate new keys</t>
		    <t>get new, un-committed keys</t>
		    <t>commit new keys</t>
		    <t>get password policy name and/or description of principal</t>
		    <t>list aliases of a principal</t>
		    <t>list enctypes and version of Kerberos V supported by realm</t>
		</list>
	    </t>

	    <t>The operation for retrieving a list of aliases of a principal is
		needed where KDCs implement aliasing of principal names and allows
		clients to properly setup their key databases when principal aliasing
		is in use.</t>

	    <t>Operations such as creation or deletion of principals are outside the
		scope of this document, and should be performed via other means, such
		as through directories or other Kerberos administration
		protocols.</t>

	    <t>The individual operations are described in <xref
		    target="operations"/>.</t>

	    <section title="Password Quality Policies">
		<t>Servers may reject new user passwords for failing to
		    meet password quality policies.  When this happens
		    the server must be able to communicate the policy to
		    the user so that the user may select a better
		    password.</t>
		<t>The protocol allows for two ways to do
		    this:
		    <list style='symbols'>
			<t>through error codes that identify specific
			    password quality policies known;</t>
			<t>through localized error strings.</t>
		    </list>
		</t>
		<t>The use of localized error strings allows servers to
		    convey non-standard password quality policies to
		    users, but it requires server-side message catalogs
		    for localization and support for language
		    negotiation.  The use of error codes only allows for
		    standard password quality policies that clients must
		    be aware of a priori, therefore use of error codes
		    requires the distribution of new message catalogs to
		    clients whenever new error codes are added; this
		    simplifies servers at the expense of password
		    quality extensibility.</t>
		<t>When a server would reject a password due to its
		    failing to meet a standard password quality policy
		    the the server MUST use the appropriate error codes
		    (see below) and the server SHOULD send a localized
		    error message to the user.</t>
		<t>When a server would reject a password due to its
		    failing to meet a non-standard password quality
		    policy (one not described herein) the the server
		    MUST send a localized error message to the user.</t>
		<section title="Standard Password Quality Policies">
		    <t>
			<list style='symbols'>
			    <t>pwq-too-soon
				<vspace blankLines='1'/>
				It is too soon for the principal to
				change its password or long-term keys.
				<vspace blankLines='1'/></t>
			    <t>pwq-history
				<vspace blankLines='1'/>
				The new password is one that the
				principal has used before or is too
				similar to a password that it has used
				before.
				<vspace blankLines='1'/></t>
			    <t>pwq-too-short
				<vspace blankLines='1'/>
				The new password is too short.
				<vspace blankLines='1'/></t>
			    <t>pwq-dictionary-words
				<vspace blankLines='1'/>
				The new password is or contains words
				that are in the dictionary.
				<vspace blankLines='1'/></t>
			    <t>pwq-prohibited-codepoints
				<vspace blankLines='1'/>
				The new password contains prohibited
				codepoints.
				<vspace blankLines='1'/></t>
			    <t>pwq-need-more-char-classes
				<vspace blankLines='1'/>
				The new password does not have
				characters from enough character classes
				(lower-case letters, upper-case letters,
				digits, punctuation, etc...).
				<vspace blankLines='1'/></t>
			</list>
		    </t>
		</section>
	    </section>

	    <section title="PDUs">
		<t>The types "Request," "Response" and "Error-Response" are the ASN.1
		    module's PDUs.</t>
		<t>The "Request" and "Response" PDUs are always to be
		    sent wrapped in KRB-PRIV messages, except for the
		    "Error-Response" PDU which MUST be sent as
		    KRB-ERROR e-data (see <xref
			target="use_of_krb5"/>) when AP exchanges
		    fail, otherwise it MUST be sent wrapped in a
		    KRB-PRIV.</t>
		<t>The ASN.1 syntax for the PDUs is given in <xref
			target="asn1_module"/>.</t>
		<t>Note that the first field of each PDU is the major version of the
		    protocol, defaulted to 2, meaning that it is never included in
		    version 2 exchanges.  Similarly, the second field of each PDU is the
		    minor version, defaulted to 0.</t>
		<t>The request, responses and error PDUs consist of an outer structure
		    ("Request," "Response" and "Error-Response") containing fields common
		    to all requests, responses and errors, respectively, and an inner
		    structure for fields that are specific to each operation's
		    requests/responses.  The inner structure is optional in the case of
		    the Error-Response PDU and need not be included when generic errors
		    occur for which there is a suitable ProtocolErrorCode.</t>
		<t>Specifically, the outer Request structure has a field for passing a
		    client user's spoken (read) languages to the server.  It also has two
		    optional fields for identifying the requested operation's target
		    principal's name and realm (if not sent then the server MUST use the
		    client's principal name and realm as the target).  A boolean field
		    for indicating whether or not the request should be dry-run is also
		    included; dry-runs can be used to test server policies, and servers
		    MUST NOT modify any principals when processing dry-run requests.</t>
		<t>The Response and Error PDUs' outer structures include a field
		    indicating the language that the server has chosen for localization
		    of text intended to be displayed to users; this field is defaulted to
		    "i-default".  This language tag applies to all UTF8 strings in the
		    inner structure (Op-rep and Op-err) that are meant to be displayed to
		    users.</t>
		<t>The protocol error codes are:
		    <list style='symbols'>
			<t>proto-generic-error
			    <vspace blankLines='1'/>
			    An operation-specific error ocurred, see the inner Op-error.</t>
			<t>proto-format-error
			    <vspace blankLines='1'/>
			    The server failed to parse a message sent by
			    the client.
			</t>
			<t>proto-unsupported-major-version
			    <vspace blankLines='1'/>
			    The server does not support the major
			    version of this protocol requested by the
			    client.
			</t>
			<t>proto-unsupported-minor-version
			    <vspace blankLines='1'/>
			    The server does not support the minor
			    version of this protocol requested by the
			    client.
			</t>
			<t>proto-unsupported-operation
			    <vspace blankLines='1'/>
			    The server does not support the operation
			    requested by the client.
			</t>
			<t>proto-wrong-service-principal
			    <vspace blankLines='1'/>
			    Use kadmin/setpw for the server's principal name.
			</t>
			<t>proto-re-authentication-required
			    <vspace blankLines='1'/>
			    The server demands that the client re-authenticate through a new
			    AP exchange.
			</t>
			<t>proto-initial-ticket-required
			    <vspace blankLines='1'/>
			    Use of an INITIAL ticket is required for the requested
			    operation.
			</t>
			<t>proto-client-and-target-realm-mismatch
			    <vspace blankLines='1'/>
			    The server requires that the client's principal name and the
			    target principal of the operation share the same realm name.</t>
			<t>proto-target-principal-unknown
			    <vspace blankLines='1'/>
			    The target of the client's operation is not
			    a valid principal.
			</t>
			<t>proto-authorization-failed
			    <vspace blankLines='1'/>
			    The client principal is not authorized to
			    perform the requested operation.
			</t>
			<t>proto-fresh-ticket-required
			    <vspace blankLines='1'/>
			    The server would like the client to
			    re-authenticate using a fresh ticket.
			</t>
		    </list>
		</t>
	    </section>
	    <section anchor="operations" title="Operations">
		<t>This section describes the semantics of each
		    operation request and response defined in the
		    ASN.1 module in <xref target="asn1_module"/>.</t>
		<section title="Null">
		    <figure>
			<artwork>
			    &null;
			</artwork>
		    </figure>
		</section>
		<section title="Change Kerberos Password">
		    <figure>
			<artwork>
			    &change-pw;
			</artwork>
		    </figure>
		</section>
		<section title="Set Kerberos Password">
		    <figure>
			<artwork>
			    &set-pw;
			</artwork>
		    </figure>
		</section>
		<section title="Set Kerberos Keys">
		    <figure>
			<artwork>
			    &set-keys;
			</artwork>
		    </figure>
		</section>
		<section title="Generate Kerberos Keys">
		    <figure>
			<artwork>
			    &gen-keys;
			</artwork>
		    </figure>
		</section>
		<section title="Get New Keys">
		    <figure>
			<artwork>
			    &get-keys;
			</artwork>
		    </figure>
		</section>
		<section title="Commit New Keys">
		    <figure>
			<artwork>
			    &commit-keys;
			</artwork>
		    </figure>
		</section>
		<section title="Get Password Quality Policy">
		    <figure>
			<artwork>
			    &get-pw-policy;
			</artwork>
		    </figure>
		</section>
		<section title="Get Principal Aliases">
		    <figure>
			<artwork>
			    &get-princ-aliases;
			</artwork>
		    </figure>
		</section>
		<section title="Get Realm&#39;s Supported Kerberos V Version and Features">
		    <figure>
			<artwork>
			    &get-realm-krb5-support;
			</artwork>
		    </figure>
		</section>
		<section title="Retrieve Principal&#39;s S2K Params and Preferred Params">
		    <figure>
			<artwork>
			    &get-s2kparams;
			</artwork>
		    </figure>
		</section>
	    </section>
	    <section title="Principal Aliases">
		<t>Applications that use Kerberos often have to derive acceptor
		    principal names from hostnames entered by users.  Such hostnames may
		    be aliases, they may be fully qualified, partially qualified or not
		    qualified at all.  Some implementations have resorted to deriving
		    principal names from such hostnames by utilizing the names services
		    to canonicalize the hostname first; such practices are not secure
		    unless the name service are secure, which often aren&#39;t.</t>
		<t>One method for securely deriving principal names from hostnames is to
		    alias principals at the KDC such that the KDC will issue tickets for
		    principal names which are aliases of others.  It is helpful for
		    principals to know what are their aliases as known by the KDCs.</t>
		<t>Note that changing a principal&#39;s aliases is out of scope for this
		    protocol.</t>
	    </section>
	    <section title="Kerberos V Feature Negotiation">
		<t>Principals and realms' KDCs may need to know about additional
		    Kerberos V features and extensions that they each support.  Several
		    operations (see above) provide a way for clients and servers to
		    exchange such infomration, in the form of lists of types supported
		    for the various typed holes used in Kerberos V.</t>
	    </section>
	</section>
	<section anchor="asn1_module" title="ASN.1 Module">
	    <figure>
		<artwork>
		    &asn1module;
		</artwork>
	    </figure>
	</section>
	<section title="Security Considerations">
	    <t>Implementors and site administrators should note that the
		redundancy of UTF-8 encodings of passwords varies by
		language.  Password quality policies SHOULD, therefore,
		take this into account when estimating the amount of
		redundancy and entropy in a proposed new password.</t>
	    <t>Kerberos set/change password/key protocol major version
		negotiation cannot be done securely; a downgrade attack
		is possible against clients that attempt to negotiate
		the protocol major version to use with a server.  It is
		not clear at this time that the attacker would gain much
		from such a downgrade attack other than denial of
		service (DoS) by forcing the client to use a protocol
		version which does not support some feature needed by
		the client (Kerberos V in general is subject to a
		variety of DoS attacks anyways <xref
		    target="RFC4120"/>).  Clients SHOULD NOT negotiate
		support for legacy major versions of this protocol
		unless configured otherwise.</t>
	    <t>This protocol does not have Perfect Forward Security
		(PFS).  As a result, any passive network snooper
		watching password/key changing operations who has stolen
		a principal's password or long-term keys can find out
		what the new ones are.</t>
	</section>
    </middle>

    <back>
        <references title="Normative References">
	    &rfc2119;&rfc3066;&rfc4120;&x680;&x690;
	</references>
        <references title="Informative References">
	    &rfc3244;
	</references>
    </back>

</rfc>

<!--
1  Introduction

   Up to this point Kerberos V has lacked a single, standard protocol
   for changing passwords and keys.  While several vendor-specific
   protocols exist for changing Kerberos passwords/keys, none are
   properly internationalized and all are incomplete in one respect or
   another and none are sufficiently extensible to cope with new
   features that may be added to Kerberos V at some future time.

   This document defines a protocol that is somewhat backward-compatible
   with the "kpasswd" protocol defined in [RFC3244] that uses more or
   less the same protocol framing.

   This new protocol is designed to be extensible and properly
   internationalized.

2  The Protocol

   The structure of the protocol is quite similar to that of typical RPC
   protocols.  Each transaction consists of a data structure specific to
   an operation which is then wrapped in a data structure which is
   general to all operations of the protocol.  These data structures are
   defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
   are encoded using the Distinguished Encoding Rules (DER) [X690].

   All protocol data is wrapped KRB-PRIV messages, or, in some cases, a
   KRB-ERROR, and framed in a header that is backwards compatible with
   [RFC3244].

2.1  Transports 

   The service supports only connection-oriented transports,
   specifically TCP, and MUST accept requests on TCP port 464, the same
   as in [RFC3244].

2.2  Protocol Framing

   Requests and responses are exchanged using the same framing as in
   [RFC3244], but with the following differences:

    - the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1)

    - the 'AP-REQ length' field of the request can be set to 0x0, in
      which case the 'AP-REQ' field of the request is excluded

    - the 'KRB-PRIV' field of the request and reply is mutually
      exclusive with the 'AP-REQ' field of the request

    - the 'AP-REP length' field of the reply can be set to 0x0, in
      which case the 'AP-REP' field of the reply is excluded

    - all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can
      be or has been accepted by the server

    - any KRB-ERROR messages are framed and sent in the 'AP-REP' field
      of the reply

   The initial message from the client MUST carry an AP-REQ and the
   response to any request bearing an AP-REQ MUST carry an AP-REP or
   MUST be a KRB-ERROR.

   Subsequent messages exchanged on the same TCP connection MAY involve
   Kerberos V AP exchanges, but generally the client SHOULD NOT initiate
   a new AP exchange except when it desires to authenticate as a
   different principal, when the ticket last used for authentication
   expires or when the server responds with an error indicating that the
   client must re-authenticate.

2.3  Protocol Version Negotiation

   There are several major versions of this protocol.  Version 2 also
   introduces a notion of protocol minor versions for use in negotiating
   protocol extensions.  As of this time only one minor version is
   defined for major version 2: minor version 0, defined herein.

2.3.1  Protocol Major Version Negotiation

   Version 2 clients that also support other versions, such as 0xff80,
   as in [RFC3244], SHOULD attempt to use version 2 of the protocol
   first.

   Servers which do not support version 2 of this protocol typically
   include their preferred version number in the reply and/or may
   include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a
   status code of KRB5_KPASSWD_MALFORMED.

   Note that some [RFC3244] server implementations close the TCP
   connection without returning any other response.  Note also that
   there is no integrity protection for the major version number in the
   protocol framing or for any data in a KRB-ERROR.

   As a result change password protocol major version negotiation is
   subject to downgrade attacks.  Therefore major version negotiation is
   NOT RECOMMENDED.

   Where the server indicates that it does not support version 2, the
   client MAY, but SHOULD NOT, unless configured to do so, fall back on
   another major version of this protocol.

   Version 2 servers MAY respond to non-v2 requests using whatever
   response is appropriate for the versions used by the clients, but if
   a server does not do this or know how to do this then it MUST respond
   with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
   if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise and
   using a ProtocolErrorCode value of unsupported-major-version.

   It is expected that implementations of as yet unspecified future
   major versions of this protocol will be required to support version 2
   integrity protected error replies for properly indicating no support
   for version 2 of the protocl.  We also hope that no further major
   versions of this protocol will be needed.

2.3.2  Protocol Minor Version Negotiation

   Version 2 clients are free to use whatever protocol minor version and
   message extensions are available to them in their initial messages to
   version 2 servers, provided that the minor versions (other than 0)
   have been defined through IETF documents.

   Version 2 servers MUST answer with the highest protocol minor version
   number supported by the server and the client.

   Version 2 clients MUST use the protocol minor version used in a
   server's reply for any subsequent messages in the same TCP session.
   See section 2.7 for further description of the protocol's
   extensibility and its relation to protocol minor versions and the
   negotiation thereof.

2.4  Use of Kerberos V and Key Exchange

   This protocol makes use of messages defined in [RFC1510] and
   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
   KRB-PRIV.

   All operations are to be performed by the server on behalf of the
   client principal.

   Clients SHOULD use "kadmin/setpw" as the principal name of the server
   for all requests except when changing the client principal's own
   expired password, for which they should use "kadmin/changepw".  The 
   "kadmin/changepw" service exists to allow KDCs to limit principals
   with expired passwords to getting initial tickets to the password
   changing service only and only for changing expired passwords.

   Servers MUST limit clients that used the "kadmin/changepw" service
   principal name to changing the password of the client principal.

   The client MUST request mutual authentication and the client MUST
   MUST request the use of sequence numbers.

   Clients SHOULD use INITIAL tickets for requests whose target
   principal is the client's principal.  Servers SHOULD force the use of
   INITIAL tickets for such requests and MAY force the use of INITIAL
   for all others - see section 3.2.

   Servers MUST specify a sub-session key.

   The encrypted part of KRB-PRIVs MUST be encrypted with the server's
   sub-session key and key usage 20 (client->server) or 21
   (server->client).

   After each new AP exchange the client and server MUST destroy the
   session keys, if any, resulting from the previous AP exchange.

2.5  Use of ASN.1

   This protocol's messages are defined in ASN.1, using only features
   from [X680].  All ASN.1 types defined herein are to be encoded in
   DER [X690].  A complete ASN.1 module is given in section 4.

   The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
   KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.

2.6  Internationalization

   This protocol's request PDU carries an optional field indicating the
   languages spoken by the client user; the client SHOULD send its list
   of spoken languages to the server (once per-TCP session).

   The server SHOULD localize all strings intended for display to users
   to a language in common with the languages spoken by the client user.

   Strings for Kerberos principal and realm names used in this protocol
   are be constrained as per [clarifications].

2.6.1  Normalization Forms for UTF-8 Strings

   Because Kerberos V [clarifications] restricts principal names, realm
   names and passwords to IA5String, this protocol uses UTF8String with
   an extensible constraint to IA5String.

   Future versions of Kerberos may relax this constraint; if so then a
   minor version of this protocol should relax this constraint
   accordingly.

2.6.2  Language Negotiation

   The server MUST pick a language from the client's input list or
   the default language tag (see [RFC3066]) for text in its responses
   which is meant for the user to read.

   The server SHOULD use a language selection algorithm such that
   consideration is first given to exact matches between the client's
   spoken languages and the server's available locales, followed by
   "fuzzy" matches where only the first sub-tags of the client's
   language tag list are used for matching against the servers available
   locales.

   Servers MUST cache the optional language tag lists from prior
   requests for use with subsequent requests that exclude the language
   tag list.  Clients MAY expect such server behaviour and send the
   language tag lists only once per-TCP session.  Clients SHOULD send
   the server the language tag list at least once.

   When the server has a message catalog for one of the client's spoken
   languages the server SHOULD localize any text strings intended for
   display to users.

2.7  Protocol Extensibility

   The protocol is defined in ASN.1 and uses extensibility markers
   throughout.  As such, the module presented herein can be extended
   within the framework of [X680].

   Typed holes are not used in this protocol as it is very simple and
   does not require the ability to deal with abstract data types defined
   in different layers.  For this reason, the only way to extend this
   protocol is by extending the ASN.1 module within the framework of the
   IETF; all future extensions to this protocol have to be defined in
   IETF documents unless otherwise specified in a future IETF revision
   of this protocol.

   A protocol minor version number is used to negotiate use of
   extensions.  See section 2.3.2 for the minor version negotiation.

   Servers SHOULD ignore unknown additions to the ASN.1 types, in
   initial requests, where the syntax allows them, except for extensions
   to the "Op-req" type, which MUST result in an error.

   Servers MUST respond with an error (ProtocolErrorCode value of
   unsupported-minor-version) to clients that use operations unknown to
   the server.

2.8  Protocol Subsets

   The structure of the protocol is such that the ASN.1 syntaxes for the
   various operations supported by the protocol are independent of the
   each other.  Client and server implementations MAY implement subsets
   of the overall protocol by removing some alternatives to the Op-req,
   Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
   
   For example, it should be possible to have a password-change only
   client that cannot set principal's keys - and vice versa.

3  Protocol Elements

   The protocol as defined herein supports the following operations
   relating to the management of Kerberos principal's passwords or keys:

     [NOTE:  New since last version of this I-D.]
     - get principal's current and preferred string-to-key parameters

     - change password (or enctypes and string-to-key parameters)
     - set password (administrative)
     - set new keys
     - generate new keys
     - get new, un-committed keys
     - commit new keys
     - get password policy name and/or description of principal
     - list aliases of a principal
     - list enctypes and version of Kerberos V supported by realm

   The operation for retrieving a list of aliases of a principal is
   needed where KDCs implement aliasing of principal names and allows
   clients to properly setup their key databases when principal aliasing
   is in use.

   Operations such as creation or deletion of principals are outside the
   scope of this document, and should be performed via other means, such
   as through directories or other Kerberos administration protocols.

   The individual operations are described in section 3.2.

3.1  PDUs

   The types "Request," "Response" and "Error-Response" are the ASN.1
   module's PDUs.

   The "Request" and "Response" PDUs are always to be sent wrapped in
   KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
   sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
   otherwise it MUST be sent wrapped in a KRB-PRIV.

   The ASN.1 syntax for the PDUs is given in section 4.

   Note that the first field of each PDU is the major version of the
   protocol, defaulted to 2, meaning that it is never included in
   version 2 exchanges.  Similarly, the second field of each PDU is the
   minor version, defaulted to 0.

   The request, responses and error PDUs consist of an outer structure
   ("Request," "Response" and "Error-Response") containing fields common
   to all requests, responses and errors, respectively, and an inner
   structure for fields that are specific to each operation's
   requests/responses.  The inner structure is optional in the case of
   the Error-Response PDU and need not be included when generic errors
   occur for which there is a suitable ProtocolErrorCode.

   Specifically, the outer Request structure has a field for passing a
   client user's spoken (read) languages to the server.  It also has two
   optional fields for identifying the requested operation's target
   principal's name and realm (if not sent then the server MUST use the
   client's principal name and realm as the target).  A boolean field
   for indicating whether or not the request should be dry-run is also
   included; dry-runs can be used to test server policies, and servers
   MUST NOT modify any principals when processing dry-run requests.

   The Response and Error PDUs' outer structures include a field
   indicating the language that the server has chosen for localization
   of text intended to be displayed to users; this field is defaulted to
   "i-default".  This language tag applies to all UTF8 strings in the
   inner structure (Op-rep and Op-err) that are meant to be displayed to
   users.

   The protocol error codes are:

      - proto-generic-error

        An operation-specific error ocurred, see the inner Op-error.

      - proto-format-error
      - proto-unsupported-major-version
      - proto-unsupported-minor-version
      - proto-unsupported-operation

N. Williams        						[Page 8]

DRAFT		Kerberos Set/Change Password v2		  Expires April 2006

      - proto-wrong-service-principal

        Use kadmin/setpw for the server's principal name.

      - proto-re-authentication-required

        The server demands that the client re-authenticate through a new
        AP exchange.

      - proto-initial-ticket-required

        Use of an INITIAL ticket is required for the requested
        operation.

      - proto-client-and-target-realm-mismatch

        The server requires that the client's principal name and the
        target principal of the operation share the same realm name.

      - proto-target-principal-unknown
      - proto-authorization-failed

3.2  Operations

   This section describes the semantics of each operation request and
   response defined in the ASN.1 module in section 4.

3.3  Principal Aliases

   Applications that use Kerberos often have to derive acceptor
   principal names from hostnames entered by users.  Such hostnames may
   be aliases, they may be fully qualified, partially qualified or not
   qualified at all.  Some implementations have resorted to deriving
   principal names from such hostnames by utilizing the names services
   to canonicalize the hostname first; such practices are not secure
   unless the name service are secure, which often aren&#39;t.
   
   One method for securely deriving principal names from hostnames is to
   alias principals at the KDC such that the KDC will issue tickets for
   principal names which are aliases of others.  It is helpful for
   principals to know what are their aliases as known by the KDCs.
   
   Note that changing a principal&#39;s aliases is out of scope for this
   protocol.

3.4  Kerberos V Feature Negotiation

   Principals and realms' KDCs may need to know about additional
   Kerberos V features and extensions that they each support.  Several
   operations (see above) provide a way for clients and servers to
   exchange such infomration, in the form of lists of types supported
   for the various typed holes used in Kerberos V.

4  ASN.1 Module

   DEFINITIONS EXPLICIT TAGS ::= BEGIN
   -- 
   -- Note:  EXPLICIT tagging is in use by default throughout this
   --        module.

   -- From [clarifications] with modifications
   PrincipalName            ::= SEQUENCE {
        name-string [1] SEQUENCE OF UTF8String (IA5String, ...)
   }
   Realm                    ::= UTF8String (IA5String, ...)
   Salt                     ::= UTF8String (IA5String, ...)
   Password                 ::= UTF8String (IA5String, ...)

   -- NOTE WELL: Principal and realm names MUST be constrained by the
   --            specification of the version of Kerberos V used by the
   --            client.

   -- 
   -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
   --  type and a UTF8String, for simplicity.]

   -- From [clarifications]
   Int32            ::= INTEGER (-2147483648..2147483647)
   UInt32           ::= INTEGER (0..4294967295)

   -- Based on [clarifications]
   Etype            ::= Int32
   Etype-Info-Entry ::= SEQUENCE {
        etype           [0] Etype,
        salt            [1] Salt OPTIONAL,
        s2kparams       [2] OCTET STRING OPTIONAL
   }
   Key              ::= SEQUENCE {
        enc-type        [0] Etype,        -- from Kerberos
        key             [1] OCTET STRING
   }

   Language-Tag     ::= UTF8String -- Constrained by [RFC3066]

   -- Empty, extensible SEQUENCEs are legal ASN.1
   Extensible-NULL  ::= SEQUENCE {
        ...
   }

   -- Kerberos clients negotiate some parameters relating to their peers
   -- indirectly through the KDC.  Today this is true of ticket session
   -- key enctypes, but in the future this indirect negotiation may also
   -- occur with respect to the minor version of Kerberos V to be used
   -- between clients and servers.  Additionally, KDCs may need to know
   -- what authorization-data types are supported by service principals,
   -- both, for compatibility with legacy software and for optimization.
   --
   -- Thesefore it is important for KDCs to know what features of
   -- Kerberos V each service principal supports.
   --
   -- In version 2.0 of this protocol the clients and servers may notify
   -- each other of their support for:
   --
   --  - enctypes
   --  - authorization data types
   --  - transited encoding data types
   --
   -- All authorization-data types defined in [clarifications] are
   -- assumed to be supported if the minor version is 1 and do not need
   -- to be included in the ad-type list.
   --
   -- Int32 is used for enctype and transited encoding data type
   -- identifiers.

   --
   -- An extensible CHOICE of Int32 is used for authorization data
   -- types.

   KerberosV-TR-ID             ::= Int32

   KerberosV-AD-ID             ::= CHOICE {
        ad-int                [0] Int32,
        ...
   }

   KerberosVSupportNego        ::= SEQUENCE {
        enc-types       [0] SEQUENCE OF Etype,
        ad-types        [1] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
                                    -- authorization data types
        tr-enc-types    [2] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
                                    -- transited encoding types
        ...
   }

   Request                     ::= [APPLICATION 0] SEQUENCE {
        pvno-minor      [0] INTEGER DEFAULT 0,
        languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
                -- Should be defaulted to the SEQUENCE of "i-default"
        targ-name       [2] PrincipalName OPTIONAL,
        targ-realm      [3] Realm OPTIONAL,
                -- If targ-name/realm are missing then the request
                -- applies to the principal of the client
        dry-run         [4] BOOLEAN DEFAULT FALSE,
        operation       [5] Op-req,
        ...
   }

   Response                    ::= [APPLICATION 1] SEQUENCE {
        pvno-minor      [0] INTEGER DEFAULT 0,
        language        [1] Language-Tag DEFAULT "i-default",
        result          [2] Op-rep,
        ...
   }

   Error-Response              ::= [APPLICATION 2] SEQUENCE {
        pvno-minor      [0] INTEGER DEFAULT 0,
        language        [1] Language-Tag DEFAULT "i-default",
        error-code      [2] ProtocolErrorCode,
        help-text       [3] UTF8String OPTIONAL,
        op-error        [4] Op-err OPTIONAL,
        ...
   }

   Op-req                      ::= CHOICE {
        null                     [0] Req-null,
        change-pw                [1] Req-change-pw,
        set-pw                   [2] Req-set-pw,
        set-keys                 [3] Req-set-keys,
        gen-keys                 [4] Req-gen-keys,
        get-keys                 [5] Req-get-keys,
        commit-keys              [6] Req-commit-keys,
        get-pw-policy            [7] Req-get-pw-policy,
        get-princ-aliases        [8] Req-get-princ-aliases,
        get-realm-krb5-support   [9] Req-get-realm-krb5-support,
        get-s2kparams            [10] Req-get-s2kparams,
        ...
   }

   Op-rep                     ::= CHOICE {
        null                    [0] Rep-null,
        change-pw               [1] Rep-change-pw,
        set-pw                  [2] Rep-set-pw,
        set-keys                [3] Rep-set-keys,
        gen-keys                [4] Req-gen-keys,
        get-keys                [5] Req-get-keys,
        commit-keys             [6] Rep-commit-keys,
        get-pw-policy           [7] Rep-get-pw-policy,
        get-princ-aliases       [8] Rep-get-princ-aliases,
        get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
        get-s2kparams           [10] Rep-get-s2kparams,
        ...
   }

   Op-err        ::= CHOICE {
        null                    [0] Err-null,
        change-pw               [1] Err-change-pw,
        set-pw                  [2] Err-set-pw,
        set-keys                [3] Err-set-keys,
        gen-keys                [4] Err-gen-keys,
        get-keys                [5] Err-get-keys,
        commit-keys             [6] Err-commit-keys,
        get-pw-policy           [7] Err-get-pw-policy,
        get-princ-aliases       [8] Err-get-princ-aliases,
        get-realm-krb5-support  [9] Err-get-realm-krb5-support,
        get-s2kparams           [10] Err-get-s2kparams,
        ...
   }

   ProtocolErrorCode           ::= ENUM {
        proto-format-error,
        proto-unsupported-major-version,
        proto-unsupported-minor-version,
        proto-unsupported-operation,      -- Request CHOICE tag unknown
        proto-generic-see-op-error,       -- See Op-error
        proto-wrong-service-principal,    -- Use kadmin/setpw
        proto-re-authentication-required,
        proto-initial-ticket-required,
        proto-client-and-target-realm-mismatch,
        proto-target-principal-unknown,
        proto-authorization-failed,
        proto-dry-run-not-permitted,
        proto-fresh-ticket-required,
        ...
   }

   -- These codes are hints for clients, primarily for when they are
   -- used for changing the passwords of automated principals; error
   -- replies carry password quality policy help text that is more
   -- appropriate for clients to display to users.
   PW-Quality-Codes        ::= ENUM {
        pwq-generic,
        pwq-too-soon,
        pwq-history,
        pwq-too-short,
        pwq-dictionary-words,
        pwq-prohibited-codepoints,
        pwq-need-more-char-classes,
        ...
   }

   --
   -- Requests and responses
   --

   -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
   Req-null    ::= NULL

   Rep-null    ::= NULL

   Err-null    ::= NULL

   -- Change password
   Req-change-pw        ::= SEQUENCE {
        old-pw            [0] Password,
        new-pw            [1] Password OPTIONAL,
        commit            [2] BOOLEAN DEFAULT TRUE,
        etypes            [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
   }

   Rep-change-pw        ::= SEQUENCE {
        info-text         [0] UTF8String OPTIONAL,
        new-pw            [1] Password OPTIONAL,
                            -- generated by the server if present
                            -- (and requested by the client)
        etypes            [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
   }

   Err-change-pw        ::= SEQUENCE {
        help-text         [0] UTF8String OPTIONAL,
        error             [1] CHOICE {
            op-generic-error           [0] Extensible-NULL,
            op-old-pw-incorrect        [1] Extensible-NULL,
            op-wont-generate-new-pw    [2] Extensible-NULL,
            op-new-pw-rejected-generic [3] SEQUENCE {
                    policy                  [1] SEQUENCE OF UTF8String,
                    suggested-pw            [2] Password OPTIONAL,
                    policy-codes            [3] SET OF PW-Quality-Codes
                                                    OPTIONAL
            }
            op-etype-not-supported     [4] SEQUENCE {
                    supported-etypes   [1] SEQUENCE OF Etype
            }
        }
   }

   -- Set password
   Req-set-pw        ::= SEQUENCE {
        languages        [0] SEQUENCE OF Language-Tag OPTIONAL,
        new-pw                [1] Password OPTIONAL,
        commit                [2] BOOLEAN DEFAULT TRUE,
        etypes                [3] SEQUENCE (1..MAX) OF Etype OPTIONAL
   }

   Rep-set-pw        ::= SEQUENCE {
        info-text        [0] UTF8String OPTIONAL,
        new-pw                [1] Password OPTIONAL,
                                -- generated by the server if present
                                -- (and requested by the client)
        etypes                [2] SEQUENCE (1..MAX) OF Etype OPTIONAL
   }

   Err-set-pw        ::= Err-change-pw

   -- Set keys
   Req-set-keys      ::= SEQUENCE {
        keys            [0] SEQUENCE OF Key,
        commit          [1] BOOLEAN DEFAULT TRUE,
                                -- TRUE  -&gt; install keys now
                                -- 
                                -- FALSE -&gt; require set-keys-commit
                                --          before issuing tickets
                                --          encrypted with these keys.
                                -- 
                                -- See commit-keys op
        isupport        [2] KerberosVSupportNego OPTIONAL
                                -- For future Kerberos V extensions KDCs
                                -- may need to know what krb5 version is
                                -- supported by individual service
                                -- principals.  This field provides a
                                -- way to tell the KDC what version of
                                -- Kerberos V the target principal
                                -- supports.
   }

   Rep-set-keys        ::= SEQUENCE {
        info-text        [0] UTF8String OPTIONAL,
        kvno             [1] UInt32,
        aliases          [2] SEQUENCE OF SEQUENCE {
                name     [0] PrincipalName,
                realm    [1] Realm OPTIONAL
        },
        isupport         [3] KerberosVSupportNego OPTIONAL
        -- Should there be ETYPE-INFO2 stuff here?
   }

   Err-set-keys        ::= SEQUENCE {
        help-text     [0] UTF8String OPTIONAL, -- Reason for rejection
        error         [1] CHOICE {
                op-generic                    [0] Extensible-NULL,
                op-deferred-commit-no-support [1] Extensible-NULL,
                op-etype-no-support           [2] SEQUENCE OF {
                        supported-etypes      [1] SEQUENCE OF Etype
                }
        }
   }

   -- Generate keys
   Req-gen-keys        ::= SEQUENCE {
        etypes           [0] SEQUENCE (1..MAX) OF Etype,
        entropy          [1] OCTET STRING OPTIONAL,
        commit           [2] BOOLEAN DEFAULT TRUE,
                                -- TRUE  -&gt; install keys now
                                -- 
                                -- FALSE -&gt; require set-keys-commit
                                --          before issuing tickets
                                --          encrypted with these keys.
                                -- 
                                -- See commit-keys op
        isupport         [3] KerberosVSupportNego OPTIONAL
                                -- For future Kerberos V extensions KDCs
                                -- may need to know what krb5 version is
                                -- supported by individual service
                                -- principals.  This field provides a
                                -- way to tell the KDC what version of
                                -- Kerberos V the target principal
                                -- supports.
   }

   Rep-gen-keys        ::= SEQUENCE {
        info-text        [0] UTF8String OPTIONAL,
        kvno             [1] UInt32,
        key              [2] Key,
        aliases          [3] SEQUENCE OF SEQUENCE {
                name          [0] PrincipalName,
                realm         [1] Realm OPTIONAL
        },
        isupport         [4] KerberosVSupportNego OPTIONAL
        -- Should there be ETYPE-INFO2 stuff here?
   }

   Err-gen-keys        ::= Err-set-keys

   -- Get un-committed key request
   Req-get-keys        ::= SEQUENCE {
        kvno             [0] UInt32
   }

   Rep-get-keys        ::= SEQUENCE {
        info-text        [0] UTF8String OPTIONAL,
        keys             [1] SEQUENCE OF Key,
        aliases          [2] SEQUENCE OF SEQUENCE {
                name          [0] PrincipalName,
                realm         [1] Realm OPTIONAL
        },
        isupport         [3] KerberosVSupportNego OPTIONAL
        -- Should there be ETYPE-INFO2 stuff here?
   }

   Err-get-keys      ::= SEQUENCE {
        help-text      [0] UTF8String OPTIONAL, -- Reason for rejection
        error          [1] CHOICE {
                op-generic         [0] Extensible-NULL,
                op-kvno-committed  [1] Extensible-NULL,
                op-no-such-kvno    [1] Extensible-NULL
        }
   }

   -- Commit a set keys request
   Req-commit-keys ::= SEQUENCE {
        kvno         [0] UInt32
   }

   Rep-commit-keys ::= Extensible-NULL

   Err-commit-keys ::= SEQUENCE {
        help-text    [0] UTF8String OPTIONAL, -- Reason for rejection
        error        [1] CHOICE {
                op-generic           [0] Extensible-NULL,
                op-kvno-expired      [1] Extensible-NULL,
                    -- The client took too long to respond.
                op-kvno-unknown      [2] Extensible-NULL,
                    -- The targ princ/kvno is invalid or unknown to the
                    -- server (perhaps it lost track of state)
                op-new-keys-conflict [3] Extensible-NULL
                    -- A new-keys/commit-keys request subsequent to the
                    -- new-keys that produced the kvno has completed
                    -- and incremented the principal's kvno
        }
   }

   -- Get password policy
   Req-get-pw-policy   ::= Extensible-NULL

   Rep-get-pw-policy   ::= SEQUENCE {
        policy-name      [0] UTF8String OPTIONAL,
        description      [1] SEQUENCE OF UTF8String OPTIONAL
   }

   Err-get-pw-policy   ::= Extensible-NULL

   -- Get principal aliases
   Req-get-princ-aliases        ::= Extensible-NULL

   Rep-get-princ-aliases        ::= SEQUENCE {
        help-text    [0] UTF8String OPTIONAL,
        aliases      [1] SEQUENCE OF SEQUENCE {
                name      [0] PrincipalName,
                realm     [1] Realm OPTIONAL
        }
   }

   Err-get-princ-aliases        ::= Extensible-NULL

   -- Get list of enctypes supported by KDC for new keys
   Req-get-realm-krb5-support   ::= Extensible-NULL

   Rep-get-realm-krb5-support   ::= SEQUENCE {
        isupport        [0] KerberosVSupportNego
                                -- Version of Kerberos V supported by
                                -- the target realm.
   }

   Err-get-realm-krb5-support   ::= Extensible-NULL

   -- Get s2kparams
   Req-get-s2kparams            ::= Extensible-NULL

   Rep-get-s2kparams            ::= SEQUENCE {
        help-text       [0] UTF8String OPTIONAL,
        s2kparams       [1] SEQUENCE OF Etype-Info-Entry
   }

   Err-get-s2kparams            ::= Extensible-NULL

   END

6  IANA Considerations

   There are no IANA considerations for this document.

7  Security Considerations
   
   Implementors and site administrators should note that the redundancy
   of UTF-8 encodings of passwords varies by language.  Password quality
   policies SHOULD, therefore, take this into account when estimating
   the amount of redundancy and entropy in a proposed new password.  [??
   It's late at night - I think this is correct.]

   Kerberos set/change password/key protocol major version negotiation
   cannot be done securely; a downgrade attack is possible against
   clients that attempt to negotiate the protocol major version to use
   with a server.  It is not clear at this time that the attacker would
   gain much from such a downgrade attack other than denial of service
   (DoS) by forcing the client to use a protocol version which does not
   support some feature needed by the client (Kerberos V in general is
   subject to a variety of DoS attacks anyways [RFC1510]).  Clients
   SHOULD NOT negotiate support for legacy major versions of this
   protocol unless configured otherwise.

   This protocol does not have Perfect Forward Security (PFS).  As a
   result, any passive network snooper watching password/key changing
   operations who has stolen a principal's password or long-term keys
   can find out what the new ones are.

   [More text needed?]

8  Acknowledgements
   
   The authors would like to thank original editors/authors Jonathan
   Trostle, Bill Gossman, Mike Swift, John Brezak, as well as Ken
   Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W.
   Nelson, Marcus Watts, Love, Joel N.  Weber II, Jeffrey Hutzelman and
   other participants from the IETF Kerberos Working Group for their
   assistance.
-->
>From fenner at gmail.com  Sat Mar 31 21:55:53 2007
From: fenner at gmail.com (Bill Fenner)
Date: Sat Mar 31 20:56:02 2007
Subject: [xml2rfc] Entities broken lately
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Initial analysis shows that this isn't entity handling per se: it's a
combination of
a) <artwork> elements don't render properly when there's a PI inside
b) entity expansion now gets <?rfc linefile="..."?> PIs inserted.

I'm trying to investigate the root cause of (a).  It's frustratingly
subtle, since in the earlier passes the PCDATA is seen properly; it's
just lost in the processing pass.  It knows how many lines of artwork
to expect, but it just fails to render them.

  Bill

From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Sat Mar 31 23:13:23 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-03-31 01:18, Bill Fenner wrote:
> On 3/20/07, Tony Hansen <[email-masked]> wrote:
>> Something I periodically trip over is forgetting to change the name of
>> the draft I'm writing from e.g. "-01" to "-02".
>>
>> It would be nice if xml2rfc could optionally check
>>
>>         <rfc ... docName="draft-ietf-xyz-01.txt">
>>
>> against the name of the file being processed, and warn if they don't
>> match up through the "-02" portion of the name.
> 
> Just want to check on this, since it seems that different people have
> different usage models.  I tend to name things with short names that
> have no relationship to the output file, e.g.,
> draft-fenner-iana-exp-2780 was created by iana-experimental.xml .  Are
> you proposing that with this usage model, the warning should always
> trigger?

I personally use the full filename, but that is just my finicky
personality coming out ;-). I think that using a short form is
quite reasonable. But maybe, iff the name starts with draft- you can
process the version number?

> 
>> PS. I use the online xml2rfc submission form.
> 
> This is actually a sticky wicket: the online converter can return
> status or the converted file, but not both, so it chooses to ignore
> warnings in favor of supplying the converted file.
> 
> Certainly it'd be possible to return an HTML status page that uses an
> http refresh header to download the converted document, but I'm not
> sure making that change would make us many friends (especially since
> right now you can easily script the online conversion).

Maybe add a 3rd "show warnings" alternative to the "output result" options?

    Brian
>From brc at zurich.ibm.com  Sun Apr  1 10:15:02 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Sat Mar 31 23:15:17 2007
Subject: [xml2rfc] Announcing 1.33pre3
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Bill,

Thanks.

> Links to RFCs are to the tools.ietf.org HTML version.

This being very much a matter of taste, can we have a way to select it?

    Brian
>From nobody at xyzzy.claranet.de  Sun Apr  1 19:34:52 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr  1 10:31:42 2007
Subject: [xml2rfc] Re: Announcing 1.33pre3
References: <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
 
> More details at http://xml.resource.org/experimental.html

Hi, I've downloaded the DTD linked on that page:
<http://xml.resource.org/authoring/rfc2629.dtd>

That DTD says its date is 2005-10-25 like the DTD I already
had, and the only change is s/"info"/#IMPLIED/ for the
category.  Is that really the 1.33pre3 experimental DTD ?

Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Apr  1 14:18:51 2007
Subject: [xml2rfc] Re: Announcing 1.33pre3
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> That DTD says its date is 2005-10-25 like the DTD I already
> had, and the only change is s/"info"/#IMPLIED/ for the
> category.  Is that really the 1.33pre3 experimental DTD ?

here's the file. we'll make sure the right one is on the servers.

/mtr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rfc2629.dtd
Type: application/octet-stream
Size: 8685 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070401/e54b1083/rfc2629.obj
>From tony at att.com  Sun Apr  1 21:47:38 2007
From: tony at att.com (Tony Hansen)
Date: Sun Apr  1 17:47:24 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Brian E Carpenter wrote:
>> Just want to check on this, since it seems that different people have
>> different usage models.  I tend to name things with short names that
>> have no relationship to the output file, e.g.,
>> draft-fenner-iana-exp-2780 was created by iana-experimental.xml .  Are
>> you proposing that with this usage model, the warning should always
>> trigger?
> 
> I personally use the full filename, but that is just my finicky
> personality coming out ;-). I think that using a short form is
> quite reasonable. But maybe, iff the name starts with draft- you can
> process the version number?

+1

>>> PS. I use the online xml2rfc submission form.
>>
>> This is actually a sticky wicket: the online converter can return
>> status or the converted file, but not both, so it chooses to ignore
>> warnings in favor of supplying the converted file.
>>
>> Certainly it'd be possible to return an HTML status page that uses an
>> http refresh header to download the converted document, but I'm not
>> sure making that change would make us many friends (especially since
>> right now you can easily script the online conversion).
> 
> Maybe add a 3rd "show warnings" alternative to the "output result" options?

I'd certainly like the option of seeing the warnings. I also could see
an option that caused the warnings to be shown, along with a link that
you could click on to go directly to the output if you chose to.

First form:

	Input file     ________________
	Output mode    * Text o HTML o nroff o unpaginated XML
 	Output result  * Window o File
	Show warnings: * no o yes

If you chose to show warnings, you'd see something like this:

	The following warnings were found ....

	__LINK__ Generate file, ignoring warnings

If not on the default form, perhaps the "show warnings" could be on the
Advanced form that I brought up in another thread?

	Tony Hansen
	[email-masked]
>From nobody at xyzzy.claranet.de  Mon Apr  2 03:46:47 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Sun Apr  1 17:48:10 2007
Subject: [xml2rfc] Re: Announcing 1.33pre3
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> here's the file

Thanks, now it's 5 (or 4) changes, 2007 timestamp, no
default category, section nesting, ditto appendix, and
irefs at the begin of a figure.

Frank

From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  2 07:14:08 2007
Subject: [xml2rfc] <cref>'s and formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 3/26/07, Tony Hansen <[email-masked]> wrote:
> Another issue that came up with my conversation the other day about
> using <cref>s, is that formatting commands are totally ignored within
> the <cref>. All you ever get is a blob of unending text. You can't get
> newlines or white space or *anything*, much less doing anything else
> remotely interesting.

I've only ever used <cref>s for brief, one or two sentence blurbs, so
I'm curious about the use case for this.  If I wanted to write long
commentary on something such that I wanted formatting, I might think
I'd use an appendix with an xref from the text.

> I'd like to see the DTD and processing model modified to support
> formatting. <cref> could possibly be made equivalent to <t> for all
> intents, except that it's contents are conditionally output.

Currently, <cref> is (can be) rendered inline, like <span> in html,
while <t> is a block element, like <p> or <div>.  I'd like to retain
the ability to have a one-or-two sentence comment rendered inline.
(This just means that it's not quite as simple as treating <cref>
exactly like a conditional <t>)

  Bill
>From john+xml at jck.com  Mon Apr  2 16:34:40 2007
From: john+xml at jck.com (John C Klensin)
Date: Mon Apr  2 12:34:50 2007
Subject: [xml2rfc] Re: xml2rfc Digest, Vol 34, Issue 2
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Monday, 02 April, 2007 07:13:57 -0700, "Bill Fenner"
<[email-masked]> wrote,...

> On 3/26/07, Tony Hansen <[email-masked]> wrote:
>> Another issue that came up with my conversation the other day
>> about using <cref>s, is that formatting commands are totally
>> ignored within the <cref>. All you ever get is a blob of
>> unending text. You can't get newlines or white space or
>> *anything*, much less doing anything else remotely
>> interesting.
> 
> I've only ever used <cref>s for brief, one or two sentence
> blurbs, so I'm curious about the use case for this.  If I
> wanted to write long commentary on something such that I
> wanted formatting, I might think I'd use an appendix with an
> xref from the text.

At least one use case arises when <cref>s are used to do
detailed tracking of a document being revised as the result of
an ongoing, high-controversy, discussion.  One might contain a
date, a brief summary of the relevant discussion, URLs or
equivalent pointing to 
key messages, or a summary of the path not taken (including
potentially alternate ABNF, deleted text, etc.).  They are
conditionally expanded, inline, when needed for tracking, but do
not normally appear in the "official" I-D posting.

Independent of wanting to _write_ complex <cref> elments,
suppose one wants to turn several lines of highly-formatted or
marked-up text into a <cref> that contains "Deleted 20070231:
..." followed by the original text.  The current <cref> syntax
requires that the markup, xref elements, etc., that might have
occurred in that block of text be removed.   That makes things
harder to read, harder to understand, and is, at best, a
significant annoyance.

This is, in many respects, exactly one of the uses for which
<cref> was, if I recall, first discussed -- providing an
alternative for the extensive change tracking by precise date,
responsible party, removed text, etc., of more traditional
document management systems.

How far it is worth going in that direction and what priority it
should have are clearly separate questions.

best,
   john

From: tony at att.com (Tony Hansen)
Date: Mon Apr  2 12:52:54 2007
Subject: [xml2rfc] <cref>'s and formatting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

In my conversation, both of us were using the cref to capture comments
on the document by other users, which we wanted to be able to see
inline. Some of those comments could go on for several paragraphs, along
with our own notes about those comments.

	Tony

Bill Fenner wrote:
> On 3/26/07, Tony Hansen <[email-masked]> wrote:
>> Another issue that came up with my conversation the other day about
>> using <cref>s, is that formatting commands are totally ignored within
>> the <cref>. All you ever get is a blob of unending text. You can't get
>> newlines or white space or *anything*, much less doing anything else
>> remotely interesting.
> 
> I've only ever used <cref>s for brief, one or two sentence blurbs, so
> I'm curious about the use case for this.  If I wanted to write long
> commentary on something such that I wanted formatting, I might think
> I'd use an appendix with an xref from the text.
> 
>> I'd like to see the DTD and processing model modified to support
>> formatting. <cref> could possibly be made equivalent to <t> for all
>> intents, except that it's contents are conditionally output.
> 
> Currently, <cref> is (can be) rendered inline, like <span> in html,
> while <t> is a block element, like <p> or <div>.  I'd like to retain
> the ability to have a one-or-two sentence comment rendered inline.
> (This just means that it's not quite as simple as treating <cref>
> exactly like a conditional <t>)
> 
>  Bill
>From fenner at gmail.com  Mon Apr  2 17:51:31 2007
From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  2 16:51:40 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 4/1/07, Brian E Carpenter <[email-masked]> wrote:
> On 2007-03-31 01:18, Bill Fenner wrote:
> > On 3/20/07, Tony Hansen <[email-masked]> wrote:
> >> Something I periodically trip over is forgetting to change the name of
> >> the draft I'm writing from e.g. "-01" to "-02".
> >>
> >> It would be nice if xml2rfc could optionally check
> >>
> >>         <rfc ... docName="draft-ietf-xyz-01.txt">
> >>
> >> against the name of the file being processed, and warn if they don't
> >> match up through the "-02" portion of the name.

Here's an alternate proposal: have the filename provided in the
download be derived from the docName.  e.g., you upload foo.xml, with
docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt"
instead of "foo.txt".

  Bill
>From tony at att.com  Mon Apr  2 23:47:31 2007
From: tony at att.com (Tony Hansen)
Date: Mon Apr  2 19:47:24 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

That could work.

Here's an alternate alternate proposal: make docName optional and have
the generated filename used for it be derived from the uploaded
filename. So if I upload the file foo.xml and don't specify a docName,
the generated filename would be foo.txt.

On the scale of things, I'm much less concerned about this issue as
things like formatting within <cref>. That's why I called it a nitlet. :-)

	Tony Hansen
	[email-masked]

Bill Fenner wrote:
> On 4/1/07, Brian E Carpenter <[email-masked]> wrote:
>> On 2007-03-31 01:18, Bill Fenner wrote:
>> > On 3/20/07, Tony Hansen <[email-masked]> wrote:
>> >> Something I periodically trip over is forgetting to change the name of
>> >> the draft I'm writing from e.g. "-01" to "-02".
>> >>
>> >> It would be nice if xml2rfc could optionally check
>> >>
>> >>         <rfc ... docName="draft-ietf-xyz-01.txt">
>> >>
>> >> against the name of the file being processed, and warn if they don't
>> >> match up through the "-02" portion of the name.
> 
> Here's an alternate proposal: have the filename provided in the
> download be derived from the docName.  e.g., you upload foo.xml, with
> docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt"
> instead of "foo.txt".

From: fenner at gmail.com (Bill Fenner)
Date: Wed Apr  4 17:00:30 2007
Subject: [xml2rfc] Please try newfangled warning reporting
Message-ID: <[email-masked]>

http://www2.xml.resource.org/newfangled.html is a form that allows
both reporting of warnings and download of the resulting file.  Please
try it out and let me know how it works for you.  It uses an HTTP
Refresh: 0; ... header to redirect you to the download and provides a
link if the refresh doesn't work.  I've only tested it with Safari so
far.

(IE7 feedback is particularly encouraged since I've heard that IE7
behaves differently with this kind of refresh.)

Thanks,
  Bill
>From tony at att.com  Wed Apr  4 23:33:11 2007
From: tony at att.com (Tony Hansen)
Date: Wed Apr  4 19:32:49 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Clicking on the "follow this link" link gives "Download Failed Sorry,
CGI....txt must have expired."

Otherwise, it has caught some things I didn't know about before. Thanks!

	Tony Hansen
	[email-masked]

Bill Fenner wrote:
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.  Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides a
> link if the refresh doesn't work.  I've only tested it with Safari so
> far.
> 
> (IE7 feedback is particularly encouraged since I've heard that IE7
> behaves differently with this kind of refresh.)

From: fenner at gmail.com (Bill Fenner)
Date: Wed Apr  4 23:32:49 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 4/4/07, Tony Hansen <[email-masked]> wrote:
> Clicking on the "follow this link" link gives "Download Failed Sorry,
> CGI....txt must have expired."

Did the download happen in the background (which would have deleted
the file, making the second attempt think it had expired)?  Can you
check your download manager and/or directory to see if it is there?

Would it be better to have the contents of the link live for longer,
to allow multiple downloads like this?

  Bill
>From brc at zurich.ibm.com  Thu Apr  5 10:47:06 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Thu Apr  5 00:47:21 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

The warnings are excellent to have.

The Windows download box works fine, but with Firefox 2.0.0.2 "follow this link" gives:

Download Failed

Sorry, CGI73236.1.txt must have expired.

Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8 Server at 
www2.xml.resource.org Port 80

     Brian

On 2007-04-05 02:00, Bill Fenner wrote:
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.  Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides a
> link if the refresh doesn't work.  I've only tested it with Safari so
> far.
> 
> (IE7 feedback is particularly encouraged since I've heard that IE7
> behaves differently with this kind of refresh.)
> 
> Thanks,
>  Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From brc at zurich.ibm.com  Thu Apr  5 11:22:02 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Thu Apr  5 01:22:17 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

In my case, it seemed to be invalid instantly - i.e. regardless
of whether I also clicked the download box presented by
Windows. Maybe the act of popping up that box makes the server
believe that the download has been requested?

    Brian

On 2007-04-05 08:32, Bill Fenner wrote:
> On 4/4/07, Tony Hansen <[email-masked]> wrote:
>> Clicking on the "follow this link" link gives "Download Failed Sorry,
>> CGI....txt must have expired."
> 
> Did the download happen in the background (which would have deleted
> the file, making the second attempt think it had expired)?  Can you
> check your download manager and/or directory to see if it is there?
> 
> Would it be better to have the contents of the link live for longer,
> to allow multiple downloads like this?
> 
>  Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From elwynd at dial.pipex.com  Thu Apr  5 12:01:47 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Apr  5 03:00:49 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi.

Agreed!  This is a good move.
It reported a warning I hadn't seen before (on an old draft) about the 
need for a bad line break.

The symptoms Tony reports occur for me on Firefox 1.5.0.11 - the output 
has successfully downloaded at the same time, but I can't use the link 
(tried it while the download report was still popped up).
I think it would be good to maintain the file for a while - for those 
little moments when one presses the wrong button ;-) and where the 
conversion has taken 5 hours (thinking of a recent example!)

But...
I tried it on IE6 (which I only use for the web sites that have sold 
their souls to Gatessoft) and the result was not so good.
The symptoms were:
- The 'success' page which I had just seen on Firefox flashed onto the 
screen, but
- It was immediately replaced by a page from the Apache server saying 
'Invocation Error - input file not provided'.

Sorry I can't help with IE7 due to an aversion to .0 releases (and no 
desire to clutter my disk).

Regards,
Elwyn

Tony Hansen wrote:
> Clicking on the "follow this link" link gives "Download Failed Sorry,
> CGI....txt must have expired."
>
> Otherwise, it has caught some things I didn't know about before. Thanks!
>
> 	Tony Hansen
> 	[email-masked]
>
> Bill Fenner wrote:
>   
>> http://www2.xml.resource.org/newfangled.html is a form that allows
>> both reporting of warnings and download of the resulting file.  Please
>> try it out and let me know how it works for you.  It uses an HTTP
>> Refresh: 0; ... header to redirect you to the download and provides a
>> link if the refresh doesn't work.  I've only tested it with Safari so
>> far.
>>
>> (IE7 feedback is particularly encouraged since I've heard that IE7
>> behaves differently with this kind of refresh.)
>>     
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From henrik at levkowetz.com  Thu Apr  5 13:57:22 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Apr  5 03:57:25 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

on 2007-04-05 02:00 Bill Fenner said the following:
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.  Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides a
> link if the refresh doesn't work.  I've only tested it with Safari so
> far.
> 
> (IE7 feedback is particularly encouraged since I've heard that IE7
> behaves differently with this kind of refresh.)

Tried it with IE 5.2 (Mac), and a draft with errors.  The error page
came up fine, but almost immediately transitioned into a page which
said 
  Invocation Error
  input file not provided

Trying it with a draft that should be error-free resulted in a good
completion report page with the download link, and the browser started
doing something (possibly attempting the download?) which either
resulted in or was superseded by an error page with the same message
as above (Invocation error).

	Henrik
>From tony at att.com  Thu Apr  5 10:59:45 2007
From: tony at att.com (Tony Hansen)
Date: Thu Apr  5 06:59:16 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On 4/4/07, Tony Hansen <[email-masked]> wrote:
>> Clicking on the "follow this link" link gives "Download Failed Sorry,
>> CGI....txt must have expired."
> 
> Did the download happen in the background (which would have deleted
> the file, making the second attempt think it had expired)?  Can you
> check your download manager and/or directory to see if it is there?

The download did happen in the background. Silly me, since the link was
there, I just expected the link to work as well.

> Would it be better to have the contents of the link live for longer,
> to allow multiple downloads like this?

yes

	Tony Hansen
	[email-masked]

> 
>  Bill
>From fenner at gmail.com  Thu Apr  5 08:48:25 2007
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  5 07:48:30 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 4/5/07, Henrik Levkowetz <[email-masked]> wrote:
> Tried it with IE 5.2 (Mac), and a draft with errors.  The error page
> came up fine, but almost immediately transitioned into a page which
> said
>   Invocation Error
>   input file not provided

For those who have gotten this error, can you give me the IP address
that you would have been trying from so that I can check the logs?  It
looks like the redirect is losing the CGI arguments.

I've modified it so that it doesn't delete the file on download, so
that multiple clicks on the "download it" link will work, and fancy
download managers won't cause the file to be deleted early.

I've added a hash of the output filename to the download URL, to make
it harder to guess a valid file to download, now that they're longer
lived.  Previously there was just a PID in the filename, which you
could increment or decrement and download someone else's document.
(Not that I think that anyone is converting state secrets using this
form, but it's polite to not share things that people have just
started working on, etc.)

  Bill
>From henrik at levkowetz.com  Thu Apr  5 18:25:02 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu Apr  5 08:25:07 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Bill,

on 2007-04-05 16:48 Bill Fenner said the following:
> On 4/5/07, Henrik Levkowetz <[email-masked]> wrote:
>> Tried it with IE 5.2 (Mac), and a draft with errors.  The error page
>> came up fine, but almost immediately transitioned into a page which
>> said
>>   Invocation Error
>>   input file not provided
> 
> For those who have gotten this error, can you give me the IP address
> that you would have been trying from so that I can check the logs?  It
> looks like the redirect is losing the CGI arguments.

My access would have been from either
  shiraz.levkowetz.com at 81.232.110.214
or
  shiraz.levkowetz.com at 2001:16d8:ff54::1

> I've modified it so that it doesn't delete the file on download, so
> that multiple clicks on the "download it" link will work, and fancy
> download managers won't cause the file to be deleted early.
> 
> I've added a hash of the output filename to the download URL, to make
> it harder to guess a valid file to download, now that they're longer
> lived.  Previously there was just a PID in the filename, which you
> could increment or decrement and download someone else's document.
> (Not that I think that anyone is converting state secrets using this
> form, but it's polite to not share things that people have just
> started working on, etc.)

Sounds good to me.  Cron job cleanup after 24 hours?

	Henrik

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  5 09:15:38 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
References: <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:

> http://www2.xml.resource.org/newfangled.html

Hi, I've tested it this mornong (my time, GMT) with IE6, it did
not work as expected:  For a split second there was a "succesful
conversion" screen, immediately followed by a page claiming that
something on your side was missing.

Second test *now* with netscape 3.x:  Same problem, I get an
"You lose" "Invocation Error" "input file not provided" page
immediately after the "You win" "successful conversion" page.

Maybe try a meta-refresh instead of whatever you do now, example:

<meta http-equiv="Refresh" content="5; URL=http://purl.net/xyzzy/index.htm" />

For HTML get rid of the last slash.  The 5 is for seconds.
You can test the effect at http://purl.net/xyzzy/err404.html

Frank

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  5 09:26:47 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
 
> For those who have gotten this error, can you give me the IP address
> that you would have been trying from so that I can check the logs?

No idea what I used some hours ago, but now it's 80.171.255.87  Maybe
you use some HTTP/1.1 magic for the refresh, that can't work with an
HTTP/1.0 netscape 3.x UA.  There are two problems, the missing delay,
(don't try 5 seconds, start with 10), and the error with the target
page showing an "invocation error".

Frank

From: fenner at research.att.com (Bill Fenner)
Date: Thu Apr  5 10:15:14 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>Maybe try a meta-refresh instead of whatever you do now, example:
>
><meta http-equiv="Refresh" content="5; URL=http://purl.net/xyzzy/index.htm" />

What I'm doing now is an HTTP Refresh: header.  Is <meta http-equiv>
really better supported than actual HTTP headers?

  Bill
>From nobody at xyzzy.claranet.de  Thu Apr  5 21:05:03 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  5 11:07:10 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:

> Is <meta http-equiv> really better supported than actual HTTP headers?

Dunno, it was a wild guess why that delay might not work as expected.

Can you setup a simple test page somewhere using the HTTP/1.1 header
approach, i.e. without additional tricks like synchronous downloads ?

Other unsorted ideas:  Do you have a pragma nocache for the page with
the allegedly missing "input" ?  If not I'd clear my cache manually
for new tests.  

How about replacing "newfangled" by "warnings", no result at all, only
errors and warnings resp.  Or a combined plain/text result, errors or
output, and if there was no error add warnings to the output as is...
if that's possible, it could be more difficult than finding and fixing
the current problem(s).

Frank

From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  5 12:02:45 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 4/2/07, Bill Fenner <[email-masked]> wrote:
> Here's an alternate proposal: have the filename provided in the
> download be derived from the docName.  e.g., you upload foo.xml, with
> docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt"
> instead of "foo.txt".

I implemented this in my experimental version at
http://www2.xml.resource.org/newfangled.html .

Tony suggested making docName optional and having the generated
filename be based on the uploaded filename.  That's what already
happens; if you don't supply a docName= attribute the filename
displayed on the front page is based upon the filename that was
supplied in the upload.  e.g., I just uploaded ospf-iana-nodocname.xml
to the standard converter and the header says

                      IANA Considerations for OSPF
                          ospf-iana-nodocname

  Bill
>From elwynd at dial.pipex.com  Thu Apr  5 21:04:17 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Apr  5 12:03:18 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

The trials at a few minutes before 11am BST (6am EDT) were from 
81.187.254.247.

You should see about half a dozen trials - the last couple were from 
IE6, the earlier (successful) ones from Firefox.

regards,
Elwyn

Bill Fenner wrote:
> On 4/5/07, Henrik Levkowetz <[email-masked]> wrote:
>> Tried it with IE 5.2 (Mac), and a draft with errors.  The error page
>> came up fine, but almost immediately transitioned into a page which
>> said
>>   Invocation Error
>>   input file not provided
>
> For those who have gotten this error, can you give me the IP address
> that you would have been trying from so that I can check the logs?  It
> looks like the redirect is losing the CGI arguments.
>
> I've modified it so that it doesn't delete the file on download, so
> that multiple clicks on the "download it" link will work, and fancy
> download managers won't cause the file to be deleted early.
>
> I've added a hash of the output filename to the download URL, to make
> it harder to guess a valid file to download, now that they're longer
> lived.  Previously there was just a PID in the filename, which you
> could increment or decrement and download someone else's document.
> (Not that I think that anyone is converting state secrets using this
> form, but it's polite to not share things that people have just
> started working on, etc.)
>
>  Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From elwynd at dial.pipex.com  Thu Apr  5 21:14:57 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Thu Apr  5 12:14:01 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

The latest incarnation appears to have fixed the problem at least with 
IE6 (and it still works fine with Firefox 1.5.0.11).

FYI attached is a copy of the displayed page source with all the 
debugging info.

/Elwyn

Bill Fenner wrote:
> On 4/5/07, Henrik Levkowetz <[email-masked]> wrote:
>> Tried it with IE 5.2 (Mac), and a draft with errors.  The error page
>> came up fine, but almost immediately transitioned into a page which
>> said
>>   Invocation Error
>>   input file not provided
>
> For those who have gotten this error, can you give me the IP address
> that you would have been trying from so that I can check the logs?  It
> looks like the redirect is losing the CGI arguments.
>
> I've modified it so that it doesn't delete the file on download, so
> that multiple clicks on the "download it" link will work, and fancy
> download managers won't cause the file to be deleted early.
>
> I've added a hash of the output filename to the download URL, to make
> it harder to guess a valid file to download, now that they're longer
> lived.  Previously there was just a PID in the filename, which you
> could increment or decrement and download someone else's document.
> (Not that I think that anyone is converting state secrets using this
> form, but it's polite to not share things that people have just
> started working on, etc.)
>
>  Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
-------------- next part --------------
<html>
<head>
<title>You Win</title>
</head>
<body >
<h1>Conversion Successful</h1>Your download should begin shortly, or <a href="http://www2.xml.resource.org/cgi-bin/xml2rfc-exp.cgi?download=CGI743.1.8D27A0861513054BE957F9D85755DE22.txt">follow this link</a>.
<br /><b>Warnings during conversion:</b>
<ul>
<li>xml2rfc: warning: no &lt;xref&gt; in &lt;rfc&gt; targets &lt;reference anchor='NewArch03'&gt; around input line 44</li>
<li>xml2rfc: warning: output line 4 (on page 40) breaks badly between &quot;&lt;ht&quot; and &quot;tp://psg.com/~avri/papers/paper-yong-hpsr2002-final.pdf&gt;&quot; around input line 2822</li>
</ul>
<hr /><hr /><b>Debugging:</b>
<br />HTTP Refresh header:
<pre>Refresh: 0; URL=http://www2.xml.resource.org/cgi-bin/xml2rfc-exp.cgi?download=CGI743.1.8D27A0861513054BE957F9D85755DE22.txt
</pre>Environment:
<pre>LC_IDENTIFICATION=C
LD_LIBRARY_PATH=/usr/pkg/lib:/usr/lib:/usr/local/lib
LC_NUMERIC=C
SERVER_ADDR=192.20.225.40
LANG=C
LC_COLLATE=C
HTTP_X_FORWARDED_FOR=81.187.254.247
GATEWAY_INTERFACE=CGI/1.1
DOCUMENT_ROOT=/usr/local/www/xml.resource.org/web
SERVER_PORT=80
LANGUAGE=C
LC_MEASUREMENT=C
LC_ADDRESS=C
HTTP_HOST=www2.xml.resource.org
REMOTE_ADDR=81.187.254.242
SERVER_NAME=www2.xml.resource.org
HTTP_CONNECTION=keep-alive
SERVER_PROTOCOL=HTTP/1.0
REQUEST_URI=/cgi-bin/xml2rfc-exp.cgi
REMOTE_PORT=37716
SERVER_SIGNATURE=&lt;address&gt;Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8 Server at www2.xml.resource.org Port 80&lt;/address&gt;

REQUEST_METHOD=POST
SERVER_SOFTWARE=Apache/2.2.3 (FreeBSD) mod_ssl/2.2.3 OpenSSL/0.9.7e-p1 DAV/2 PHP/4.4.6 with Suhosin-Patch mod_perl/2.0.2 Perl/v5.8.8
LC_TELEPHONE=C
HTTP_ACCEPT_LANGUAGE=en-gb
LINGUAS=C
LC_CTYPE=C
HTTP_CACHE_CONTROL=no-cache, max-age=259200
UNIQUE_ID=pVdZ3cAU4SgAAYAaGCAAAAAG
CONTENT_TYPE=multipart/form-data; boundary=---------------------------7d731027a07b4
QUERY_STRING=
HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
CONTENT_LENGTH=136132
XML_LIBRARY=/usr/local/www/xml.resource.org/web/public/rfc/bibxml:/usr/local/www/xml.resource.org/web/public/rfc/bibxml2:/usr/local/www/xml.resource.org/web/public/rfc/bibxml3:/usr/local/www/xml.resource.org/web/public/rfc/bibxml4:/usr/local/www/xml.resource.org/web/public/rfc/bibxml5
LC_TIME=C
LC_MONETARY=C
SCRIPT_NAME=/cgi-bin/xml2rfc-exp.cgi
HTTP_ACCEPT_ENCODING=gzip, deflate
PATH=/usr/bin:/bin:/usr/pkg/bin:/usr/local/bin:/sbin:/usr/sbin
SCRIPT_FILENAME=/usr/local/www/xml.resource.org/cgi-bin/xml2rfc-exp.cgi
LC_PAPER=C
LC_MESSAGES=C
LC_NAME=C
LC_ALL=C
HTTP_VIA=1.1 brdgfw:3128 (squid/2.5.STABLE6)
SERVER_ADMIN=[email-masked]
HTTP_ACCEPT=image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
</pre>Parsed XML root element:
<pre>.ANCHOR 42 updates {} iprExtract {} docName draft-irtf-routing-history-02.txt .NAME rfc obsoletes {} seriesNo {} number {} ipr full3978 xml:lang en submissionType IETF .CHILDREN {2 41 577}
</pre></body>
</html>
<html>
<body >
</body>
</html>
>From tony at att.com  Thu Apr  5 16:19:15 2007
From: tony at att.com (Tony Hansen)
Date: Thu Apr  5 12:18:50 2007
Subject: [xml2rfc] minor nitlet I'd like flagged
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Excellent!

	Tony

Bill Fenner wrote:
> On 4/2/07, Bill Fenner <[email-masked]> wrote:
>> Here's an alternate proposal: have the filename provided in the
>> download be derived from the docName.  e.g., you upload foo.xml, with
>> docname="draft-ietf-xyz-01", it downloads as "draft-ietf-xyz-01.txt"
>> instead of "foo.txt".
> 
> I implemented this in my experimental version at
> http://www2.xml.resource.org/newfangled.html .
> 
> Tony suggested making docName optional and having the generated
> filename be based on the uploaded filename.  That's what already
> happens; if you don't supply a docName= attribute the filename
> displayed on the front page is based upon the filename that was
> supplied in the upload.  e.g., I just uploaded ospf-iana-nodocname.xml
> to the standard converter and the header says
> 
>                      IANA Considerations for OSPF
>                          ospf-iana-nodocname
> 
> 
>  Bill
>From fenner at gmail.com  Thu Apr  5 14:26:41 2007
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  5 13:26:49 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 4/5/07, Elwyn Davies <[email-masked]> wrote:
> later... Was just wondering if all that was needed was to keep the file around.
>   I have a sneaking suspicion that IE re-accesses the file as part of its
> download nannying and was finding it missing on the second pass when it was
> removed immediately?

Yes, the "Explorer prevented this site from downloading a file"
interaction counted to the cgi script as a successful download, so it
removed the file.

  Bill
>From fenner at gmail.com  Thu Apr  5 14:36:54 2007
From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  5 13:37:00 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 4/5/07, Frank Ellermann <[email-masked]> wrote:
> Hi, I've tested it this mornong (my time, GMT) with IE6, it did
> not work as expected:  For a split second there was a "succesful
> conversion" screen, immediately followed by a page claiming that
> something on your side was missing.

This was probably the IE download-nanny, causing the file to get
deleted before allowing you to see it.

> Second test *now* with netscape 3.x:  Same problem, I get an
> "You lose" "Invocation Error" "input file not provided" page
> immediately after the "You win" "successful conversion" page.

I suspect this was because of the partial URL that the refresh header
supplies.  I've made the URL a complete URL, and it works in Netscape
4.79 (the oldest browser that I have access to).  I have a list of
user-agents for which to not try the refresh (right now just MSIE5 (it
displays the text file instead of downloading it, so replaces the
result page with the document)); I can add Mozilla/3 to the list if
the updated version doesn't work for you.

  Bill
>From nobody at xyzzy.claranet.de  Thu Apr  5 23:59:16 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Apr  5 14:00:06 2007
Subject: [xml2rfc] Re: Please try newfangled warning reporting
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:

 [2nd test] 
> I suspect this was because of the partial URL that the refresh
> header supplies.  I've made the URL a complete URL, and it works
> in Netscape 4.79

It now works also here (Netscape 3.x, officially Netscape 2.02 for
OS/2, but that's the 3.x "mozilla 3" enginge, only with a 2.x GUI)

> I can add Mozilla/3 to the list if the updated version doesn't
> work for you.

Add it to the opposite list, "oldest browser reported to work" :-)

Thanks,

 Frank

From: fenner at gmail.com (Bill Fenner)
Date: Thu Apr  5 14:39:23 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 4/5/07, Fred Baker <[email-masked]> wrote:
> The error page (second case) had all the errors pointing
> to line 41

Let's seperate out that issue for now - that's about how xml2rfc
reports these particular warnings, and right now I'm trying to focus
on getting the UI for getting the warnings back to the user through
the CGI.  Once people start seeing the warnings that have been being
generated all along, we can focus on improving them.

> One thing that surprised me was to find
>
> <html>
> <head>
> <title>untitled</title>
> </head>
> <body >
> </body>
> </html>
>
> at the tail of the .txt file (both cases).

Good eye!  I was only looking at the first few pages.  The cgi library
thought that there wasn't any output so it made sure to output an
"html page".

> Also, the web page
> resulting had a lot of debug outputs that didn't mean much to me.

Indeed, that's only supposed to mean anything to me.  Thanks for the reports.

  Bill
>From tony at att.com  Thu Apr  5 19:12:37 2007
From: tony at att.com (Tony Hansen)
Date: Thu Apr  5 15:12:17 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Would it be possible to have a version that goes to the warnings page
but doesn't start an auto-download. Instead, it has a link pointing at
the generated output file that can be viewed within the browser?

This would be particularly preferable for html output.

	Tony Hansen
	[email-masked]

Bill Fenner wrote:
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.  Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides a
> link if the refresh doesn't work.  I've only tested it with Safari so
> far.

From: simon at josefsson.org (Simon Josefsson)
Date: Fri Apr  6 00:38:26 2007
Subject: [xml2rfc] Change default to use symbolic references?
Message-ID: <[email-masked]>

Hi!  There is a thread about using symbolic references in IETF
documents on the IETF list:

http://thread.gmane.org/gmane.ietf.general/24640

What do you think about changing the default behaviour for xml2rfc?
Was there a conscious decision to use numeric references?  If so, does
anyone recall the motivation for that?

Thanks,
Simon
>From brc at zurich.ibm.com  Fri Apr  6 14:41:11 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Fri Apr  6 04:41:18 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

The issues I saw with Firefox are all fixed now.

Thanks
    Brian

On 2007-04-05 10:22, Brian E Carpenter wrote:
> In my case, it seemed to be invalid instantly - i.e. regardless
> of whether I also clicked the download box presented by
> Windows. Maybe the act of popping up that box makes the server
> believe that the download has been requested?
> 
>    Brian
> 
> On 2007-04-05 08:32, Bill Fenner wrote:
>> On 4/4/07, Tony Hansen <[email-masked]> wrote:
>>> Clicking on the "follow this link" link gives "Download Failed Sorry,
>>> CGI....txt must have expired."
>>
>> Did the download happen in the background (which would have deleted
>> the file, making the second attempt think it had expired)?  Can you
>> check your download manager and/or directory to see if it is there?
>>
>> Would it be better to have the contents of the link live for longer,
>> to allow multiple downloads like this?
>>
>>  Bill
>> _______________________________________________
>> xml2rfc mailing list
>> [email-masked]
>> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>>
> 
>From mrose at dbc.mtview.ca.us  Fri Apr  6 10:13:59 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Apr  6 09:14:05 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> What do you think about changing the default behaviour for xml2rfc?
> Was there a conscious decision to use numeric references?  If so, does
> anyone recall the motivation for that?

the default will not change, because that would create surprises for  
people.

if you want symbolic references, use the PI that gets you that: symrefs.

we will also add symrefs to the rfcedstyle PI, since the rfc editor  
has proclaimed them a "good thing".

/mtr

From: dbharrington at comcast.net (David B Harrington)
Date: Fri Apr  6 11:34:15 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I used IE7 and it worked fine.

dbh 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bill Fenner
> Sent: Wednesday, April 04, 2007 8:00 PM
> To: xml2rfc mailing list
> Subject: [xml2rfc] Please try newfangled warning reporting
> 
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.
Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides
a
> link if the refresh doesn't work.  I've only tested it with Safari
so
> far.
> 
> (IE7 feedback is particularly encouraged since I've heard that IE7
> behaves differently with this kind of refresh.)
> 
> Thanks,
>   Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: dhc2 at dcrocker.net (Dave Crocker)
Date: Mon Apr  9 11:39:55 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> What do you think about changing the default behaviour for xml2rfc?
>> Was there a conscious decision to use numeric references?  If so, does
>> anyone recall the motivation for that?
> 
> the default will not change, because that would create surprises for 
> people.

+1.

Separately, that thread cited the rather cumbersome symbolic name convention 
for Internet Drafts.  I'm not sure what to suggest, but is seems like a 
shorter convention out to be possible, or maybe just allow the autor to choose 
the symbolic reference?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From julian.reschke at gmx.de  Mon Apr  9 21:50:33 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 11:50:52 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Dave Crocker schrieb:
> Separately, that thread cited the rather cumbersome symbolic name 
> convention for Internet Drafts.  I'm not sure what to suggest, but is 
> seems like a shorter convention out to be possible, or maybe just allow 
> the autor to choose the symbolic reference?

Well, the author *can* choose the symbolic reference. Just paste in the 
<reference>, and change the anchor. This also makes the reference robust 
(instead of a moving target).

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Apr  9 14:55:38 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 11:56:38 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 11:39:14AM -0700, Dave Crocker wrote:
> Separately, that thread cited the rather cumbersome symbolic name 
> convention for Internet Drafts.  I'm not sure what to suggest, but is seems 
> like a shorter convention out to be possible, or maybe just allow the autor 
> to choose the symbolic reference?

The latter.  I want control over what the symbolic references look like.

I realize that this doesn't work well with the current model for xrefs.
It might be necessary to add a way to re-assign the anchor of an object
(<reanchor target="I-D...." anchor="rfcXYZbis"/>).

Else Bill's XSLT approach might be recommended, though it's quite unqieldy
compared to something supported directly by xml2rfc.

Nico
-- 
>From Nicolas.Williams at sun.com  Mon Apr  9 14:56:57 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 11:58:01 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote:
> Well, the author *can* choose the symbolic reference. Just paste in the 
> <reference>, and change the anchor. This also makes the reference robust 
> (instead of a moving target).

True, and I've even done this once or twice before.  OTOH, this would
make it more difficult for the RFC-Editor to deal with, no?
>From fenner at research.att.com  Mon Apr  9 13:07:42 2007
From: fenner at research.att.com (Bill Fenner)
Date: Mon Apr  9 12:07:51 2007
Subject: [xml2rfc] Change default to use symbolic references?
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>Dave Crocker schrieb:
>> Separately, that thread cited the rather cumbersome symbolic name 
>> convention for Internet Drafts.  I'm not sure what to suggest, but is 
>> seems like a shorter convention out to be possible, or maybe just allow 
>> the autor to choose the symbolic reference?
>
>Well, the author *can* choose the symbolic reference. Just paste in the 
><reference>, and change the anchor. This also makes the reference robust 
>(instead of a moving target).

Or, the author can add an xsl transform to his workflow to rename
the reference as he desires even if he uses the standard reference
library.

  Bill
>From julian.reschke at gmx.de  Mon Apr  9 22:14:00 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 12:14:21 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote:
>> Well, the author *can* choose the symbolic reference. Just paste in the 
>> <reference>, and change the anchor. This also makes the reference robust 
>> (instead of a moving target).
> 
> True, and I've even done this once or twice before.  OTOH, this would
> make it more difficult for the RFC-Editor to deal with, no?

I wouldn't think so. If my draft refers to draft-bla-14, and at time of 
publication that one has been updated, it's *my* job to ensure the 
reference is still good. A silent update at that stage is a Very Bad Idea.

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Apr  9 15:25:53 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 12:26:52 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 09:14:00PM +0200, Julian Reschke wrote:
> Nicolas Williams schrieb:
> >On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote:
> >>Well, the author *can* choose the symbolic reference. Just paste in the 
> >><reference>, and change the anchor. This also makes the reference robust 
> >>(instead of a moving target).
> >
> >True, and I've even done this once or twice before.  OTOH, this would
> >make it more difficult for the RFC-Editor to deal with, no?
> 
> I wouldn't think so. If my draft refers to draft-bla-14, and at time of 
> publication that one has been updated, it's *my* job to ensure the 
> reference is still good. A silent update at that stage is a Very Bad Idea.

That's not what I meant.  I meant that the RFC-Editor might have to do
more work to verify that the references you included by value are
correct.
>From julian.reschke at gmx.de  Mon Apr  9 22:36:22 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 12:36:41 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> On Mon, Apr 09, 2007 at 09:14:00PM +0200, Julian Reschke wrote:
>> Nicolas Williams schrieb:
>>> On Mon, Apr 09, 2007 at 08:50:33PM +0200, Julian Reschke wrote:
>>>> Well, the author *can* choose the symbolic reference. Just paste in the 
>>>> <reference>, and change the anchor. This also makes the reference robust 
>>>> (instead of a moving target).
>>> True, and I've even done this once or twice before.  OTOH, this would
>>> make it more difficult for the RFC-Editor to deal with, no?
>> I wouldn't think so. If my draft refers to draft-bla-14, and at time of 
>> publication that one has been updated, it's *my* job to ensure the 
>> reference is still good. A silent update at that stage is a Very Bad Idea.
> 
> That's not what I meant.  I meant that the RFC-Editor might have to do
> more work to verify that the references you included by value are
> correct.

For internet drafts, the seriesInfo element provides all necessary 
information, and there's even an automated checker (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>).

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Apr  9 13:41:32 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 12:41:38 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

>> the default will not change, because that would create surprises  
>> for people.
>
> +1.

hi. i guess i'm going to flip-flop my position on this.

what i'd like to do is change the default, and add a warning for  
documents that don't specify symrefs that tells them the default has  
changed. we can keep the warning in for a couple of releases.

does that *really* annoy anyone?

> Separately, that thread cited the rather cumbersome symbolic name  
> convention for Internet Drafts.  I'm not sure what to suggest, but  
> is seems like a shorter convention out to be possible, or maybe  
> just allow the autor to choose the symbolic reference?

the conflict is between being "short and meaningful" and "unique".  
the current rules basically value "unique" over the former.

here is a possibility that is worth discussing: having some kind of a  
mapping specified in the document, e.g.,

	<?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>

which would tell the processor that instead of using "I-D.zhou- ... - 
presence" as the label use "zhou" instead. this allows an author to:

1. unambiguously refer to the correct reference
2. use the bibliographic databases unaltered
3. use whatever short name they feel is meaningful

comments?

/mtr

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 12:45:35 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 12:41:32PM -0700, Marshall Rose wrote:
> >>the default will not change, because that would create surprises  
> >>for people.
> >
> >+1.
> 
> hi. i guess i'm going to flip-flop my position on this.
> 
> what i'd like to do is change the default, and add a warning for  
> documents that don't specify symrefs that tells them the default has  
> changed. we can keep the warning in for a couple of releases.
> 
> does that *really* annoy anyone?

Not me.  Go for it.

> here is a possibility that is worth discussing: having some kind of a  
> mapping specified in the document, e.g.,
> 
> 	<?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
> 
> which would tell the processor that instead of using "I-D.zhou- ... - 
> presence" as the label use "zhou" instead. this allows an author to:
> 
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful
> 
> comments?

+1
>From hagens at ISI.EDU  Mon Apr  9 13:52:07 2007
From: hagens at ISI.EDU (Alice Hagens)
Date: Mon Apr  9 12:52:36 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

That would be extremely helpful from an RFC Editor perspective.

I had imagined something like
<?rfc include="I-D.zhou-simple-hierarchical-presence" tag="zhou">
but what you're suggesting is better since it's not just when refs
are being included.

Alice

On Apr 9, 2007, at 12:41 PM, Marshall Rose wrote:

> here is a possibility that is worth discussing: having some kind of  
> a mapping specified in the document, e.g.,
>
> 	<?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
>
> which would tell the processor that instead of using "I-D.zhou- ...  
> -presence" as the label use "zhou" instead. this allows an author to:
>
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 12:58:27 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
> ...
> the conflict is between being "short and meaningful" and "unique". the 
> current rules basically value "unique" over the former.
> 
> here is a possibility that is worth discussing: having some kind of a 
> mapping specified in the document, e.g.,
> 
>     <?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
> 
> which would tell the processor that instead of using "I-D.zhou- ... 
> -presence" as the label use "zhou" instead. this allows an author to:
> 
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful
> 
> comments?
> ...

Please, no more PI tape to hold things together.

1) PIs are hard to process in the XML tool chain. You need a custom 
parser for the contents. It's a royal pain in XSLT.

2) This affects the validity of the document. Documents using this PI 
would be invalid by definition. And we want people to check their docs 
for validity, right?

3) Again: if we want to fix the various issues with reference inclusion, 
let's do that *properly* (meaning, using the XML tool chain properly). 
To do that, let's list the pain points first.

As far as I can tell, all of this is only a problem because people 
somehow feel that including references is somehow better. IMHO, that is 
clearly not the case. It's far more better to have a document with no 
external dependencies, and an optional mechanism that can warn if 
something you included previously changed (if there's interest in 
*that*, I'll make a proposal).

Best regards, Julian

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 13:05:05 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 09:58:05PM +0200, Julian Reschke wrote:
> As far as I can tell, all of this is only a problem because people 
> somehow feel that including references is somehow better. IMHO, that is 
> clearly not the case. It's far more better to have a document with no 
> external dependencies, and an optional mechanism that can warn if 
> something you included previously changed (if there's interest in 
> *that*, I'll make a proposal).

Huh?  No, I don't want to have to copy by value.  This is web 2.0,
hyper-linking is the way of the future, and all that.
>From mrose at dbc.mtview.ca.us  Mon Apr  9 14:05:45 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 13:05:52 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Apr 9, 2007, at 12:58 , Julian Reschke wrote:

>
> As far as I can tell, all of this is only a problem because people  
> somehow feel that including references is somehow better. IMHO,  
> that is clearly not the case. It's far more better to have a  
> document with no external dependencies, and an optional mechanism  
> that can warn if something you included previously changed (if  
> there's interest in *that*, I'll make a proposal).

julian - make a competing proposal.

i don't think we're talking about the same problem though.

the problem, as i see it, is that we have automated bibliographic  
databases that have to generate unique labels, and unique labels,  
when generated by programs tend to be long and tend to be ugly.

some people don't care about the label. for those who do, i want to  
give them a way of specifying their own labels but also to use the  
existing bibliographic databases *unaltered*.

is this the same problem that you're talking about?

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:09:23 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Alice Hagens schrieb:
> That would be extremely helpful from an RFC Editor perspective.
> 
> I had imagined something like
> <?rfc include="I-D.zhou-simple-hierarchical-presence" tag="zhou">
> but what you're suggesting is better since it's not just when refs
> are being included.
> 
> Alice

I personally think that including references by referring to external 
resources is a bad idea. They are not stable, in particular not for 
Internet Drafts, and thus not really meaningful.

That being said, the proper XML way to add that feature to xml2rfc would 
be to make it explicit in the DTD, for instance:

...<xref target="rfc2223bis"/> ...

and then

<references>
   <reference anchor="rfc2223bis">
     <include href="http://xml.resource.org/...whatever"/>
   </reference>
</references>

Same effect, clearer markup.

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:14:40 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
> 
> On Apr 9, 2007, at 12:58 , Julian Reschke wrote:
> 
>>
>> As far as I can tell, all of this is only a problem because people 
>> somehow feel that including references is somehow better. IMHO, that 
>> is clearly not the case. It's far more better to have a document with 
>> no external dependencies, and an optional mechanism that can warn if 
>> something you included previously changed (if there's interest in 
>> *that*, I'll make a proposal).
> 
> julian - make a competing proposal.
> 
> i don't think we're talking about the same problem though.
> 
> the problem, as i see it, is that we have automated bibliographic 
> databases that have to generate unique labels, and unique labels, when 
> generated by programs tend to be long and tend to be ugly.

Understood.

> some people don't care about the label. for those who do, i want to give 
> them a way of specifying their own labels but also to use the existing 
> bibliographic databases *unaltered*.
> 
> is this the same problem that you're talking about?

It's one of them.

OK, here's a proposal.

1) No new PIs. Deprecate the existing include PI. Let people *include* 
the reference.

2) Then, add a new attribute on the reference element that preserves the 
source of the reference, so that a tool can check whether the content of 
the reference is still up-to-date, and provide a warning when it is not 
(and optionally update the document):

<reference anchor="rfc223bis" 
src="http://xml.resource.org/public/rfc/bibxml3/....xml">
   ...
</reference>

3) The "src" attribute would signal that the contents of the reference 
element was copied from the given URI. Tools can then be provided that 
detect changes in the source, and potentially update the document 
source. However, the document itself stays robust and has no potentially 
fragile external references.

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:15:50 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> On Mon, Apr 09, 2007 at 09:58:05PM +0200, Julian Reschke wrote:
>> As far as I can tell, all of this is only a problem because people 
>> somehow feel that including references is somehow better. IMHO, that is 
>> clearly not the case. It's far more better to have a document with no 
>> external dependencies, and an optional mechanism that can warn if 
>> something you included previously changed (if there's interest in 
>> *that*, I'll make a proposal).
> 
> Huh?  No, I don't want to have to copy by value.  This is web 2.0,
> hyper-linking is the way of the future, and all that.

Actually, hyper-linking is web 1.0 :-).

I like hyper-linking, but I think it's not appropriate here. At least, 
as long as we're talking about references for internet drafts.

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Mon Apr  9 14:20:49 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 13:20:55 2007
Subject: [xml2rfc] 3rd xml.resource.org server
Message-ID: <[email-masked]>

hi. henrik levkowetz has brought up a new xml.resource.org server, so  
we now have three servers independently hosting and generating the  
bibliographic databases and authoring tools.

thanks henrik!

/mtr

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 13:28:52 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote:
> I personally think that including references by referring to external 
> resources is a bad idea. They are not stable, in particular not for 
> Internet Drafts, and thus not really meaningful.

If references to I-Ds are not stable then that ought to be a bug.  Just
because I-Ds are not stable doesn't mean that references to them should
also not be stable.  I don't notice if they are unstable because I
download the bibxml tar files and untar in the same location every time,
which doesn't remove files that have been dropped from the tar file.

And all other bibliographic references should be stable also.

Nico
-- 
>From fenner at gmail.com  Mon Apr  9 14:31:30 2007
From: fenner at gmail.com (Bill Fenner)
Date: Mon Apr  9 13:31:36 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 4/9/07, Julian Reschke <[email-masked]> wrote:
> Marshall Rose schrieb:
> >     <?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
>
> 2) This affects the validity of the document.

I understood it to only say "when rendering an anchor for reference
named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" -
which just affects rendering, not validity.  Both the anchor and the
target would still use the full I-D.foo name, but the refmapping=
string would be used inside the brackets.

  Bill
>From mrose at dbc.mtview.ca.us  Mon Apr  9 14:33:45 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 13:33:51 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> I understood it to only say "when rendering an anchor for reference
> named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" -
> which just affects rendering, not validity.  Both the anchor and the
> target would still use the full I-D.foo name, but the refmapping=
> string would be used inside the brackets.

correct.

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:35:34 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote:
>> I personally think that including references by referring to external 
>> resources is a bad idea. They are not stable, in particular not for 
>> Internet Drafts, and thus not really meaningful.
> 
> If references to I-Ds are not stable then that ought to be a bug.  Just

Partly agreed, but this is the case today. The references are for the 
latest version of an internet draft, so the thing they reference changes 
over time.

Some consider this a feature, because it makes authors believe that they 
don't need to take care that their ID references are correct. I consider 
it a problem.

> ...

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:37:11 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner schrieb:
> On 4/9/07, Julian Reschke <[email-masked]> wrote:
>> Marshall Rose schrieb:
>> >     <?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
>>
>> 2) This affects the validity of the document.
> 
> I understood it to only say "when rendering an anchor for reference
> named I-D.zhou-simple-hierarchical-presence, use the string 'zhou'" -
> which just affects rendering, not validity.  Both the anchor and the
> target would still use the full I-D.foo name, but the refmapping=
> string would be used inside the brackets.

OK, understood.

The whole issue would go away if the thing being included wouldn't carry 
it's anchor with it (see my proposal).

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Apr  9 16:41:09 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 13:42:15 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 10:35:15PM +0200, Julian Reschke wrote:
> Nicolas Williams schrieb:
> >On Mon, Apr 09, 2007 at 10:09:03PM +0200, Julian Reschke wrote:
> >>I personally think that including references by referring to external 
> >>resources is a bad idea. They are not stable, in particular not for 
> >>Internet Drafts, and thus not really meaningful.
> >
> >If references to I-Ds are not stable then that ought to be a bug.  Just
> 
> Partly agreed, but this is the case today. The references are for the 
> latest version of an internet draft, so the thing they reference changes 
> over time.

That is acceptable.  What wouldn't be acceptable is if the reference
disappeared altogether.

> Some consider this a feature, because it makes authors believe that they 
> don't need to take care that their ID references are correct. I consider 
> it a problem.

I consider it a feature.

I don't want to have to do a lot of copy-paste every few months on my
I-Ds, and I don't want to have to remember a long list of XML tool
incantations to produce a formatted I-D.  One incantation should
suffice.  If that means that xml2rfc needs to do XSLTs itself,
possibly with additional dependencies on other tools, then so be it.

Make this easy on us, not hard.

Nico
-- 
>From mrose at dbc.mtview.ca.us  Mon Apr  9 14:43:24 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 13:43:31 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Partly agreed, but this is the case today. The references are for  
> the latest version of an internet draft, so the thing they  
> reference changes over time.
>
> Some consider this a feature, because it makes authors believe that  
> they don't need to take care that their ID references are correct.  
> I consider it a problem.

julian - i think there is a misunderstanding here. the automated  
databases contain N+1 entries for each I-D:

	reference.I-D.whatever.xml
	reference.I-D.whatever-xx.xml

if you use "-xx", you get version "xx", e.g., "-01". if you don't use  
"-xx", you get the latest version.

this allows the "obvious" thing to happen.

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:50:12 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> ...
>> Some consider this a feature, because it makes authors believe that they 
>> don't need to take care that their ID references are correct. I consider 
>> it a problem.
> 
> I consider it a feature.
> ...

So how do you know that draft n + 1 still contains the information you 
were referring to when referencing draft n?

Best regards, Julian
>From julian.reschke at gmx.de  Mon Apr  9 23:52:16 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 13:52:36 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
>> Partly agreed, but this is the case today. The references are for the 
>> latest version of an internet draft, so the thing they reference 
>> changes over time.
>>
>> Some consider this a feature, because it makes authors believe that 
>> they don't need to take care that their ID references are correct. I 
>> consider it a problem.
> 
> julian - i think there is a misunderstanding here. the automated 
> databases contain N+1 entries for each I-D:
> 
>     reference.I-D.whatever.xml
>     reference.I-D.whatever-xx.xml
> 
> if you use "-xx", you get version "xx", e.g., "-01". if you don't use 
> "-xx", you get the latest version.
> 
> this allows the "obvious" thing to happen.

I wasn't aware of that. Thanks for the clarification.

So I would strongly argue to deprecate the usage of the non-numbered 
references. Minimally, the RFC Editor should reject them on submitted 
documents, because it's really essential that a document author knows 
what (s)he's citing.

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Apr  9 16:54:28 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 13:55:29 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 10:49:51PM +0200, Julian Reschke wrote:
> Nicolas Williams schrieb:
> >...
> >>Some consider this a feature, because it makes authors believe that they 
> >>don't need to take care that their ID references are correct. I consider 
> >>it a problem.
> >
> >I consider it a feature.
> >...
> 
> So how do you know that draft n + 1 still contains the information you 
> were referring to when referencing draft n?

In one or more of several ways:

 - lazily -- WG and IETF Last Call, AD, IESG and RFC-Editor reviews all
   can catch bogus references

 - actively -- I track the I-Ds my I-Ds reference (often there's very
   few of these and I am in touch with their editors)

No XML tool could help me with, say, an I-D being split into two or more parts,
unless all those parts had different names and the old I-D entered the DEAD
state and the bibliography DB and XML tools knew to check for this.

Nico
-- 
>From julian.reschke at gmx.de  Tue Apr 10 00:00:27 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon Apr  9 14:00:47 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Nicolas Williams schrieb:
> On Mon, Apr 09, 2007 at 10:49:51PM +0200, Julian Reschke wrote:
>> Nicolas Williams schrieb:
>>> ...
>>>> Some consider this a feature, because it makes authors believe that they 
>>>> don't need to take care that their ID references are correct. I consider 
>>>> it a problem.
>>> I consider it a feature.
>>> ...
>> So how do you know that draft n + 1 still contains the information you 
>> were referring to when referencing draft n?
> 
> In one or more of several ways:
> 
>  - lazily -- WG and IETF Last Call, AD, IESG and RFC-Editor reviews all
>    can catch bogus references

That's fragile. It means that reviewers need to be ensure that the thing 
being referenced still says what it used to say earlier. Even if that 
question is simple to answer, it basically requires checking both the 
document and the references.

>  - actively -- I track the I-Ds my I-Ds reference (often there's very
>    few of these and I am in touch with their editors)
> 
> No XML tool could help me with, say, an I-D being split into two or more parts,
> unless all those parts had different names and the old I-D entered the DEAD
> state and the bibliography DB and XML tools knew to check for this.

Well, if I'm referencing draft n, and it gets updated by n+1, my job as 
author is to ensure that the thing I wanted to reference is still there. 
  I think any facility that would make you believe that you don't have 
to do that on your own is a bad idea (don't rely on third parties; check 
yourself!).

Best regards, Julian
>From Nicolas.Williams at sun.com  Mon Apr  9 17:01:26 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Mon Apr  9 14:02:27 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Mon, Apr 09, 2007 at 11:00:27PM +0200, Julian Reschke wrote:
> Well, if I'm referencing draft n, and it gets updated by n+1, my job as 
> author is to ensure that the thing I wanted to reference is still there. 
>  I think any facility that would make you believe that you don't have 
> to do that on your own is a bad idea (don't rely on third parties; check 
> yourself!).

When I end up with a reference to an I-D I'm utterly unfamiliar with
I'll remember to do it this way.  For now, given that I author and edit
my own I-Ds I just don't have this problem.
>From henrik at levkowetz.com  Tue Apr 10 00:37:10 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Apr  9 14:37:24 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

on 2007-04-09 21:41 Marshall Rose said the following:
...
> here is a possibility that is worth discussing: having some kind of a  
> mapping specified in the document, e.g.,
> 
> 	<?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
> 
> which would tell the processor that instead of using "I-D.zhou- ... - 
> presence" as the label use "zhou" instead. this allows an author to:
> 
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful
> 
> comments?

I'd appreciate something like this.

I've been thinking in terms of being able to specify the short name
in one of the <xref/>s, something like

  ...
  <xref target="I-D.zhou-simple-hierarchical-presence" label="zhou" />
  ...

and have that label used instead of the target name at the
points of reference and in the references section; but Julian's
proposal

> ...<xref target="rfc2223bis"/> ...
> 
> and then
> 
> <references>
>    <reference anchor="rfc2223bis">
>      <include href="http://xml.resource.org/...whatever"/>
>    </reference>
> </references>
> 

would also work for me, if the effect of the <include/> (or maybe
call it <refinclude/>) would be to import the online bibxml database
entry, but let the new anchor value override the imported one.

	Henrik
>From nobody at xyzzy.claranet.de  Tue Apr 10 01:47:14 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Mon Apr  9 15:48:18 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
 
> <?rfc refmapping='I-D.zhou-simple-hierarchical-presence zhou'?>
[...]
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful
 
> comments?

Let's test it, but maybe I won't use it if it confuses rfcmarkup.

Frank

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Apr  9 16:36:09 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I've been thinking in terms of being able to specify the short name
> in one of the <xref/>s, something like
>
>   ...
>   <xref target="I-D.zhou-simple-hierarchical-presence" label="zhou" />
>   ...
>
> and have that label used instead of the target name at the
> points of reference and in the references section

i would prefer to associate the label with the <reference/> and not  
the <xref/> to avoid the issue of having multiple <xref/>'s point to  
the same <reference/> and yet have different labels (-:

/mtr

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Mon Apr  9 17:02:20 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

on 2007-04-10 01:36 Marshall Rose said the following:
>> I've been thinking in terms of being able to specify the short name
>> in one of the <xref/>s, something like
>>
>>   ...
>>   <xref target="I-D.zhou-simple-hierarchical-presence" label="zhou" />
>>   ...
>>
>> and have that label used instead of the target name at the
>> points of reference and in the references section
> 
> i would prefer to associate the label with the <reference/> and not  
> the <xref/> to avoid the issue of having multiple <xref/>'s point to  
> the same <reference/> and yet have different labels (-:

Yes, that's a good point.

	Henrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070410/68fd6cb9/signature.bin
>From brc at zurich.ibm.com  Tue Apr 10 10:24:09 2007
From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Tue Apr 10 00:24:21 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian,

On 2007-04-09 22:52, Julian Reschke wrote:
> Marshall Rose schrieb:
>>> Partly agreed, but this is the case today. The references are for the 
>>> latest version of an internet draft, so the thing they reference 
>>> changes over time.
>>>
>>> Some consider this a feature, because it makes authors believe that 
>>> they don't need to take care that their ID references are correct. I 
>>> consider it a problem.
>>
>> julian - i think there is a misunderstanding here. the automated 
>> databases contain N+1 entries for each I-D:
>>
>>     reference.I-D.whatever.xml
>>     reference.I-D.whatever-xx.xml
>>
>> if you use "-xx", you get version "xx", e.g., "-01". if you don't use 
>> "-xx", you get the latest version.
>>
>> this allows the "obvious" thing to happen.
> 
> I wasn't aware of that. Thanks for the clarification.
> 
> So I would strongly argue to deprecate the usage of the non-numbered 
> references. Minimally, the RFC Editor should reject them on submitted 
> documents, because it's really essential that a document author knows 
> what (s)he's citing.

I think you're missing that fact that RFCs cannot refer normatively
to I-Ds anyway. The only I-D references than can survive in an RFC
are informative "work in progress" references, which by definition
are not needed either to understand or implement the RFC.

So, from that point of view, I-D version numbers simply don't matter
at the RFC stage.

I agree with you that an author should know what (s)he's doing, but
that's exactly why we have the normative reference concept.

     Brian
>From julian.reschke at gmx.de  Tue Apr 10 10:31:09 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 10 00:31:33 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Brian E Carpenter schrieb:
> Julian,
> 
> ...
 >
> 
> I think you're missing that fact that RFCs cannot refer normatively
> to I-Ds anyway. The only I-D references than can survive in an RFC
> are informative "work in progress" references, which by definition
> are not needed either to understand or implement the RFC.

I was thinking of the text that the RFC Editor gets for publication, not 
the result.

*That* version can contain normative ID references; and will be 
published (if all other things are done) once the ID is published as RFC 
as well.

If the ID being referred to *changes* between the time a document is 
approved, and the time it gets published, this requires manual checking 
that the reference is still good.

> So, from that point of view, I-D version numbers simply don't matter
> at the RFC stage.
> 
> I agree with you that an author should know what (s)he's doing, but
> that's exactly why we have the normative reference concept.

Well, they still need to know even if it's informative. Having a bad 
*informative* reference is less bad, but it's still bad.

Best regards, Julian
>From john+xml at jck.com  Tue Apr 10 08:11:50 2007
From: john+xml at jck.com (John C Klensin)
Date: Tue Apr 10 04:11:56 2007
Subject: [xml2rfc] Change default to use symbolic references
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Monday, 09 April, 2007 12:41:32 -0700, Marshall Rose
<[email-masked]> wrote:

>...
>> Separately, that thread cited the rather cumbersome symbolic
>> name   convention for Internet Drafts.  I'm not sure what to
>> suggest, but   is seems like a shorter convention out to be
>> possible, or maybe   just allow the autor to choose the
>> symbolic reference?
> 
> the conflict is between being "short and meaningful" and
> "unique".   the current rules basically value "unique" over
> the former.

Yes, obviously.

> here is a possibility that is worth discussing: having some
> kind of a   mapping specified in the document, e.g.,
> 
> 	<?rfc refmapping='I-D.zhou-simple-hierarchical-presence
> zhou'?>
> 
> which would tell the processor that instead of using
> "I-D.zhou- ... -  presence" as the label use "zhou" instead.
> this allows an author to:
> 
> 1. unambiguously refer to the correct reference
> 2. use the bibliographic databases unaltered
> 3. use whatever short name they feel is meaningful
> 
> comments?

This seems both elegant and reasonable to me.    

I continue to share Julian's concern about trying to deal with
anything as volatile (with regard to name, date, and content) as
an I-D by reference, but I think that is a separate issue,
especially since I can reference a specific draft by version
number and then use the IDnits checker to determine whether all
such drafts are current.  The suggestion to permit xml2rfc
itself to generate a warning if the version of an I-D is current
also seems useful, but please note the earlier suggestion about
distinguishing between a stable reference to a particular
version of an I-D or RFC/BCP/STD (e.g., for historical purposes)
and a reference that might need updating as versions change.

    john

    john

From: john+xml at jck.com (John C Klensin)
Date: Tue Apr 10 04:29:50 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

--On Tuesday, 10 April, 2007 09:24:09 +0200, Brian E Carpenter
<[email-masked]> wrote...

Brian,

> On 2007-04-09 22:52, Julian Reschke wrote:
>> Marshall Rose schrieb:

>>> julian - i think there is a misunderstanding here. the
>>> automated  databases contain N+1 entries for each I-D:
>>> 
>>>     reference.I-D.whatever.xml
>>>     reference.I-D.whatever-xx.xml
>>> 
>>> if you use "-xx", you get version "xx", e.g., "-01". if you
>>> don't use  "-xx", you get the latest version.
>>> 
>>> this allows the "obvious" thing to happen.
>> 
>> I wasn't aware of that. Thanks for the clarification.
>> 
>> So I would strongly argue to deprecate the usage of the
>> non-numbered  references. Minimally, the RFC Editor should
>> reject them on submitted  documents, because it's really
>> essential that a document author knows  what (s)he's citing.
> 
> I think you're missing that fact that RFCs cannot refer
> normatively to I-Ds anyway. The only I-D references than can
> survive in an RFC are informative "work in progress"
> references, which by definition are not needed either to
> understand or implement the RFC.
> 
> So, from that point of view, I-D version numbers simply don't
> matter at the RFC stage.

That identification is useful for two other reasons:

(1) When someone starts revising an RFC, and has the XML
available, it is necessary to pull up any I-Ds that may be
referenced and review and probably update those references.   If
any are still to I-Ds, the I-Ds that result must have full I-D
information in them, not "work in progress" indications.

(2) I don't know how long it will take to make a change, if
ever, but I have come to believe that we actually have two types
of I-D references in RFCs and that reasonable standards for an
archival document require that they be treated differently.
Even before the change is made in the RFC format, I believe it
is useful for generic markup to indicate what is going on and
perhaps to be able to reflect the difference in HTML output.
They are:

(i) I-Ds that really are working documents ("works in progress")
that are expected to evolve into, or contribute to, RFCs in some
form.

(ii) I-Ds (and RFCs) that are cited for historical purposes and
that will never change.  This group includes the "these ideas
were first discussed in..." pointers that some of us have
encouraged to help anchor a date and document against possible
patent nonsense, references to a particular version of an I-D
that contains the last full discussion of a bad and rejected
idea that should nonetheless be cited in Acknowledgments or the
like, and so on.  Because they are stable and historical, they
are not "works in progress" in any sense.  And because they are
readily available on the network, going out of our way to make
them hard to find (by disguising them as works in progress)
violates good sense and all sorts of scholarly and bibliographic
norms about telling people where to find the things that are
being referenced if they really might need to do so.

I think what I suggested earlier (I'm not sure if on this list)
was an optional attribute of the character of 
   <reference .... status="historical">
with the alternative (and default) attribute being "normal", or
something.

Since the status of a referenced document would be very much a
property of the document containing the reference, if we start
applying directives to references to bibliographic libraries to
alter the anchor names, something like this might be good to do
at the same time or at least in the same way.

      john

From: ned.freed at mrochek.com (Ned Freed)
Date: Tue Apr 10 08:33:28 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: "Your message dated Tue, 10 Apr 2007 09:24:09 +0200" <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> > So I would strongly argue to deprecate the usage of the non-numbered
> > references. Minimally, the RFC Editor should reject them on submitted
> > documents, because it's really essential that a document author knows
> > what (s)he's citing.

> I think you're missing that fact that RFCs cannot refer normatively
> to I-Ds anyway. The only I-D references than can survive in an RFC
> are informative "work in progress" references, which by definition
> are not needed either to understand or implement the RFC.

> So, from that point of view, I-D version numbers simply don't matter
> at the RFC stage.

Even more to the point, AFAIK such references not only do not include the I-D
version, they don't even include the I-D name! It's hard to get excited about
knowing the I-D version when you don't even have the I-D name.

I will also note that for I-D references that get turned into RFC references
prior to publication the RFC Editor process itself may have changed section
numbering or other formatting in the referenced draft. So the RFC Editor has no
choice but to cross check such references. So, while it may help a little
to carefully insure all your references are up to date, you're probably
not saving the RFC Editor as much time as you might think.

FWIW, my preference is to use external references for RFCs (since they're
totally stable) but to insert I-D references inline. I do this mostly because I
don't like the lack of a URL in the default I-D reference format. I figure
since the reference is going to have to change one way or another prior to
publication it might as well be as useful to readers as possibe.

				Ned
>From mrose at dbc.mtview.ca.us  Tue Apr 10 09:46:06 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Apr 10 08:46:14 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> This would require an entry for every cited I-D.  Typically not the  
> most onerous task one might have, but possibly redundant, nonetheless.

actually, there were be an entry for the ones you care about, if any.

> I note that:
>
>>   <!ENTITY dkimbase	PUBLIC '' 'http://xml.resource.org/public/rfc/ 
>> bibxml3/reference.I-D.ietf-dkim-base.xml'>
>
> already has a field that I specify as a symbolic reference (dkimbase).
>
> So, why not merely have one "<?rfc remapping>" and have it switch  
> to use of the symbolic string in all ENTITY statements?

julian - comments? the usual "don't use a PI" ?

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 10 08:51:09 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose schrieb:
>> This would require an entry for every cited I-D.  Typically not the 
>> most onerous task one might have, but possibly redundant, nonetheless.
> 
> actually, there were be an entry for the ones you care about, if any.
> 
> 
>> I note that:
>>
>>>   <!ENTITY dkimbase    PUBLIC '' 
>>> 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dkim-base.xml'> 
>>>
>>
>> already has a field that I specify as a symbolic reference (dkimbase).
>>
>> So, why not merely have one "<?rfc remapping>" and have it switch to 
>> use of the symbolic string in all ENTITY statements?
> 
> julian - comments? the usual "don't use a PI" ?

No, in this case: don't use something that is outside both the XPath 
datamodel and the XML infoset: the name of the entity simply isn't 
available, so a XPath or Infoset based processor just doesn't have that 
information.

Best regards, Julian

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 10 09:09:41 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

OK,

here's a complete proposal. We change

<!ELEMENT reference   (front,seriesInfo*,format*,annotation*)>
<!ATTLIST reference
           anchor      ID                 #IMPLIED
           target      %URI;              #IMPLIED>

to

<!ELEMENT reference   (include|(front,seriesInfo*,format*,annotation*))>
<!ATTLIST reference
           anchor      ID                 #IMPLIED
           target      %URI;              #IMPLIED>
<!ELEMENT include     ( EMPTY>
<!ATTLIST include
           src         %URI;              #IMPLIED>

So a <reference> either is the same thing as before (<front> and 
optional metadata), *or* it contains a single <include> element.

<include> is empty, and has a single required attribute, specifying the 
URI (or relative reference) from where the reference should be included. 
The inclusion process copies all attributes of the external <reference> 
element that haven't been set in the parent <reference> element, plus 
all child elements.

For instance, to use [HTTP] to refer to RFC2616, one would say:

<reference anchor="HTTP">
   <include 
src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/>
</reference>

The benefit here is that we don't rely on pseudo-attributes in PIs 
(fragile to parse), and the source document stays DTD-valid.

That being said, *if* we do this change I'd also recommend three more 
changes:

(a) Make <organization> optional: it doesn't make sense to require the 
presence of the element, but to happily accept an empty value.

<!ELEMENT author      (organization?,address?)>

(b) Make <date> optional: for the same reasons:

<!ELEMENT front       (title,author+,date?,area*,workgroup*,keyword*,
                        abstract?,note*)>

(c) As suggested by John Klensin, add a way so that we can specify that 
a document reference is historic; thus disabling the logic in xml2rfc 
which claims "work in progress" even though the ID is known to be expired.

<!ATTLIST reference
           anchor      ID                 #IMPLIED
           historic    (true|false)       "false"
           target      %URI;              #IMPLIED>

Best regards, Julian
>From Nicolas.Williams at sun.com  Tue Apr 10 12:25:08 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Apr 10 09:26:10 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Tue, Apr 10, 2007 at 06:09:23PM +0200, Julian Reschke wrote:
> So a <reference> either is the same thing as before (<front> and 
> optional metadata), *or* it contains a single <include> element.
> 
> <include> is empty, and has a single required attribute, specifying the 
> URI (or relative reference) from where the reference should be included. 
> The inclusion process copies all attributes of the external <reference> 
> element that haven't been set in the parent <reference> element, plus 
> all child elements.

As long as one can use file:/// references :)

> (a) Make <organization> optional: it doesn't make sense to require the 
> presence of the element, but to happily accept an empty value.

+1

> (b) Make <date> optional: for the same reasons:

+1

Really, only title and author should be required.  And date could be
required provided there's a way to say "circa 1980" (c. 1980).

> (c) As suggested by John Klensin, add a way so that we can specify that 
> a document reference is historic; thus disabling the logic in xml2rfc 
> which claims "work in progress" even though the ID is known to be expired.

+1

Nico
-- 
>From nobody at xyzzy.claranet.de  Tue Apr 10 19:28:33 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr 10 09:31:45 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> I was thinking of the text that the RFC Editor gets for publication,
> not the result.

> *That* version can contain normative ID references; and will be
> published (if all other things are done) once the ID is published
> as RFC as well.

Then it's in one of those "waiting for a reference" states in the
RFC editor queue, for an example (USEFOR waiting for USEPRO) see
<http://www.rfc-editor.org/queue.html#draft-ietf-usefor-usefor>

> If the ID being referred to *changes* between the time a document
> is approved, and the time it gets published, this requires manual
> checking that the reference is still good.

Sure, the authors know this, otherwise they wouldn't introduce such
pending references.  In some cases an AD insisted on using 2234bis
instead of 2234 because 2234bis was already approved.  Black magic
to accelerate the publication of an approved I-D waiting for its
number in the slower "non-WG" queue.

In another case an I-D had an informative reference to 2476bis (in
that case it was my idea to test the black magic ;-), for unknown
reasons the approved 2476bis didn't move.  In theory the authors and
the RFC editor could have "fixed" this with s/2476bis/2476/, but in
practice 2476bis was published in time.

Normally nobody wants references to moving targets in a published
RFC, either the "work in progress" is actually dead, or the RFC
waits for its references.  Or the reference isn't essential, e.g.
a pointer to related work, a part of the credits, etc.

We've already discussed the "work in progress" actually long dead
case here, but I don't recall what the outcome was because I found
a way to avoid the "work in progress" blurb for long dead I-Ds.

For moving targets (neither approved nor expired) the authors and
the RFC editor will check the state of the art before publication.

> Well, they still need to know even if it's informative. Having
> a bad *informative* reference is less bad, but it's still bad.

Yes, compare chapter 3.4 in RFC 4714.

Frank

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Apr 10 10:17:01 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> OK,
>
> here's a complete proposal. We change
>
+1 for the reference proposal - the 'URI as a relative reference' 
comment is important here:
> <!ELEMENT reference   (front,seriesInfo*,format*,annotation*)>
> <!ATTLIST reference
>           anchor      ID                 #IMPLIED
>           target      %URI;              #IMPLIED>
>
> to
>
> <!ELEMENT reference   (include|(front,seriesInfo*,format*,annotation*))>
> <!ATTLIST reference
>           anchor      ID                 #IMPLIED
>           target      %URI;              #IMPLIED>
> <!ELEMENT include     ( EMPTY>
> <!ATTLIST include
>           src         %URI;              #IMPLIED>
>
>
> So a <reference> either is the same thing as before (<front> and 
> optional metadata), *or* it contains a single <include> element.
>
> <include> is empty, and has a single required attribute, specifying 
> the URI (or relative reference) from where the reference should be 
> included. The inclusion process copies all attributes of the external 
> <reference> element that haven't been set in the parent <reference> 
> element, plus all child elements.
>
> For instance, to use [HTTP] to refer to RFC2616, one would say:
>
> <reference anchor="HTTP">
>   <include 
> src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/>
> </reference>
>
>
> The benefit here is that we don't rely on pseudo-attributes in PIs 
> (fragile to parse), and the source document stays DTD-valid.
>
> That being said, *if* we do this change I'd also recommend three more 
> changes:
>
> (a) Make <organization> optional: it doesn't make sense to require the 
> presence of the element, but to happily accept an empty value.
>
> <!ELEMENT author      (organization?,address?)>
Currently if all the name attributes are empty, the organization is 
used:  I guess this change doesn't really cause a problem with this.
>
> (b) Make <date> optional: for the same reasons:
>
> <!ELEMENT front       (title,author+,date?,area*,workgroup*,keyword*,
>                        abstract?,note*)>
Probably.
>
> (c) As suggested by John Klensin, add a way so that we can specify 
> that a document reference is historic; thus disabling the logic in 
> xml2rfc which claims "work in progress" even though the ID is known to 
> be expired.
>
> <!ATTLIST reference
>           anchor      ID                 #IMPLIED
>           historic    (true|false)       "false"
>           target      %URI;              #IMPLIED>
>
+1.

/Elwyn
>
> Best regards, Julian
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From julian.reschke at gmx.de  Tue Apr 10 21:58:35 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Apr 10 11:58:55 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke schrieb:
> OK,
> 
> here's a complete proposal. We change
> 
> <!ELEMENT reference   (front,seriesInfo*,format*,annotation*)>
> <!ATTLIST reference
>           anchor      ID                 #IMPLIED
>           target      %URI;              #IMPLIED>
> 
> to
> 
> <!ELEMENT reference   (include|(front,seriesInfo*,format*,annotation*))>
> <!ATTLIST reference
>           anchor      ID                 #IMPLIED
>           target      %URI;              #IMPLIED>
> <!ELEMENT include     ( EMPTY>
> <!ATTLIST include
>           src         %URI;              #IMPLIED>
> 
> 
> So a <reference> either is the same thing as before (<front> and 
> optional metadata), *or* it contains a single <include> element.
> 
> <include> is empty, and has a single required attribute, specifying the 
> URI (or relative reference) from where the reference should be included. 
> The inclusion process copies all attributes of the external <reference> 
> element that haven't been set in the parent <reference> element, plus 
> all child elements.
> 
> For instance, to use [HTTP] to refer to RFC2616, one would say:
> 
> <reference anchor="HTTP">
>   <include 
> src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/>
> </reference>
> 
> 
> The benefit here is that we don't rely on pseudo-attributes in PIs 
> (fragile to parse), and the source document stays DTD-valid.
> ...

For the record, I just did a prototype implementation for rfc2629.xslt, 
and it seems to work as desired...

Best regards, Julian
>From dave at cridland.net  Tue Apr 10 21:05:43 2007
From: dave at cridland.net (Dave Cridland)
Date: Tue Apr 10 12:05:55 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]>
 <[email-masked]> <[email-masked]>
 <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue Apr 10 19:58:35 2007, Julian Reschke wrote:
> Julian Reschke schrieb:
>> For instance, to use [HTTP] to refer to RFC2616, one would say:
>> 
>> <reference anchor="HTTP">
>>   <include 
>> src="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"/>
>> </reference>

> For the record, I just did a prototype implementation for 
> rfc2629.xslt, and it seems to work as desired...

I like this too - it's close to what I'm doing anyway with XSL 
preprocessing, and I'd be happier with a standard solution.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From nobody at xyzzy.claranet.de  Wed Apr 11 09:08:03 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr 10 23:08:29 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:

> <!ATTLIST include
>           src         %URI;              #IMPLIED>

#REQUIRED ?

> <include> is empty, and has a single required attribute, specifying
> the  URI (or relative reference) from where the reference should be
> included.

Relative to which base, the processed xml file ?

> the source document stays DTD-valid.

Yes, but validators will miss issues in the included bibxml files.

> (a) Make <organization> optional
[...]
> (b) Make <date> optional

+1  I'm not sure about the <date> in references, a dummy <date />
in the "real" <front> doesn't hurt.  But a missing <date> in a
reference <front> would be utter dubious.

> historic    (true|false)       "false"

Odd.  Just using a different series info already disables the logic
adding "work in progress", example:

<reference
 anchor='I-D.gilman-news-url'
 target='http://esw.w3.org/topic/UriSchemes/snews'>
 <front>
  <title>The 'news' URL scheme</title>
  <author initials='A.' surname='Gilman'
   fullname='Alfred S. Gilman'>
   <organization />
  </author>
  <date month='March' day='9' year='1998' />
 </front>
 <seriesInfo name='Internet' value='draft-gilman-news-url-02' />
 <format type='TXT'
  target='http://esw.w3.org/topic/UriSchemes/news?etc.etc.txt' />
</reference>

Frank

P.S.:  Was webmaster@ the correct address to submit all references
       found in 4646, 4647, and another document ?

From: simon at josefsson.org (Simon Josefsson)
Date: Wed Apr 11 00:18:23 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
In-Reply-To: <[email-masked]> (Marshall Rose's message of "Mon\, 9 Apr 2007 12\:41\:32 -0700")
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose <[email-masked]> writes:

>>> the default will not change, because that would create surprises
>>> for people.
>>
>> +1.
>
> hi. i guess i'm going to flip-flop my position on this.

Thank you for reconsidering!

> what i'd like to do is change the default, and add a warning for
> documents that don't specify symrefs that tells them the default has
> changed. we can keep the warning in for a couple of releases.
>
> does that *really* annoy anyone?

No, that seems fine with me.

/Simon
>From julian.reschke at gmx.de  Wed Apr 11 11:23:25 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Apr 11 01:23:48 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Frank Ellermann schrieb:
> Julian Reschke wrote:
> 
>> <!ATTLIST include
>>           src         %URI;              #IMPLIED>
> 
> #REQUIRED ?

Yes.

>> <include> is empty, and has a single required attribute, specifying
>> the  URI (or relative reference) from where the reference should be
>> included.
> 
> Relative to which base, the processed xml file ?

Yes.

>> the source document stays DTD-valid.
> 
> Yes, but validators will miss issues in the included bibxml files.

That's right, and the only way to avoid that is to include them in-line 
or by entity reference. I think that's sufficient, but for some reason 
people don't seem to be satisfied with that.

At least it keeps the document valid, as compared to the PI-based inclusion.

>> (a) Make <organization> optional
> [...]
>> (b) Make <date> optional
> 
> +1  I'm not sure about the <date> in references, a dummy <date />
> in the "real" <front> doesn't hurt.  But a missing <date> in a
> reference <front> would be utter dubious.

Well, I've seen documents on the Standards Track where a citation didn't 
have a date, and where I was unable to find it. What should people do? 
Make it up?

>> historic    (true|false)       "false"
> 
> Odd.  Just using a different series info already disables the logic
> adding "work in progress", example:
> ...

Yes, but it also disables Internet-Draft related machinery in other 
tools, such as reference checkers.

Best regards, Julian
>From nobody at xyzzy.claranet.de  Wed Apr 11 18:27:16 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Apr 11 08:28:37 2007
Subject: [xml2rfc] Re: Change default to use symbolic references?
References: <[email-masked]><[email-masked]><[email-masked]><[email-masked]><[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
 
>>> the source document stays DTD-valid.

>> Yes, but validators will miss issues in the included bibxml files.
 
> That's right, and the only way to avoid that is to include them
> in-line or by entity reference. I think that's sufficient,

ACK, I mentioned it JFTR, maybe Bill's validator could check the
included stuff.

> for some reason people don't seem to be satisfied with that.

I don't think so, the quick shots PI or entity name would be hacks.

Your <include> idea is cleaner, and it's not (much) more work than
fiddling with entitities in the DTD subset.

The README should recommend absolute http or ftp URIs, or a kind
of "canonical" organization working locally, with Bill's validator,
with the three xml2rfc online tools on all three servers, and at
the RFC editor site - for relative file-URLs.

Or maybe the xml2rfc xml output could eliminate all <include> it
can resolve to get a portable source working almost everywhere (?)

 [optional vs. mandatory date]
> I've seen documents on the Standards Track where a citation didn't
> have a date, and where I was unable to find it. What should people
> do? Make it up?

CDATA <shrug><date year="trad." /></shrug>  Seriously, if authors
have no clue when their reference was created they shouldn't use it.

>>> historic    (true|false)       "false"

>> Odd.  Just using a different series info already disables the
>> logic adding "work in progress", example:
>> ...
 
> Yes, but it also disables Internet-Draft related machinery in other
> tools, such as reference checkers.

An expired I-D officially doesn't exist anymore.  And officially
existing I-Ds must be cited as "work in progress", unless one of
the numerous 2026 updates updated also this rule.  So if I want a
reference to son-of-1036 or Gilman's snews I'm already forced to
reference this as something that's no Internet Draft anymore.

Additional obsctacles:  I can't tell if the s-o-1036 author ever
submited his I-D, and even if he did it's not on the tools server,
it's 12 years old.  And for the nine years old Gilman I-D I need
version -02, apparently never submitted, the IETF tools server has
only -01.  

Maybe the README could recommend a common practice for such cases,
e.g. using name="Historical Draft" in <seriesInfo> or similar.  My
hack name="Internet" depends on the text output style, it could
cause havoc for HTML output or your XSLT magic.

With a recommended name it would be also possible to fix all I-Ds
in the bibxml repository older than say five years.  Semantically
I think it's a question of the series, not an attribute of I-Ds.

Frank

From: thomas.morin at orange-ftgroup.com (Thomas Morin)
Date: Fri Apr 13 02:35:59 2007
Subject: [xml2rfc] AUTH48 review with XML source / RFC Editor comments
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1176456944.26101.15.camel@wintermute>

Hello,

[cc'ing xml2rfc mailing list]

[email-masked] :
>
> RFC AUTHOR(S):
> --------------
> 
> ** AUTH48 in XML:
> ** This document is part of a trial of using the XML source file to
> ** submit changes during AUTH48. Please see instructions below.
[...]

> Please be sure to address comments/questions that we have inserted 
>    into the XML file.  These are marked as:
> 
>       <!-- RFC Editor Comment: ... -->   

I would like to suggest that instead of "<!-- RFC Editor Comment: -->",
a "<cref source="RFC Editor">..</cref>" tag should be used to mark RFC
Editor comments (and authors could also reply to these comments). This
would allow the comments to appear in the .txt outputs, and thus in the
diff files that are sent along with the RFC Editor reviewed version
(making them less easy to miss).   

There is one slight issue: some XML editing tools (well, at least
XMLMind) do not include XML attribute values in the text search; to cope
with such editors, the "RFC Editor" could be included both as "source"
attribute of cref, and in the tag itself (e.g. <cref source="RFC
Editor">RFC Editor: </cref>).

Thank you,

-Thomas

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Fri Apr 13 04:17:47 2007
Subject: [xml2rfc] Re: AUTH48 review with XML source / RFC Editor comments
References: <[email-masked]> <1176456944.26101.15.camel@wintermute>
Message-ID: <[email-masked]>

Thomas Morin wrote:
 
> I would like to suggest that instead of "<!-- RFC Editor Comment: -->",
> a "<cref source="RFC Editor">..</cref>" tag should be used to mark RFC
> Editor comments (and authors could also reply to these comments).

Makes sense, for anything more elaborated than "read the XML source".
We'd need a tutorial how to use <cref> efficiently for collaborations.

I've never used it so far, and vaguely recall that there are two "PIs"
(show comments + show them inline).  Some days ago John noted that
<cref> can't be inserted whereever it pleases you.

Frank

From: tony at att.com (Tony Hansen)
Date: Fri Apr 13 06:11:34 2007
Subject: [xml2rfc] Re: AUTH48 review with XML source / RFC Editor comments
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1176456944.26101.15.camel@wintermute> <[email-masked]>
Message-ID: <[email-masked]>

<?rfc comments="yes"?>
<?rfc inline="yes"?>

Frank Ellermann wrote:
> I've never used it so far, and vaguely recall that there are two "PIs"
> (show comments + show them inline).  Some days ago John noted that
> <cref> can't be inserted whereever it pleases you.

From: hagens at ISI.EDU (Alice Hagens)
Date: Fri Apr 20 19:57:48 2007
Subject: [xml2rfc] AUTH48 review with XML source / RFC Editor comments
In-Reply-To: <1176456944.26101.15.camel@wintermute>
References: <[email-masked]> <1176456944.26101.15.camel@wintermute>
Message-ID: <[email-masked]>

Thomas,

Appreciate the suggestion. Having experimented a bit with cref, it  
seems to lack some of the directness and flexibility with insertion  
and formatting that <!-- comments --> give us.  See below for examples.

Also, I'm not sure that having queries appear inline in the text  
output is a mutual goal. When they are in the text output (i.e., show  
up in the diff file), they affect page breaks.

We are still trying out the process of exchanging the XML source file  
with authors during AUTH48 (28 documents so far), so please keep  
sending along feedback.

Thanks,

Alice
for the RFC Editor

----------------------
EXAMPLE 1 (basic)

comment in XML:
<!-- [rfced] Should that be "above it"? -->

cref in XML:
<cref source="RFC Editor">RFC Editor: Should that be "above it"?</cref>

text output:
[[anchor4: RFC Editor: Should that be "above it"? --RFC Editor]]

text output if anchor="Q1":
[[Q1: RFC Editor: Should that be "above it"? --RFC Editor]]

EXAMPLE 2 (diagram)

comment in XML:
<!-- [rfced] In the figure below, should the Received Ver. be as  
follows?
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   |    Version    | Received Ver. |    Sub-Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-->

cref in XML:
<t><cref anchor="Q2" source="RFC Editor">RFC Editor: In the figure  
below, should
the Received Ver. be as follows?
<artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   |    Version    | Received Ver. |    Sub-Type   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</cref></t>

text output:
    [[Q2: RFC Editor: In the figure below, should the Received Ver. be
    as follows? --RFC Editor]]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Reserved   |    Version    | Received Ver. |    Sub-Type   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

On Apr 13, 2007, at 2:35 AM, Thomas Morin wrote:

> Hello,
>
> [cc'ing xml2rfc mailing list]
>
> [email-masked] :
>>
>> RFC AUTHOR(S):
>> --------------
>>
>> ** AUTH48 in XML:
>> ** This document is part of a trial of using the XML source file to
>> ** submit changes during AUTH48. Please see instructions below.
> [...]
>
>> Please be sure to address comments/questions that we have inserted
>>    into the XML file.  These are marked as:
>>
>>       <!-- RFC Editor Comment: ... -->
>
> I would like to suggest that instead of "<!-- RFC Editor Comment: -- 
> >",
> a "<cref source="RFC Editor">..</cref>" tag should be used to mark RFC
> Editor comments (and authors could also reply to these comments). This
> would allow the comments to appear in the .txt outputs, and thus in  
> the
> diff files that are sent along with the RFC Editor reviewed version
> (making them less easy to miss).
>
> There is one slight issue: some XML editing tools (well, at least
> XMLMind) do not include XML attribute values in the text search; to  
> cope
> with such editors, the "RFC Editor" could be included both as "source"
> attribute of cref, and in the tag itself (e.g. <cref source="RFC
> Editor">RFC Editor: </cref>).
>
> Thank you,
>
> -Thomas
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Apr 24 10:39:45 2007
Subject: [xml2rfc] validator.w3.org / xml.resource.org
Message-ID: <[email-masked]>

Hi, I tried to use validator-test.w3.org with an xml2rfc source,
and got tons and tons of errors, so I guess that's an issue or
feature of this test version.

To check what's going on I then tested validator.w3.org, and I
*think* (could be wrong) that this used to report no errors.

Today I get various errors, some of them in the style 

| Error Line 547 column 8: error connecting to 
| "xml.resource.org" (Connection refused).

That's for the tenth external entity &rfc3977; in the validated
document, is there some limit how many entities the validator
can fetch from xml.resource.org, or how fast it should do that ?

The other errors with http://validator.w3.org are in the style 

| Warning Line 239 column 9: cannot generate system identifier
| for general entity "nbsp".

Maybe the 2 *.ent files with the entities are not more available
where they used to be available (?), nbsp was defined in file
rfc2629-xhtml.ent

Some errors are rather cryptic:

| Line 762, Column 45: reference to non-existent ID "RFC3977". 

That's an <xref target="RFC3977" />, the DTD says it's an IDREF,
the validator never got the external entity &rfc3977;, and so it
reports a missing ID for the IDREF.  

I think the new validator could abort all efforts to validate a
document, if anything with fetching external documents doesn't 
work.  It should report what went wrong with fetching external
documents as good as possible.  It should not say that a source
is "invalid" only because it was unable to fetch the required
external documents, IMO that's "inconclusive", not "invalid".

BTW, we're not talking about hundreds of external documents in
this example, it's one DTD, two *.ent files, and about twenty
"bibxml" snippets.  An approach like "fetch at most one file
per server and second" would be fine, if that doesn't trigger
the xml.resource.org limit.

Frank

From: pcalhoun at cisco.com (Pat Calhoun (pacalhou))
Date: Wed Apr 25 10:06:39 2007
Subject: [xml2rfc] Question about Internet Draft References
Message-ID: <[email-masked]>

All,
 
I'm working on the CAPWAP drafts, and am getting close to WGLC. However,
I have never been able to really get the I-D references to work
properly. I took a look at the online tutorial, but it is still cryptic.
 
So here is how I do RFC references:
      <?rfc include="reference.RFC.2132" ?> [...]
	this document are to be interpreted as described in <xref
target="RFC2119">
	RFC 2119</xref>.</t> 

And from what I can tell, the following is how I should do I-D
references:
      <?rfc
include="reference.I-D.ietf-capwap-protocol-binding-ieee80211" ?> 
[...]
	The CAPWAP protocol binding which defines extensions for use
with the IEEE
	802.11 wireless LAN protocol is available in
	<xref
target="draft-ietf-capwap-protocol-binding-ieee80211"></xref>.

I've also tried removing draft- from the target and that also does not
work.

Any thoughts?

PatC

From: jabley at ca.afilias.info (Joe Abley)
Date: Wed Apr 25 10:51:33 2007
Subject: [xml2rfc] Question about Internet Draft References
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 25-Apr-2007, at 18:06, Pat Calhoun (pacalhou) wrote:

> I've also tried removing draft- from the target and that also does not
> work.

There's no special magic with this -- you can just take a look at the  
file you're pulling down and implicitly including in your xml source,  
and see what anchor it specifies.

For example:

[calamari:~]% curl http://xml.resource.org/public/rfc/bibxml3/ 
reference.I-D.ietf-dnsop-as112-ops.xml | grep anchor
   % Total    % Received % Xferd  Average Speed   Time    Time      
Time  Current
                                  Dload  Upload   Total   Spent     
Left  Speed
100  1716  100  1716    0     0    984      0  0:00:01  0:00:01  
--:--:--     0
<reference anchor='I-D.ietf-dnsop-as112-ops'>
[calamari:~]%

There, the file I downloaded included the anchor "I-D.ietf-dnsop- 
as112-ops", and that's what I would expect to use in the target  
attribute on any corresponding xref elements. You might try doing the  
same thing with the URL for the draft you are trying to cite; if you  
don't have a command line, you might try pulling it into a browser  
and then using "view source".

Joe

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Apr 25 12:54:57 2007
Subject: [xml2rfc] Question about Internet Draft References
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Pat Calhoun (pacalhou) wrote:
> All,
>  
> I'm working on the CAPWAP drafts, and am getting close to WGLC. However,
> I have never been able to really get the I-D references to work
> properly. I took a look at the online tutorial, but it is still cryptic.
>  
>   
I take it you mean the one on the RFC Editor's site: 
http://www.rfc-editor.org/formatting.html

Thanks for the feedback.  We are looking at a 'quickstart' guide to get people going and feedback about what still confuses people is very valuable.

/Elwyn

From: dhc2 at dcrocker.net (Dave Crocker)
Date: Tue May  1 13:45:15 2007
Subject: [xml2rfc] Using latest referencess
Message-ID: <[email-masked]>

This is a bit of fantasy that struck me as interesting.  I've no idea how much 
effort it would take -- or event whether it is feasible -- but it seems like a 
capability that would be useful to others:

When working on a document for a long time, or when revising a previously 
published document, references can become innaccurate, such as by being made 
obsolete when a later version is issued.  Sometimes, the older reference is 
still desired, but much of the time, we simply want the most current one.

I-D references do this automatically, but of course RFC ones don't.  Nor when 
an I-D becomes an RFC.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue May  1 14:05:16 2007
Subject: [xml2rfc] Using latest referencess
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dave Crocker wrote:
> This is a bit of fantasy that struck me as interesting.  I've no idea 
> how much effort it would take -- or event whether it is feasible -- but 
> it seems like a capability that would be useful to others:
> 
> When working on a document for a long time, or when revising a 
> previously published document, references can become innaccurate, such 
> as by being made obsolete when a later version is issued.  Sometimes, 
> the older reference is still desired, but much of the time, we simply 
> want the most current one.
> 
> I-D references do this automatically, but of course RFC ones don't.  Nor 
> when an I-D becomes an RFC.

Well, in general the update can't be made automatic.

What can be done easily is a check for the freshness of references, see 
the latest versions of ID-Nits and 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>.

Best regards, Julian
>From henrik at levkowetz.com  Wed May  2 00:54:40 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Tue May  1 14:54:51 2007
Subject: [xml2rfc] Using latest referencess
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

on 2007-05-01 23:04 Julian Reschke said the following:
> Dave Crocker wrote:
...
>> I-D references do this automatically, but of course RFC ones don't.  Nor 
>> when an I-D becomes an RFC.
> 
> Well, in general the update can't be made automatic.
> 
> What can be done easily is a check for the freshness of references, see 
> the latest versions of ID-Nits and 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>.

Yes, idnits catches references to drafts that have later revisions and to
RFCs which have been obsoleted.

I don't know how much functionality should be added to xml2rfc, and how
much to idnits in this respect; although it's always tempting to add
functionality to a tool to make it more capable, I think one basic
guideline should be that a tool should fulfil its basic mission, and do
that particular job well, rather than be an 'everything and the kitchen
sink' tool.

I'm now considering idnits as a draft 'lint' tool, and will continue to
develop it in that direction (unless getting clear push-back against doing
so), so you can expect to use it on a draft as you'd use lint on a C file.

Additional functionality suggestions and comments regarding idnits as a
lint-like tool are very welcome; and are best sent to [email-masked].

	Henrik
>From lear at cisco.com  Wed May  2 20:14:29 2007
From: lear at cisco.com (Eliot Lear)
Date: Wed May  2 10:14:40 2007
Subject: [xml2rfc] 
	[resending]  possible pub in 1.32 w/ anchor handling and references?
Message-ID: <[email-masked]>

With 1.32, I found an oddity when filling out a URI template.  Instead 
of replacing the text in the target with "Normative References", I got 
"[6.2]".  Is that an programming or operator error?

Thanks,

Eliot
>From dhc2 at dcrocker.net  Wed May  2 12:39:56 2007
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Wed May  2 11:40:32 2007
Subject: [xml2rfc] Using latest referencess
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
>> When working on a document for a long time, or when revising a 
>> previously published document, references can become innaccurate, such 
>> as by being made obsolete when a later version is issued.  Sometimes, 
>> the older reference is still desired, but much of the time, we simply 
>> want the most current one.
...
> What can be done easily is a check for the freshness of references, see 
> the latest versions of ID-Nits and 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>. 

This is perfect.  Thanks for pointing me at it.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From john+xml at jck.com  Wed May  2 16:55:20 2007
From: john+xml at jck.com (John C Klensin)
Date: Wed May  2 12:55:29 2007
Subject: [xml2rfc] Using latest referencess
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <8963D337EE403E086CDE10F2@[192.168.1.110]>

--On Tue, 01 May 2007 23:54:40 +0200, Henrik Levkowetz 
<[email-masked]> wrote...

>...
> Yes, idnits catches references to drafts that have later
> revisions and to RFCs which have been obsoleted.
>
> I don't know how much functionality should be added to
> xml2rfc, and how much to idnits in this respect; although it's
> always tempting to add functionality to a tool to make it more
> capable, I think one basic guideline should be that a tool
> should fulfil its basic mission, and do that particular job
> well, rather than be an 'everything and the kitchen sink' tool.
>
> I'm now considering idnits as a draft 'lint' tool, and will
> continue to develop it in that direction (unless getting clear
> push-back against doing so), so you can expect to use it on a
> draft as you'd use lint on a C file.
>
> Additional functionality suggestions and comments regarding
> idnits as a lint-like tool are very welcome; and are best sent
> to [email-masked].

Let me repeat a suggestion I made in another context some time 
ago ... making it here because it would impact the syntax 
accepted by xml2rfc although not anything it needs to do.   The 
key to having an "obsolete reference" analyzer be useful is to 
have information available about whether a document reference is 
stable or whether it is subject to change as things evolve. 
This applies equally to RFCs, I-Ds, and published books -- the 
only difference is that, if one is thinking about defaults, they 
might differ by category.  And the only person who knows is the 
author -- tools can't make this up.

So, while I agree that the work should be done in a lint-like 
tool and that idnits is the right sort of tool, I'd like to have 
the ability to include a stability attribute in the reference 
element.  Xml2rfc should presumably just ignore it, but it could 
be hugely helpful for validation checkers.

     john

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed May  2 13:07:32 2007
Subject: [xml2rfc] Re: Using latest referencess
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Henrik Levkowetz wrote:
 
> I don't know how much functionality should be added to xml2rfc,
> and how much to idnits in this respect

With <?rfc strict="yes" ?> I get warnings when I write about say
RFC 1738.

> one basic guideline should be that a tool should fulfil its 
> basic mission, and do that particular job well, rather than be
> an 'everything and the kitchen sink' tool.

Yes, e.g. "strict" checks can be annoying for type="abnf", but
OTOH nobody forces me to use type="abnf" when I don't like it ;-)

> I'm now considering idnits as a draft 'lint' tool, and will
> continue to develop it in that direction (unless getting clear
> push-back against doing so), so you can expect to use it on a
> draft as you'd use lint on a C file.

At some points this might be also annoying, e.g. for authors
following Bruce Lilly's style, defining only those 2119 keywords
which are later actually used in the draft.  Or John said a few
days ago that he's not going to change e.g. the Postel address
in 2821bis to an "example" address, for such cases there must be
a way to bypass stupid scripts when they try to outsmart authors.

Frank

From: fenner at research.att.com (Bill Fenner)
Date: Mon May  7 08:05:45 2007
Subject: [xml2rfc]  [resending]  possible pub in 1.32 w/ anchor handling and references?
Message-ID: <[email-masked]>

>With 1.32, I found an oddity when filling out a URI template.  Instead 
>of replacing the text in the target with "Normative References", I got 
>"[6.2]".  Is that an programming or operator error?

Eliot,

  I'm afraid there's not enough shared state for me to be able to make
head or tail of this report.  Could you share the xml file that generates
the output that you think is wrong?

Thanks,
  Bill
>From dbharrington at comcast.net  Tue May 15 17:42:33 2007
From: dbharrington at comcast.net (David B Harrington)
Date: Tue May 15 13:42:48 2007
Subject: [xml2rfc] unpaginated bug?
Message-ID: <[email-masked]>

Hi,

I am trying to use the unpaginated option on the xml2rfc web page.
My file uses ENTITY to include bibxml entries
<!ENTITY rfc2579 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">

I am getting an error:
Unable to Convert File
http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml.xml:
HTTP/1.1 404 Not Found

It appears to me the unpaginated option is appending  ".xml" to the
end of my URL. Is this a bug, or am I using the option incorrectly?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

From: dbharrington at comcast.net (David B Harrington)
Date: Tue May 15 17:03:33 2007
Subject: [xml2rfc] reference for rfc2578?
Message-ID: <[email-masked]>

Hi,

I am getting a file not found for
http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml

I am now able to get 2579, but not 2580.

I've looked at the bibxml web page, and it appears a number of
references are missing. Server problems?

David Harrington
[email-masked] 
[email-masked]
[email-masked]

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue May 15 17:13:28 2007
Subject: [xml2rfc] reference for rfc2578?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I am getting a file not found for
> http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml
>
> I am now able to get 2579, but not 2580.
>
> I've looked at the bibxml web page, and it appears a number of
> references are missing. Server problems?

it looks like it.

bill - www2.xml.resource.org appears to be missing some files.

david - www1.xml.resource.org and www3.xml.resource.org appear to  
have the complete set.

/mtr

From: fenner at gmail.com (Bill Fenner)
Date: Wed May 16 19:47:23 2007
Subject: [xml2rfc] reference for rfc2578?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

My apologies; this server had some disk problems and I assumed that
what I had done to fix them was on track; I discovered around the same
time as everyone else that it was broken and just fixed it now.  I'm
sorry for the slow response but I'm on a cross-country road trip
driving 650 miles per day so there isn't much time to work on problems
like this ;-)

  Bill
>From dbharrington at comcast.net  Thu May 17 00:01:41 2007
From: dbharrington at comcast.net (David B Harrington)
Date: Wed May 16 20:01:54 2007
Subject: [xml2rfc] reference for rfc2578?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Thanks Bill,

have a good road trip.

dbh 

> -----Original Message-----
> From: Bill Fenner [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2007 10:47 PM
> To: Marshall Rose
> Cc: David B Harrington; xml2rfc mailing list
> Subject: Re: [xml2rfc] reference for rfc2578?
> 
> My apologies; this server had some disk problems and I assumed that
> what I had done to fix them was on track; I discovered around the
same
> time as everyone else that it was broken and just fixed it now.  I'm
> sorry for the slow response but I'm on a cross-country road trip
> driving 650 miles per day so there isn't much time to work on
problems
> like this ;-)
> 
>   Bill
> 

From: fenner at gmail.com (Bill Fenner)
Date: Thu May 17 06:00:57 2007
Subject: [xml2rfc] unpaginated bug?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 5/15/07, David B Harrington <[email-masked]> wrote:
> I am getting an error:
> Unable to Convert File
> http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml.xml:
> HTTP/1.1 404 Not Found

This is fixed now, right?  This was actually reporting the missing
reference files in the bibxml directory on www2.xml.resource.org.

  Bill
>From fenner at gmail.com  Thu May 17 07:39:33 2007
From: fenner at gmail.com (Bill Fenner)
Date: Thu May 17 06:39:40 2007
Subject: [xml2rfc] Announcing 1.33pre4
Message-ID: <[email-masked]>

Hi,

  I'd like to announce another release of the development version of
1.33.  I'd like to encourage wider testing of this version, since
barring any major problems this will probably be the real 1.33.

  As usual, it's available at http://xml.resource.org/experimental.html .

  The changes since pre3 include:

- CHANGED DEFAULT ALERT: by popular demand,<?rfc symrefs=''?> now
defaults to "yes".  xml2rfc will warn if you have no <? rfc symrefs=
?> PI in the file.

- Fix bug that Elwyn reported when referencing cached versions of
included files.

- Fixed error when formatting an RFC with submissionType="independent"

- Warn when outdenting artwork to avoid overrunning right margin.

- The category attribute is now mandatory when using <?rfc strict="yes"?>.

There are a couple of outstanding issues which are not fixed in this release:

- The agreed-upon <lt> element for multi-paragraph lists.  I've
implemented the text output, but not the HTML output and haven't
tested the nroff output.  I'm swamped with other work and just haven't
had the cycles to finish this, and didn't want it to hold other stuff
up.

- artwork gets truncated if it consists of multiple CDATA segments,
e.g., if there are any processing instructions or comments inside the
artwork element.  This is a known bug but fixing it requires
restructuring a fair bit of code that I'm not familiar with, so is a
big investment that I once again haven't yet had the time to do and
don't want it to hold other stuff up.

The main reasons we want to release 1.33 are the improved XML warning
messages and the <? rfc symrefs= ?> default setting.

  Bill
>From nobody at xyzzy.claranet.de  Fri May 18 08:03:43 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu May 17 22:05:27 2007
Subject: [xml2rfc] Re: validator.w3.org / xml.resource.org
References: <[email-masked]>
Message-ID: <[email-masked]>

> Today I get various errors, some of them in the style

> | Error Line 547 column 8: error connecting to
> | "xml.resource.org" (Connection refused).

Whatever this problem was, it's gone today, working also
with the validator-test v0.8.0-beta1 and xml2rfc 1.33pre4.

Frank

From: brc at zurich.ibm.com (Brian E Carpenter)
Date: Wed May 23 00:54:42 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Are you planning to put this into the production code at some point?

   Brian

NEW: Preferred email for non-IBM matters: [email-masked]

On 2007-04-05 02:00, Bill Fenner wrote:
> http://www2.xml.resource.org/newfangled.html is a form that allows
> both reporting of warnings and download of the resulting file.  Please
> try it out and let me know how it works for you.  It uses an HTTP
> Refresh: 0; ... header to redirect you to the download and provides a
> link if the refresh doesn't work.  I've only tested it with Safari so
> far.
> 
> (IE7 feedback is particularly encouraged since I've heard that IE7
> behaves differently with this kind of refresh.)
> 
> Thanks,
>  Bill
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From fenner at gmail.com  Wed May 23 09:32:23 2007
From: fenner at gmail.com (Bill Fenner)
Date: Wed May 23 07:32:32 2007
Subject: [xml2rfc] Please try newfangled warning reporting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 5/23/07, Brian E Carpenter <[email-masked]> wrote:
> Are you planning to put this into the production code at some point?

I suppose the perfect is being the enemy of the good here.  I got
enough feedback like "this is good but wouldn't it be better if ___"
and haven't had enough time to ___ that it's been stalled.

If we keep it as a seperate option, then there's no reason not to just
deploy it.  If it is lacking some abilities then people can still use
the older options.

(Anyone have a better name for the radio button choice than "newfangled"?)

  Bill
>From dhc2 at dcrocker.net  Thu May 24 09:39:42 2007
From: dhc2 at dcrocker.net (Dave Crocker)
Date: Thu May 24 08:40:50 2007
Subject: [xml2rfc] one-word boilerplate error
Message-ID: <[email-masked]>

Howdy.

The IETF nits tool reports:

>   == The document seems to lack the recommended RFC 2119 boilerplate, even if
>      it appears to use RFC 2119 keywords -- however, there's a paragraph with
>      a matching beginning. Boilerplate error?
> 
>      RFC 2119 paragraph 2 text:
>      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>       this document are to be interpreted as described in RFC 2119."     
> 
>      ... text found in draft:
>      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>       this document are to be interpreted as specified in RFC 2119
> .............................................^
>       [RFC2119].")

I have used the xml2rfc version on the resource.org web site, as well as the 
latest tcl version.  Both generate this error report on using 'specified' 
instead of 'described'.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
>From julian.reschke at gmx.de  Thu May 24 18:55:57 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu May 24 08:56:16 2007
Subject: [xml2rfc] one-word boilerplate error
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dave Crocker wrote:
> Howdy.
> 
> 
> The IETF nits tool reports:
> 
>>   == The document seems to lack the recommended RFC 2119 boilerplate, 
>> even if
>>      it appears to use RFC 2119 keywords -- however, there's a 
>> paragraph with
>>      a matching beginning. Boilerplate error?
>>
>>      RFC 2119 paragraph 2 text:
>>      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>       this document are to be interpreted as described in RFC 2119."    
>>      ... text found in draft:
>>      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
>>       this document are to be interpreted as specified in RFC 2119
>> .............................................^
>>       [RFC2119].")
> 
> 
> I have used the xml2rfc version on the resource.org web site, as well as 
> the latest tcl version.  Both generate this error report on using 
> 'specified' instead of 'described'.

:-)

It took me some time until I realized that that text is in your XML 
source, and isn't generated by xmlrfc at all.

Best regards, Julian
>From dbharrington at comcast.net  Thu May 24 19:23:53 2007
From: dbharrington at comcast.net ([email-masked])
Date: Thu May 24 11:23:59 2007
Subject: [xml2rfc] Please try newfangled warning reporting
Message-ID: <052420071823[email-masked]>

How about "debug"?

dbh

-------------- Original message -------------- 
From: "Bill Fenner" <[email-masked]> 

> On 5/23/07, Brian E Carpenter wrote: 
> > Are you planning to put this into the production code at some point? 
> 
> I suppose the perfect is being the enemy of the good here. I got 
> enough feedback like "this is good but wouldn't it be better if ___" 
> and haven't had enough time to ___ that it's been stalled. 
> 
> If we keep it as a seperate option, then there's no reason not to just 
> deploy it. If it is lacking some abilities then people can still use 
> the older options. 
> 
> (Anyone have a better name for the radio button choice than "newfangled"?) 
> 
> Bill 
> _______________________________________________ 
> xml2rfc mailing list 
> [email-masked] 
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070524/2224c5aa/attachment.htm
>From lars.eggert at nokia.com  Wed May 30 12:11:41 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Wed May 30 01:12:18 2007
Subject: [xml2rfc] xml2rfc & proxies
Message-ID: <[email-masked]>

Hi,

I'm trying to process an xml file that uses entity declarations to  
download references from xml.resource.org, but I'm behind a company  
proxy.

I saw that xml2rfc uses the Tcl autoproxy package and I have set the  
usual Unix environment variables (and they work with wget curl,  
etc.), but retrieval of the references still fails.

Anyone have any smart ideas?

Thanks,
Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070530/54582462/smime.bin
>From fenner at gmail.com  Wed May 30 11:59:20 2007
From: fenner at gmail.com (Bill Fenner)
Date: Wed May 30 07:59:29 2007
Subject: [xml2rfc] xml2rfc & proxies
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 5/30/07, Lars Eggert <[email-masked]> wrote:
> I saw that xml2rfc uses the Tcl autoproxy package and I have set the
> usual Unix environment variables (and they work with wget curl,
> etc.), but retrieval of the references still fails.

Do you have autoproxy available?  It's part of tcllib, which is a
different package from tcl on many systems.  xml2rfc silently fails to
use autoproxy if it's not installed.

  Bill
>From lars.eggert at nokia.com  Wed May 30 19:49:59 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Wed May 30 08:50:28 2007
Subject: [xml2rfc] xml2rfc & proxies
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 2007-5-30, at 17:59, ext Bill Fenner wrote:
> On 5/30/07, Lars Eggert <[email-masked]> wrote:
>> I saw that xml2rfc uses the Tcl autoproxy package and I have set the
>> usual Unix environment variables (and they work with wget curl,
>> etc.), but retrieval of the references still fails.
>
> Do you have autoproxy available?  It's part of tcllib, which is a
> different package from tcl on many systems.  xml2rfc silently fails to
> use autoproxy if it's not installed.

Bingo. I didn't have tcllib installed, and with my tcl skills being  
limited to ns2 scripts, I didn't understand that it would fail silently.

However: I just installed tcllib via fink, and it still fails.

Here's the dump, in case that gives anyone some ideas:

http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml:  
http package failed
http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml:  
http package failed
     while executing
"error "$u: $code""
     (procedure "prexml_find_uri" line 39)
     invoked from within
"prexml_find_uri $uf $uf"
     (procedure "prexml_find" line 4)
     invoked from within
"prexml_find $arg1"
     ("SYSTEM" arm line 2)
     invoked from within
"switch -- $idtype {
                     SYSTEM {
                         set l [prexml_find $arg1]
                     }

                     PUBLIC {..."
     ("<!ENTITY" arm line 47)
     invoked from within
"switch -- $m {
             <?rfc {
                 if {![regexp -indices -start $b -- {\?>} $stream x]} {
                     prexml_error "missing cl..."
     (procedure "prexml_stream" line 60)
     invoked from within
"prexml_stream $stream [expr 1 + $n]"
     (procedure "prexml" line 43)
     invoked from within
"prexml [read $in_fd]"
     invoked from within
"xml2rfc draft-eggert-middlebox-control-survey.xml"
     ("eval" body line 1)
     invoked from within
"eval [file tail [file rootname [lindex $argv 0]]]  $file"
     ("2" arm line 20)
     invoked from within
"switch -- [llength $argv] {
             2 {
                 set file [lindex $argv 1]
                 if {![string compare $tcl_platform(platform)  wi..."

Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070530/8891749c/smime.bin
>From dwing at cisco.com  Thu May 31 15:41:37 2007
From: dwing at cisco.com (Dan Wing)
Date: Thu May 31 14:42:08 2007
Subject: [xml2rfc] 194.146.105.14 missing some XML files?
Message-ID: <[email-masked]>

xml.resource.org resolves to three addresses.  A few minutes ago, my
resolver choose 194.146.105.14 and it seems that host was missing some XML
files:

> dig +short xml.resource.org
168.143.123.173
192.20.225.40
194.146.105.14

> wget --header "Host: xml.resource.org"
http://168.143.123.173/public/rfc/bibxml/reference.RFC.4884.xml --no-verbose
--spider
200 OK

> wget --header "Host: xml.resource.org"
http://192.20.225.40/public/rfc/bibxml/reference.RFC.4884.xml --no-verbose
--spider
200 OK

> wget --header "Host: xml.resource.org"
http://194.146.105.14/public/rfc/bibxml/reference.RFC.4884.xml --no-verbose
--spider
http://194.146.105.14/public/rfc/bibxml/reference.RFC.4884.xml:
13:50:34 ERROR 404: Not Found.

-d
>From mrose at dbc.mtview.ca.us  Thu May 31 16:09:41 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu May 31 15:09:49 2007
Subject: [xml2rfc] 194.146.105.14 missing some XML files?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> xml.resource.org resolves to three addresses.  A few minutes ago, my
> resolver choose 194.146.105.14 and it seems that host was missing  
> some XML
> files:

we'll look into this. in the interim, you probably want to hardwire  
xml.resource.org to one of the other servers...

thanks,

/mtr

From: dwing at cisco.com (Dan Wing)
Date: Thu May 31 16:21:40 2007
Subject: [xml2rfc] 194.146.105.14 missing some XML files?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> > xml.resource.org resolves to three addresses.  A few minutes ago, my
> > resolver choose 194.146.105.14 and it seems that host was missing  
> > some XML
> > files:
> 
> we'll look into this. in the interim, you probably want to hardwire  
> xml.resource.org to one of the other servers...

Yep, I already did that by modifying my hosts file.

-d

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Thu May 31 17:25:43 2007
Subject: [xml2rfc] 194.146.105.14 missing some XML files?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Dan,

On 2007-05-31 23:41 Dan Wing said the following:
> xml.resource.org resolves to three addresses.  A few minutes ago, my
> resolver choose 194.146.105.14 and it seems that host was missing some XML
> files:
...
> 13:50:34 ERROR 404: Not Found.

Yes.  A cron script not running properly.  I've run it manually now,
and will follow up to find and fix the problem.

	Henrik
>From fernando at gont.com.ar  Sun Jun 10 11:44:37 2007
From: fernando at gont.com.ar (Fernando Gont)
Date: Sun Jun 10 06:49:25 2007
Subject: [xml2rfc] Problem with table layout
Message-ID: <[email-masked]>

Hi folks,

I'm having trouble to get the same layout for a table as that in 
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html

The code I'm using is:
     <texttable title="Extrapolating the concept of soft errors to 
ICMPv6" anchor="icmp-table">
         <ttcol align="center">ICMP</ttcol>
         <ttcol align="center">ICMPv6</ttcol>
         <c>Destination Unreachable (codes 0, 1, and 5)</c>
         <c>Destination Unreachable (codes 0 and 3)</c>
         <c>Time Exceeded (codes 0 and 1)</c>
         <c>Time exceeded (codes 0 and 1)</c>
         <c>Parameter Problem</c>
         <c>Parameter Problem (codes 0, 1, and 2)</c>
     </texttable>

And it results in the following table layout:
    +----------------------------------+--------------------------------+
    |               ICMP               |             ICMPv6             |
    +----------------------------------+--------------------------------+
    |  Destination Unreachable (codes  | Destination Unreachable (codes |
    |           0, 1, and 5)           |            0 and 3)            |
    |   Time Exceeded (codes 0 and 1)  |  Time exceeded (codes 0 and 1) |
    |         Parameter Problem        | Parameter Problem (codes 0, 1, |
    |                                  |             and 2)             |
    +----------------------------------+--------------------------------+

(in which the lines between the rows are missing).

Is there anything in my code, or was the layout of the reference document?

(BTW, I'm using the online tool at http://xml.resource.org)

Thanks in advance,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: dmm at 1-4-5.net (David Meyer)
Date: Wed Jun 13 07:55:05 2007
Subject: [xml2rfc] how to correct an error in something that's on xml.resource.org/public/rfc/bibxml3?
Message-ID: <[email-masked]>

	Folks,

	There's an error in 

	http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-iab-raws-report-02.xml

	How do I get that corrected?

	thnx,

	--dmm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070613/8b2f962c/attachment.bin
>From mrose at dbc.mtview.ca.us  Wed Jun 13 09:15:15 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jun 13 08:15:23 2007
Subject: [xml2rfc] how to correct an error in something that's on
	xml.resource.org/public/rfc/bibxml3?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> 	Folks,
>
> 	There's an error in
>
> 	http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-iab- 
> raws-report-02.xml
>
> 	How do I get that corrected?

what's the error, exactly? (hint: send a corrected file)

/mtr

>From dmm at 1-4-5.net  Wed Jun 13 09:22:13 2007
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Jun 13 08:22:18 2007
Subject: [xml2rfc] how to correct an error in something that's on
	xml.resource.org/public/rfc/bibxml3?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070613/b4d40bc6/attachment.bin
>From mrose at dbc.mtview.ca.us  Wed Jun 13 09:46:56 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Jun 13 08:47:10 2007
Subject: [xml2rfc] how to correct an error in something that's on
	xml.resource.org/public/rfc/bibxml3?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Jun 13, 2007, at 08:22 , David Meyer wrote:

>  Misspelled name.

in that case, contact the secretariat and ask them to correct 1id- 
abstracts.txt

/mtr

>From dmm at 1-4-5.net  Wed Jun 13 10:10:03 2007
From: dmm at 1-4-5.net (David Meyer)
Date: Wed Jun 13 09:10:09 2007
Subject: [xml2rfc] how to correct an error in something that's on
	xml.resource.org/public/rfc/bibxml3?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Wed, Jun 13, 2007 at 08:46:56AM -0700, Marshall Rose wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> On Jun 13, 2007, at 08:22 , David Meyer wrote:
> 
> > Misspelled name.
> 
> in that case, contact the secretariat and ask them to correct 1id- 
> abstracts.txt

	Thnx.

	--dmm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070613/7cc5f54a/attachment.bin
>From fenner at research.att.com  Wed Jun 13 15:56:13 2007
From: fenner at research.att.com (Bill Fenner)
Date: Wed Jun 13 11:56:20 2007
Subject: [xml2rfc] Problem with table layout
Message-ID: <[email-masked]>

Try 'style="all"' on the texttable element.  The style
attribute hasn't been fully documented.

  Bill
>From fernando at gont.com.ar  Thu Jun 14 00:43:06 2007
From: fernando at gont.com.ar (Fernando Gont)
Date: Wed Jun 13 19:47:21 2007
Subject: [xml2rfc] Problem with table layout
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

At 03:56 p.m. 13/06/2007, Bill Fenner wrote:

>Try 'style="all"' on the texttable element.  The style
>attribute hasn't been fully documented.

Thanks so much! (worked as expected)

Maybe texttable this could be established as the default? Or, if not, 
how about setting this explicitly in the example at 
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html?

Kindest regards,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Jun 21 00:59:56 2007
Subject: [xml2rfc] Bug in xml2rfc's XML parser
Message-ID: <[email-masked]>

Hi,

I just noticed that xml2rfc's XML parser accepts the character sequence 
"--" inside comments, although an XML parser needs to report a parse error.

Best regards, Julian
>From julian.reschke at gmx.de  Tue Jun 26 16:41:17 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jun 26 06:41:28 2007
Subject: [xml2rfc] Clarification about "initials" attribute
Message-ID: <[email-masked]>

Hi,

I'd like to see a clarification about how the author/@initials is to be 
processed.

Trying with different kinds of inputs, it seems that xml2rfc always just 
picks the first letter, and appends a dot.

On the other hand, the example in 
<http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html#author> 
suggests that values such as 'F.J.' are allowed, too.

Feedback appreciated (preferably from the authors of spec and TCL impl :-).

Best regards, Julian
>From Chris.Dearlove at baesystems.com  Tue Jun 26 18:38:54 2007
From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Tue Jun 26 09:39:05 2007
Subject: [xml2rfc] xml2rfc problem
Message-ID: <[email-masked]>

I, and my co-authors, have a problem with one of our
current Internet Drafts, as xml2rfc isn't doing the
right thing with it. At the end is a close to minimal
example of the problem, the point being that the final
text includes

1.  Problem

   1.  Number

       *  Bullet

       2.  Number

rather than

1.  Problem

   1.  Number

       *  Bullet

       1.  Number

Does anyone have a workaround for this, and is this the
right place for fault reporting that will feed into
updating xml2rfc? Thanks in advance for any help.

<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc ipr="full3978" category="std" docName="test-00">

  <front>
    <title abbrev="Test">Test</title>
    <author fullname="No One">
      <organization>Nowhere</organization>
    </author>
    <date month='June' year='2007'/>
    <area>SPQR</area>
    <workgroup>XYZ WG</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet Draft</keyword>
    <abstract>
    </abstract>
  </front>

  <middle>

    <section title="Problem">

      <list style="numbers">

        <t>
          Number

          <list style="symbols">
            <t>Bullet</t>
          </list>

          <list style="numbers">
            <t>Number</t>
          </list>

        </t>

     </list>

    </section>

  </middle>

  <back>
  </back>

</rfc>

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Tue Jun 26 13:11:41 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Seems to be a bug in the formatter.  Also the outside list needs to be 
embedded in a <t>.

Use Bill fenner's validator to help. 
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

Here is a workaround using the format style.

<?xml version="1.0" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc ipr="full3978" category="std" docName="test-00">

  <front>
    <title abbrev="Test">Test</title>
    <author fullname="No One">
      <organization>Nowhere</organization>
    </author>
    <date month='June' year='2007'/>
    <area>SPQR</area>
    <workgroup>XYZ WG</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet Draft</keyword>
    <abstract><t>abstract text</t>
    </abstract>
  </front>

  <middle>

    <section title="Problem">
    <t>

      <list style="numbers">

        <t>
          Number

          <list style="symbols">
            <t>Bullet</t>
          </list>

          <list style="format %d" counter="a">
            <t>Number</t>
          </list>

        </t>

     </list>
     </t>

    </section>

  </middle>

  <back>
  </back>

</rfc>

Use different counters if you have multiple instances.
Regards,
Elwyn

Dearlove, Christopher (UK) wrote:
> I, and my co-authors, have a problem with one of our
> current Internet Drafts, as xml2rfc isn't doing the
> right thing with it. At the end is a close to minimal
> example of the problem, the point being that the final
> text includes
>
> 1.  Problem
>
>    1.  Number
>
>        *  Bullet
>
>        2.  Number
>
> rather than
>
> 1.  Problem
>
>    1.  Number
>
>        *  Bullet
>
>        1.  Number
>
> Does anyone have a workaround for this, and is this the
> right place for fault reporting that will feed into
> updating xml2rfc? Thanks in advance for any help.
>
>
> <?xml version="1.0" ?>
> <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
> <?rfc toc="yes"?>
>
> <rfc ipr="full3978" category="std" docName="test-00">
>
>   <front>
>     <title abbrev="Test">Test</title>
>     <author fullname="No One">
>       <organization>Nowhere</organization>
>     </author>
>     <date month='June' year='2007'/>
>     <area>SPQR</area>
>     <workgroup>XYZ WG</workgroup>
>     <keyword>I-D</keyword>
>     <keyword>Internet Draft</keyword>
>     <abstract>
>     </abstract>
>   </front>
>
>   <middle>
>
>     <section title="Problem">
>
>       <list style="numbers">
>
>         <t>
>           Number
>
>           <list style="symbols">
>             <t>Bullet</t>
>           </list>
>
>           <list style="numbers">
>             <t>Number</t>
>           </list>
>
>         </t>
>
>      </list>
>
>     </section>
>
>   </middle>
>
>   <back>
>   </back>
>
> </rfc>
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>   
>From Chris.Dearlove at baesystems.com  Wed Jun 27 12:17:14 2007
From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Jun 27 03:17:21 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Seems to be a bug in the formatter.

That's what I thought. Will this be seen by whoever maintains
it, or is there someone I should point this out to.

> Also the outside list needs to be embedded in a <t>.

That actually was there is the original, over-pruning to
produce the test version lost it. But thanks for the point.

> Here is a workaround using the format style.

<snip>

>          <list style="format %d" counter="a">

Just in case anyone else sees this and wants to use it,
to replace <list style="numbers"> you actually need

          <list style="format %d." counter="a">

(It took me some puzzling over the "a" significance,
even with son-of-RFC2629 to read, before working out
there wasn't one, anything will do.)

Thanks a lot for this.

Christopher Dearlove

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Jun 27 04:12:58 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

FYI..
I made a tutorial which gives a bit more info thn son-of-RFC2629.  You 
can find this on the RFC Editor web pages at
http://www.rfc-editor.org/formatting.html

As regards the bug:  It might be a 'feature':

    <t>

      <list style="numbers">

        <t>
          Number

          <list style="numbers">
            <t>Number</t>
          </list>

          <list style="symbols">
            <t>Bullet</t>
          </list>

          <list style="numbers">
            <t>Number</t>
          </list>

          <list style="format %d" counter="a">
            <t>Number</t>
          </list>

        </t>

     </list>
     </t>

produces

1.  Problem

   1.  Number

       1.  Number

       *  Bullet

       3.  Number

       1  Number

i.e. it appears that the internal counter per-level of lists is not reset if a 
new sub-list is started.  I seem to remember that the formatter keeps track of the number 
of sub-items at each level for use in an undocumented feature related to references.

I don't think we have actually thought too hard about what the exact behaviour
in the example should be.

/Elwyn

Dearlove, Christopher (UK) wrote:
>> Seems to be a bug in the formatter.
>>     
>
> That's what I thought. Will this be seen by whoever maintains
> it, or is there someone I should point this out to.
>
>   
>> Also the outside list needs to be embedded in a <t>.
>>     
>
> That actually was there is the original, over-pruning to
> produce the test version lost it. But thanks for the point.
>
>   
>> Here is a workaround using the format style.
>>     
>
> <snip>
>
>   
>>          <list style="format %d" counter="a">
>>     
>
> Just in case anyone else sees this and wants to use it,
> to replace <list style="numbers"> you actually need
>
>           <list style="format %d." counter="a">
>
> (It took me some puzzling over the "a" significance,
> even with son-of-RFC2629 to read, before working out
> there wasn't one, anything will do.)
>
> Thanks a lot for this.
>
> Christopher Dearlove
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>   
>From Chris.Dearlove at baesystems.com  Wed Jun 27 14:19:12 2007
From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Jun 27 05:19:24 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> I don't think we have actually thought too hard about what the exact
behaviour
> in the example should be.

Here's an extract from our ID (this is actually
from the next unpublished version) which shows
why we're using this sort of construct. The
numbering is pseudo-code steps, the bullets
make setting out the condition clearer (we think).

       1.  If there are no remaining Link Tuples for any MANET interface
           with:

           +  L_neighbor_iface_addr_list contained in
              N_neighbor_iface_addr_list; AND

           +  L_status == SYMMETRIC;

           then modify the Neighbor Tuple by:

           1.  N_symmetric = false.

           2.  ...

Without the workaround, the final 1 and 2 become 3 and 4, which is
not right for us.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Jun 27 05:23:30 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
>> Here is a workaround using the format style.
>>     
>
> <snip>
>
>   
>>          <list style="format %d" counter="a">
>>     
>
> Just in case anyone else sees this and wants to use it,
> to replace <list style="numbers"> you actually need
>
>           <list style="format %d." counter="a">
>
> (It took me some puzzling over the "a" significance,
> even with son-of-RFC2629 to read, before working out
> there wasn't one, anything will do.)
>   
The point about the counter variable is that the value is persistent.  
You can split a list using "format" style over several sections and 
continue the numbering sequence by using the same variable name in 
multiple <list> elements.  You can also have several numbered lists 
going in parallel by using different names for the counter variable.  
For example, if you are specifying requirements and want to provide a 
numbering scheme for them, they will usually appear spread through the 
document - the "format" style is ideal for that using something like 
<list style="format R(%d)" counter="reqnum">.

?ewlyn
> Thanks a lot for this.
>
> Christopher Dearlove
>
>
>   
>From elwynd at dial.pipex.com  Wed Jun 27 14:31:04 2007
From: elwynd at dial.pipex.com (Elwyn Davies)
Date: Wed Jun 27 05:29:28 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Dearlove, Christopher (UK) wrote:
>> I don't think we have actually thought too hard about what the exact
>>     
> behaviour
>   
>> in the example should be.
>>     
>
> Here's an extract from our ID (this is actually
> from the next unpublished version) which shows
> why we're using this sort of construct. The
> numbering is pseudo-code steps, the bullets
> make setting out the condition clearer (we think).
>
>
>        1.  If there are no remaining Link Tuples for any MANET interface
>            with:
>
>            +  L_neighbor_iface_addr_list contained in
>               N_neighbor_iface_addr_list; AND
>
>            +  L_status == SYMMETRIC;
>
>            then modify the Neighbor Tuple by:
>
>            1.  N_symmetric = false.
>
>            2.  ...
>
>
> Without the workaround, the final 1 and 2 become 3 and 4, which is
> not right for us.
>
>   
The behaviour you want is probably what xml2rfc should do by default - 
i.e., the numbering sequence should restart from 1 in a each 
"numbers"-style list, even if it isn't the first at that sub-level.  But 
there may be other opinions!

/Elwyn

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Jun 27 05:40:25 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The behaviour you want is probably what xml2rfc should do by default -

> i.e., the numbering sequence should restart from 1 in a each 
> "numbers"-style list, even if it isn't the first at that sub-level.
But 
> there may be other opinions!

I wouldn't object (I'm not sure whether I'm for or against) to

<list style="numbers">
<p></p>
<p></p>
</list>
<list style="symbols">
<p></p>
<p></p>
</list>
<list style="numbers">
<p></p>
<p></p>
</list>

going

1
2
*
*
3
4

but not to it going

1
2
*
*
5
6

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: Chris.Dearlove at baesystems.com (Dearlove, Christopher (UK))
Date: Wed Jun 27 05:43:29 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> The point about the counter variable is that the value is persistent.

I'd realised it was persistent,
 
> You can split a list using "format" style over several sections and 
> continue the numbering sequence by using the same variable name in 
> multiple <list> elements.

but not that persistent,

> You can also have several numbered lists 
> going in parallel by using different names for the counter variable.

or that flexible.

When I said that the "a" wasn't significant, I meant that it
could have been any name. (Actually using this as a workaround
means it has to be unique, so if you have many instances of this
- but we only have one - you have to take care.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Jun 27 05:45:29 2007
Subject: [xml2rfc] xml2rfc problem
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Elwyn Davies wrote:

> The behaviour you want is probably what xml2rfc should do by default - 
> i.e., the numbering sequence should restart from 1 in a each 
> "numbers"-style list, even if it isn't the first at that sub-level.  But 
> there may be other opinions!

Seems to be a bug (rfc2629.xslt behaves differently, and the spec 
doesn't mention the behavior). It may even be a regression; I remember 
that a similar problem was fixed some time ago.

Best regards, Julian

From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon Jul  2 13:02:18 2007
Subject: [xml2rfc] Text RFC parser?
Message-ID: <[email-masked]>

I know, it is offtopic but I'm not sure there are many other lists to
ask this question.

I would like to have the RFC in a SQL RDBMS, not just the text, but
the metadata: authors, date, references, etc.

Unless someone already did it, it means translating a structured
format like RFC 2629 to SQL.

My problem is that only a part of the RFCs are published in RFC 2629
(http://xml.resource.org/public/rfc/). For these RFC, the task is
straightforward. But for the others?

I wonder if there are available "RFC parsers" who can parse 90 or 95 %
of a text RFC and produce RFC 2629 or another structured format?

Otherwise, I'll have to write one, probably using metadata from
http://xml.resource.org/public/rfc/bibxml/ first.
>From mrose at dbc.mtview.ca.us  Mon Jul  2 16:10:35 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Mon Jul  2 13:10:42 2007
Subject: [xml2rfc] Text RFC parser?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I wonder if there are available "RFC parsers" who can parse 90 or 95 %
> of a text RFC and produce RFC 2629 or another structured format?
>
> Otherwise, I'll have to write one, probably using metadata from
> http://xml.resource.org/public/rfc/bibxml/ first.

hi. carl spent a fair amount of time writing and tweaking scripts to  
go from the txt format to 2629. his experience was that there was  
enough variability with the final output that a programmatic attempt  
became near-problematic.

however, if you're able to write a tool that does a good job, we'd  
love to try it out.

thanks,

/mtr

From: lars.eggert at nokia.com (Lars Eggert)
Date: Mon Jul  9 05:50:14 2007
Subject: [xml2rfc] bibxml issues?
Message-ID: <[email-masked]>

Hi,

is there a problem with the XML reference files on xml.resource.org/ 
public/rfc/bibxml3/?

For example, the ones for I-D.shore-afwc and I-D.shore-nls-fw seem to  
be missing currently. (They went missing again a few weeks ago but  
then reappeared.)

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070709/805ffcfe/smime.bin
>From fenner at gmail.com  Mon Jul  9 11:16:02 2007
From: fenner at gmail.com (Bill Fenner)
Date: Mon Jul  9 07:16:07 2007
Subject: [xml2rfc] bibxml issues?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

My bibxml3 directory got corrupted.  I've restored from one of the
other mirrors.

  Bill
>From slawrence at pingtel.com  Tue Jul 10 10:53:55 2007
From: slawrence at pingtel.com (Scott Lawrence)
Date: Tue Jul 10 06:54:01 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On Mon, 2007-04-09 at 22:14 +0200, Julian Reschke wrote:

> 1) No new PIs. Deprecate the existing include PI. Let people *include* 
> the reference.

Wait - there are lots of cases when the include PI is very useful that
have nothing to do with references.  I've used it extensively to
assemble a document from components.  For example, if I have an xml
schema that I want to include in a draft, it's much more useful to have
that schema as a standalone document and preprocess that to include it
into the draft.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jul 10 07:02:29 2007
Subject: [xml2rfc] Change default to use symbolic references?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Scott Lawrence wrote:
> On Mon, 2007-04-09 at 22:14 +0200, Julian Reschke wrote:
> 
>> 1) No new PIs. Deprecate the existing include PI. Let people *include* 
>> the reference.
> 
> Wait - there are lots of cases when the include PI is very useful that
> have nothing to do with references.  I've used it extensively to
> assemble a document from components.  For example, if I have an xml
> schema that I want to include in a draft, it's much more useful to have
> that schema as a standalone document and preprocess that to include it
> into the draft.

Understood, but that doesn't need to be a feature of the xml2rfc grammar 
itself. Just use tools that are available for that purpose, such as XML 
external entities, or XML Include (supported in xsltproc for instance).

Best regards, Julian
>From dmm at 1-4-5.net  Tue Jul 17 11:29:20 2007
From: dmm at 1-4-5.net (David Meyer)
Date: Tue Jul 17 10:29:28 2007
Subject: [xml2rfc] 
	problems with xml.resource.org (in particular, 192.20.225.40) today?
Message-ID: <[email-masked]>

	Looks like xml.resource.org returns 3 A records:

xml.resource.org.       60      IN      A       194.146.105.14
xml.resource.org.       60      IN      A       168.143.123.173
xml.resource.org.       60      IN      A       192.20.225.40

	Seems that 192.20.225.40 is having its problems...

[dmm@m106:~]861% wget -v http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml
--10:27:13--  http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml
           => `reference.RFC.2119.xml.2'
Resolving xml.resource.org... 192.20.225.40, 194.146.105.14, 168.143.123.173, ...
Connecting to xml.resource.org|192.20.225.40|:80... 

	[hangs]

	Anyone else observing this?

	Thnx,

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070717/645bc74b/attachment.bin
>From fenner at research.att.com  Tue Jul 17 17:36:47 2007
From: fenner at research.att.com (Bill Fenner)
Date: Tue Jul 17 13:36:59 2007
Subject: [xml2rfc]  problems with xml.resource.org (in particular,
	192.20.225.40) today?
Message-ID: <[email-masked]>

192.20.225.40 has been having hardware trouble; it went down
hard yesterday and the measures I put in place to recover
from the impending doom failed.  I am recovering from a backup
now and it should be back up tomorrow.

  Bill
>From dmm at 1-4-5.net  Tue Jul 17 14:52:34 2007
From: dmm at 1-4-5.net (David Meyer)
Date: Tue Jul 17 13:52:41 2007
Subject: [xml2rfc]  problems with xml.resource.org (in particular,
	192.20.225.40) today?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Jul 17, 2007 at 04:36:47PM -0400, Bill Fenner wrote:
> 
> 192.20.225.40 has been having hardware trouble; it went down
> hard yesterday and the measures I put in place to recover
> from the impending doom failed.  I am recovering from a backup
> now and it should be back up tomorrow.

	Thanks Bill.

	Dave

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070717/43c557c6/attachment.bin
>From schishol at nortel.com  Tue Jul 31 11:25:54 2007
From: schishol at nortel.com (Sharon Chisholm)
Date: Tue Jul 31 07:26:02 2007
Subject: [xml2rfc] Figure Numbering
Message-ID: <[email-masked]>

Hi

I have an issue with figure numbering in my draft. The draft contains a
lot of XML in the form of XSDs and XML examples. To get them to show up
properly, I have included them in figures and escaped them using CDATA.
The problem is that although I only have 3 or 4 real figures in the
document, every "figure" gets a number. So far I have only figured out
two options:

1. Have the numbering of what I consider to be figures to jump from 1 to
5 to 9, etc.
2. Number everything (which looks daft)

Is there a way I can fix this?

The draft in question is the following:
 
http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-08.t
xt

Thanks,

Sharon Chisholm
Nortel
Ottawa, Ontario
Canada

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jul 31 07:43:29 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Sharon Chisholm wrote:
> Hi
> 
> I have an issue with figure numbering in my draft. The draft contains a
> lot of XML in the form of XSDs and XML examples. To get them to show up
> properly, I have included them in figures and escaped them using CDATA.
> The problem is that although I only have 3 or 4 real figures in the
> document, every "figure" gets a number. So far I have only figured out
> two options:
> 
> 1. Have the numbering of what I consider to be figures to jump from 1 to
> 5 to 9, etc.
> 2. Number everything (which looks daft)
> 
> Is there a way I can fix this?
> 
> The draft in question is the following:
>  
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-08.t
> xt

I think numbers are assigned when you have an anchor attribute on the 
figure. Did you try to remove those?

Best regards, Julian
>From schishol at nortel.com  Tue Jul 31 11:57:23 2007
From: schishol at nortel.com (Sharon Chisholm)
Date: Tue Jul 31 07:57:48 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi

When you don't have anchors, the figures seem to still be assigned
numbers, but they don't get displayed. This is what gives me option 1
below.

Sharon 

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 10:43 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [xml2rfc] Figure Numbering

Sharon Chisholm wrote:
> Hi
> 
> I have an issue with figure numbering in my draft. The draft contains 
> a lot of XML in the form of XSDs and XML examples. To get them to show

> up properly, I have included them in figures and escaped them using
CDATA.
> The problem is that although I only have 3 or 4 real figures in the 
> document, every "figure" gets a number. So far I have only figured out

> two options:
> 
> 1. Have the numbering of what I consider to be figures to jump from 1 
> to
> 5 to 9, etc.
> 2. Number everything (which looks daft)
> 
> Is there a way I can fix this?
> 
> The draft in question is the following:
>  
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-08
> .t
> xt

I think numbers are assigned when you have an anchor attribute on the
figure. Did you try to remove those?

Best regards, Julian

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jul 31 10:21:35 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I have an issue with figure numbering in my draft. The draft  
> contains a
> lot of XML in the form of XSDs and XML examples. To get them to  
> show up
> properly, I have included them in figures and escaped them using  
> CDATA.
> The problem is that although I only have 3 or 4 real figures in the
> document, every "figure" gets a number.

so basically, what you're doing is using the <artwork/> element to  
turn off formatting. is that the gist of it?

we really don't have a usage model for that. i suppose we could do  
something in terms of numbering (e.g., make this an un-numbered figure).

/mtr

From: schishol at nortel.com (Sharon Chisholm)
Date: Tue Jul 31 10:24:17 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

Yes. If there is another way to embed XML Schema and XML nicely, I'm
game to try that.

Sharon 

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 1:21 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [xml2rfc] Figure Numbering

> I have an issue with figure numbering in my draft. The draft contains 
> a lot of XML in the form of XSDs and XML examples. To get them to show

> up properly, I have included them in figures and escaped them using 
> CDATA.
> The problem is that although I only have 3 or 4 real figures in the 
> document, every "figure" gets a number.

so basically, what you're doing is using the <artwork/> element to turn
off formatting. is that the gist of it?

we really don't have a usage model for that. i suppose we could do
something in terms of numbering (e.g., make this an un-numbered figure).

/mtr

From: carl at media.org (Carl Malamud)
Date: Tue Jul 31 10:31:09 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> When you don't have anchors, the figures seem to still be assigned
> numbers, but they don't get displayed. This is what gives me option 1
> below.

How about leaving anchors off and doing your numbering on "real" figures
manually using the <postamble>Figure X</postamble> element?

Carl
>From cpignata at cisco.com  Tue Jul 31 15:02:53 2007
From: cpignata at cisco.com (Carlos Pignataro)
Date: Tue Jul 31 11:03:01 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 7/31/2007 1:31 PM, Carl Malamud said the following:
>> When you don't have anchors, the figures seem to still be assigned
>> numbers, but they don't get displayed. This is what gives me option 1
>> below.
> 
> How about leaving anchors off and doing your numbering on "real" figures
> manually using the <postamble>Figure X</postamble> element?

One problem with this is that you cannot xref the "real" figure; another
is the manual renumbering needed if inserting a new figure in before an
existing one.

I faced this same issue recently, and the *workaround* I used (not
saying that this is the desired or possible solution, but what I used to
get the I-D out) was to modify xml2rfc.tcl to only increment the figure
counter when there is an anchor, and otherwise emit a warning/debug to
remember the hack (off 1.33pre4):

@@ -4384,11 +4384,18 @@
             }

             figure {
+# cpignata: Added this condition to only
+# increment the figure counter if there is an anchor
+             if {[info exists attrs(anchor)]} {
                 if {[catch { incr counter(figure) }]} {
                     set counter(figure) 1
                 }
                 set attrs(.COUNTER) [set value $counter(figure)]
                 set elem($elemN) [array get attrs]
+             } else {
+               unexpected warning \
+               "figure: Not incrementing counter for figure without anchor"
+             }
             }

             preamble - postamble {

Thanks,

--Carlos.

> 
> Carl
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
>From julian.reschke at gmx.de  Tue Jul 31 21:32:33 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jul 31 11:32:47 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> I have an issue with figure numbering in my draft. The draft contains a
>> lot of XML in the form of XSDs and XML examples. To get them to show up
>> properly, I have included them in figures and escaped them using CDATA.
>> The problem is that although I only have 3 or 4 real figures in the
>> document, every "figure" gets a number.
> 
> so basically, what you're doing is using the <artwork/> element to turn 
> off formatting. is that the gist of it?
 >
> we really don't have a usage model for that. i suppose we could do 
> something in terms of numbering (e.g., make this an un-numbered figure).

Decoupling figures from pre-formatted text would make sense in many 
cases, for instance in lists (where figures currently are "deprecated", 
but no replacement mechanism is available).

Best regards, Julian
>From julian.reschke at gmx.de  Tue Jul 31 21:35:41 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jul 31 11:35:55 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Carlos Pignataro wrote:
> 
> On 7/31/2007 1:31 PM, Carl Malamud said the following:
>>> When you don't have anchors, the figures seem to still be assigned
>>> numbers, but they don't get displayed. This is what gives me option 1
>>> below.
>> How about leaving anchors off and doing your numbering on "real" figures
>> manually using the <postamble>Figure X</postamble> element?
> 
> One problem with this is that you cannot xref the "real" figure; another
> is the manual renumbering needed if inserting a new figure in before an
> existing one.
> 
> I faced this same issue recently, and the *workaround* I used (not
> saying that this is the desired or possible solution, but what I used to
> get the I-D out) was to modify xml2rfc.tcl to only increment the figure
> counter when there is an anchor, and otherwise emit a warning/debug to
> remember the hack (off 1.33pre4):
> ...

Essentially, this is what rfc2629.xslt is doing, and I thought xml2rfc 
was doing as well (maybe it did in the past?).

Best regards, Julian
>From mrose at dbc.mtview.ca.us  Tue Jul 31 14:37:39 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jul 31 11:37:44 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> Decoupling figures from pre-formatted text would make sense in many  
> cases, for instance in lists (where figures currently are  
> "deprecated", but no replacement mechanism is available).

yes, but that sounds like an awfully large work item in comparison to  
a six line diff...

am i missing something?

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jul 31 11:44:03 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I faced this same issue recently, and the *workaround* I used (not
> saying that this is the desired or possible solution, but what I  
> used to
> get the I-D out) was to modify xml2rfc.tcl to only increment the  
> figure
> counter when there is an anchor, and otherwise emit a warning/debug to
> remember the hack (off 1.33pre4):

hi. i think your patch is fine (we'll put something similar in  
1.33pre5), but with two notes:

1. since anchor is #IMPLIED, i don't think a warning is warranted.

2. the same test should be made for texttable elements.

thanks!

/mtr

From: julian.reschke at gmx.de (Julian Reschke)
Date: Tue Jul 31 11:52:25 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> Decoupling figures from pre-formatted text would make sense in many 
>> cases, for instance in lists (where figures currently are 
>> "deprecated", but no replacement mechanism is available).
> 
> yes, but that sounds like an awfully large work item in comparison to a 
> six line diff...
> 
> am i missing something?

No.

To get the figure numbering issue fixed, it's sufficient to number just 
the figures with anchors.

Best regards, Julian
>From cpignata at cisco.com  Tue Jul 31 15:53:39 2007
From: cpignata at cisco.com (Carlos Pignataro)
Date: Tue Jul 31 11:53:51 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall,

On 7/31/2007 2:43 PM, Marshall Rose said the following:
>> I faced this same issue recently, and the *workaround* I used (not
>> saying that this is the desired or possible solution, but what I  
>> used to
>> get the I-D out) was to modify xml2rfc.tcl to only increment the  
>> figure
>> counter when there is an anchor, and otherwise emit a warning/debug to
>> remember the hack (off 1.33pre4):
> 
> hi. i think your patch is fine (we'll put something similar in  
> 1.33pre5), but with two notes:
> 
> 1. since anchor is #IMPLIED, i don't think a warning is warranted.

Agreed, the warning was just for me to remember about the patch.

> 
> 2. the same test should be made for texttable elements.

Agree as well, the code is the same there (for the "table" counter).

Thanks !

--Carlos.

> 
> thanks!
> 
> /mtr
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
>From mrose at dbc.mtview.ca.us  Tue Jul 31 14:55:10 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jul 31 11:55:15 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

> To get the figure numbering issue fixed, it's sufficient to number  
> just the figures with anchors.

julian - agreed, thanks!

sharon - to solve your immediate problem, use the patch that carlos  
posted.

if you are using the web-based service, that should be updated within  
a day or so.

/mtr

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Tue Jul 31 12:00:10 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Agree as well, the code is the same there (for the "table" counter).

we're on the same page, thanks!

/mtr

From: schishol at nortel.com (Sharon Chisholm)
Date: Tue Jul 31 12:35:08 2007
Subject: [xml2rfc] Figure Numbering
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

That seems to have done the trick.

Thanks!

Sharon 

-----Original Message-----
From: Marshall Rose [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2007 2:55 PM
To: Julian Reschke
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [xml2rfc] Figure Numbering

> To get the figure numbering issue fixed, it's sufficient to number 
> just the figures with anchors.

julian - agreed, thanks!

sharon - to solve your immediate problem, use the patch that carlos
posted.

if you are using the web-based service, that should be updated within a
day or so.

/mtr

From: stpeter at jabber.org (Peter Saint-Andre)
Date: Wed Aug  8 09:29:36 2007
Subject: [xml2rfc] copyright boilerplate
Message-ID: <[email-masked]>

My latest I-D submissions have been rejected with the following message:

******

The Secretariat CANNOT process your Internet-Draft submission due to
following reason(s):  * All Internet-Drafts must include the following
statement:

This document is subject to the rights, licenses
and restrictions contained in BCP 78, and except as set forth
therein, the authors retain all their rights.

******

The offending text seems to be:

"and at http://www.rfc-editor.org/copyright.html"

The problem seems to be caused by flagging the I-D as an independent
submission (see copylong4 vs. copylong5 in xml2rfc.tcl).

I assume that for now I should simply remove the
submissionType='independent' flag from the XML source?

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070808/f9979013/smime.bin
>From mrose at dbc.mtview.ca.us  Wed Aug  8 11:12:52 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Aug  8 10:12:58 2007
Subject: [xml2rfc] copyright boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> The problem seems to be caused by flagging the I-D as an independent
> submission (see copylong4 vs. copylong5 in xml2rfc.tcl).
>
> I assume that for now I should simply remove the
> submissionType='independent' flag from the XML source?\

i think i've seen this before.

what version are you using?

also, for now remove the submissionType just to get it through.

/mtr

From: stpeter at jabber.org (Peter Saint-Andre)
Date: Wed Aug  8 10:20:27 2007
Subject: [xml2rfc] copyright boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>> The problem seems to be caused by flagging the I-D as an independent
>> submission (see copylong4 vs. copylong5 in xml2rfc.tcl).
>>
>> I assume that for now I should simply remove the
>> submissionType='independent' flag from the XML source?\
> 
> i think i've seen this before.
> 
> what version are you using?

It happens with both 1.32 and 1.33pre4.

> also, for now remove the submissionType just to get it through.

Yep. That kind of defeats the purpose though. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070808/900cfee1/smime.bin
>From fenner at gmail.com  Wed Aug  8 15:05:56 2007
From: fenner at gmail.com (Bill Fenner)
Date: Wed Aug  8 11:06:04 2007
Subject: [xml2rfc] copyright boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 8/8/07, Peter Saint-Andre <[email-masked]> wrote:
> Marshall Rose wrote:
> > also, for now remove the submissionType just to get it through.
>
> Yep. That kind of defeats the purpose though. :)

The IETF accidentally outlawed this construct by publishing RFC 3978.
Its publication got held up for months trying to resolve the issue,
the wg appeared to have consensus on a fix, and then the RFC got
published without any fix.

So, unfortunately, the Secretariat is only enforcing the rules that
the IETF created; it would presumably be a work item of the IPR
working group to fix this.

  Bill
>From stpeter at jabber.org  Wed Aug  8 16:16:20 2007
From: stpeter at jabber.org (Peter Saint-Andre)
Date: Wed Aug  8 14:14:14 2007
Subject: [xml2rfc] copyright boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> On 8/8/07, Peter Saint-Andre <[email-masked]> wrote:
>> Marshall Rose wrote:
>>> also, for now remove the submissionType just to get it through.
>> Yep. That kind of defeats the purpose though. :)
> 
> The IETF accidentally outlawed this construct by publishing RFC 3978.
> Its publication got held up for months trying to resolve the issue,
> the wg appeared to have consensus on a fix, and then the RFC got
> published without any fix.
> 
> So, unfortunately, the Secretariat is only enforcing the rules that
> the IETF created; it would presumably be a work item of the IPR
> working group to fix this.

Thanks for the clarification. I'll pursue the matter there.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070808/aef4b71a/smime.bin
>From presnick at qualcomm.com  Sat Aug 18 01:28:01 2007
From: presnick at qualcomm.com (Pete Resnick)
Date: Fri Aug 17 22:28:03 2007
Subject: [xml2rfc] Delimiters for artwork in text?
Message-ID: <p0625010fc2ec33df0fe0@[74.134.5.163]>

This is probably just a feature request:

In HTML, artwork is contained in a grey background box. That's 
lovely. However, in the text version, there is nothing delimiting the 
artwork from the rest of the text. That's not so lovely, and in my 
case rather confusing to try and read the thing. Is there any way, 
with either a processing instruction or a parameter, to do this? If 
we're talking about a new feature, either of these would be OK with 
me:

<?rfc textartdelim="-----"?>

or

<artwork textdelim="-----">

And what you'd end up with is:

    -----
    This is my lovely artwork
    -----

Any possibility such a thing, even in the "living on the edge" version?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
>From jonghyouk at gmail.com  Thu Aug 30 00:13:09 2007
From: jonghyouk at gmail.com (Jong-Hyouk Lee)
Date: Wed Aug 29 07:13:32 2007
Subject: [xml2rfc] XML2RFC newbie question on "initials".
Message-ID: <[email-masked]>

Dear colleagues.

I'm writing a document. In the authors field, I cannot insert the exact
initials. For instance, My initials is "J.-H." and fullname is "Jong-Hyouk
Lee".

<!-- AUTHORS -->
<author initials="J.-H." surname="Lee" fullname="Jong-Hyouk Lee">
...
...
...

If I write like above. I cannot get the exact initials. The problem is here,

<author initials="J.-H."
Anyone knows the solution?

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://www.hurryon.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070829/88728306/attachment.htm

From: lars.eggert at nokia.com (Lars Eggert)
Date: Tue Sep 18 23:05:50 2007
Subject: [xml2rfc] formatting inside texttable cells?
Message-ID: <[email-masked]>

Hi,

I'm trying to use vspace to structure the contents of a texttable  
call, but apparently that isn't possible? Is there another way to do  
what I want?

Thanks,
Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070919/cb12714d/smime.bin
>From swb at employees.org  Thu Sep 20 11:36:31 2007
From: swb at employees.org (Scott Brim)
Date: Thu Sep 20 07:37:01 2007
Subject: [xml2rfc] bus error on Mac OS X
Message-ID: <[email-masked]>

I just tried installing and running xml2rfc locally for the first time
in many months.  Unfortunately I get:

  [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/
  [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl 
  Bus error
  [10:30:34 ~/working/xml2rfc-1.32 (138)]$ 

On Mac OS X.
tcl_platform says "unix".
I get the same error when I fire up tclsh and source xml2rfc.tcl.
I get the same error with 1.33pre4.

I suspect this is a well-known newbie install problem.  Help?

Thanks ... Scott
>From swb at employees.org  Thu Sep 20 12:03:03 2007
From: swb at employees.org (Scott Brim)
Date: Thu Sep 20 08:03:34 2007
Subject: [xml2rfc] bus error on Mac OS X
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I was asked which tcl.  tclsh -> "info patchlevel" says 8.4.7.

On 20 Sep 2007 at 10:36 -0400, Scott Brim allegedly wrote:
> I just tried installing and running xml2rfc locally for the first time
> in many months.  Unfortunately I get:
> 
>   [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/
>   [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl 
>   Bus error
>   [10:30:34 ~/working/xml2rfc-1.32 (138)]$ 
> 
> On Mac OS X.
> tcl_platform says "unix".
> I get the same error when I fire up tclsh and source xml2rfc.tcl.
> I get the same error with 1.33pre4.
> 
> I suspect this is a well-known newbie install problem.  Help?
> 
> Thanks ... Scott
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From lars.eggert at nokia.com  Thu Sep 20 19:02:01 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Sep 20 08:04:57 2007
Subject: [xml2rfc] bus error on Mac OS X
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Did you install it manually? If so, you may want to try the fink  
port, which should work.

On 2007-9-20, at 17:36, ext Scott Brim wrote:
> I just tried installing and running xml2rfc locally for the first time
> in many months.  Unfortunately I get:
>
>   [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/
>   [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl
>   Bus error
>   [10:30:34 ~/working/xml2rfc-1.32 (138)]$
>
> On Mac OS X.
> tcl_platform says "unix".
> I get the same error when I fire up tclsh and source xml2rfc.tcl.
> I get the same error with 1.33pre4.
>
> I suspect this is a well-known newbie install problem.  Help?
>
> Thanks ... Scott
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20070920/8654371a/smime.bin
>From mrose at dbc.mtview.ca.us  Thu Sep 20 11:37:49 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Sep 20 08:37:54 2007
Subject: [xml2rfc] bus error on Mac OS X
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> On Mac OS X.
> tcl_platform says "unix".
> I get the same error when I fire up tclsh and source xml2rfc.tcl.
> I get the same error with 1.33pre4.
>
> I suspect this is a well-known newbie install problem.  Help?

Mac OS X comes with tclsh pre-installed. i haven't had to install tcl/ 
tk for a few years.

what does "which" say?

	which tclsh

/mtr

From: sbrim at cisco.com (Scott Brim)
Date: Thu Sep 20 08:38:39 2007
Subject: [xml2rfc] bus error on Mac OS X
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 20 Sep 2007 at 18:02 +0300, Lars Eggert allegedly wrote:
> Did you install it manually? If so, you may want to try the fink  
> port, which should work.

This got me looking.  I have tclsh 8.4, 8.4.7 and 8.5, probably from
MacPorts.  I'll explore.  Thanks.
>From mrose at dbc.mtview.ca.us  Thu Sep 20 11:38:58 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Sep 20 08:39:04 2007
Subject: [xml2rfc] formatting inside texttable cells?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm trying to use vspace to structure the contents of a texttable  
> call, but apparently that isn't possible? Is there another way to  
> do what I want?

my guess: probably not. that kind of functionality is outside the  
design goals for texttable.

/mtr

From: fenner at gmail.com (Bill Fenner)
Date: Thu Sep 20 10:20:43 2007
Subject: [xml2rfc] bus error on Mac OS X
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 9/20/07, Scott Brim <[email-masked]> wrote:
> I just tried installing and running xml2rfc locally for the first time
> in many months.  Unfortunately I get:
>
>   [10:30:25 ~ (0)]$ cd working/xml2rfc-1.32/
>   [10:30:29 ~/working/xml2rfc-1.32 (0)]$ ./xml2rfc.tcl
>   Bus error
>   [10:30:34 ~/working/xml2rfc-1.32 (138)]$

I get the same thing on my main development machine.  I tracked it
down to dynamically loading Tk, so I commented out the parts of
xml2rfc.tcl that tries to load Tk.  Lame, but gets the command-line
part working.

  Bill
>From Nicolas.Williams at sun.com  Tue Sep 25 13:32:00 2007
From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Tue Sep 25 10:32:08 2007
Subject: [xml2rfc] Entities broken lately
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Sat, Mar 31, 2007 at 09:55:53PM -0700, Bill Fenner wrote:
> Initial analysis shows that this isn't entity handling per se: it's a
> combination of
> a) <artwork> elements don't render properly when there's a PI inside
> b) entity expansion now gets <?rfc linefile="..."?> PIs inserted.
> 
> I'm trying to investigate the root cause of (a).  It's frustratingly
> subtle, since in the earlier passes the PCDATA is seen properly; it's
> just lost in the processing pass.  It knows how many lines of artwork
> to expect, but it just fails to render them.

BTW, 1.33pre4 still has this bug.

From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon Oct  1 12:11:44 2007
Subject: [xml2rfc] more than one <uri/> element?
Message-ID: <[email-masked]>

I'm wondering why the DTD limits the author description to one URI:

<!ELEMENT address     (postal?,phone?,facsimile?,email?,uri?)>

What if you want to include, say, a SIP address and an XMPP address, or
a website URL and a presence URI?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071001/6c72b00d/smime.bin
>From rajeev.koodli at nokia.com  Tue Oct  9 15:48:49 2007
From: rajeev.koodli at nokia.com (Rajeev Koodli)
Date: Tue Oct  9 14:49:15 2007
Subject: [xml2rfc] "not expecting pcdata.."
Message-ID: <[email-masked]>

Hi,

I have used xml2rfc on xml.resource.org twice before. This time around, I
get the following error:

not expecting pcdata in <middle> element around input line 65 in
"internally-preprocessed XML"

Syntax:
    65:<middle>
    8:<rfc category="std" ipr="full3978"
docName="draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt">

Any pointers?

Many thanks,

-Rajeev
-- 
http://people.nokia.net/~rajeev

From: dwing at cisco.com (Dan Wing)
Date: Tue Oct  9 16:16:09 2007
Subject: [xml2rfc] "not expecting pcdata.."
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Try running your XML through 

  http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/

which uncovers all sorts of syntax errors.

-d

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rajeev Koodli
> Sent: Tuesday, October 09, 2007 2:49 PM
> To: [email-masked]
> Subject: [xml2rfc] "not expecting pcdata.."
> 
> 
> Hi,
> 
> I have used xml2rfc on xml.resource.org twice before. This 
> time around, I
> get the following error:
> 
> 
> not expecting pcdata in <middle> element around input line 65 in
> "internally-preprocessed XML"
> 
> Syntax:
>     65:<middle>
>     8:<rfc category="std" ipr="full3978"
> docName="draft-ietf-mipshop-fmipv6-rfc4068bis-03.txt">
> 
> 
> 
> Any pointers?
> 
> Many thanks,
> 
> -Rajeev
> -- 
> http://people.nokia.net/~rajeev
> 
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 
>From fenner at research.att.com  Tue Oct  9 20:36:07 2007
From: fenner at research.att.com (Bill Fenner)
Date: Tue Oct  9 16:37:29 2007
Subject: [xml2rfc] "not expecting pcdata.."
Message-ID: <[email-masked]>

I'd bet you have non-whitespace outside a <section> element.

  Bill
>From fenner at gmail.com  Tue Oct  9 17:43:16 2007
From: fenner at gmail.com (Bill Fenner)
Date: Tue Oct  9 16:43:24 2007
Subject: [xml2rfc] Entities broken lately
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 9/25/07, Nicolas Williams <[email-masked]> wrote:
> BTW, 1.33pre4 still has this bug.

Yup, the bug is due to the architecture of a major feature introduced
in 1.31 (typed-artwork validation) and I am not yet familiar enough
with the internals to be able to do more than diagnose the cause - I
have some theories about the fix but nothing concrete yet.

  Bill
>From rajeev.koodli at nokia.com  Wed Oct 10 14:34:10 2007
From: rajeev.koodli at nokia.com (Rajeev Koodli)
Date: Wed Oct 10 13:34:19 2007
Subject: [xml2rfc] "not expecting pcdata.."
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 10/9/07 4:36 PM, "ext Bill Fenner" <[email-masked]> wrote:

> 
> I'd bet you have non-whitespace outside a <section> element.
> 
>   Bill

Right on. (leftovers from mistyped ESC-gg)

Thanks,

-Rajeev
-- 
http://people.nokia.net/~rajeev

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Wed Oct 10 13:42:51 2007
Subject: [xml2rfc] Entities broken lately
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Tue, Oct 09, 2007 at 04:43:16PM -0700, Bill Fenner wrote:
> On 9/25/07, Nicolas Williams <[email-masked]> wrote:
> > BTW, 1.33pre4 still has this bug.
> 
> Yup, the bug is due to the architecture of a major feature introduced
> in 1.31 (typed-artwork validation) and I am not yet familiar enough
> with the internals to be able to do more than diagnose the cause - I
> have some theories about the fix but nothing concrete yet.

Thanks for looking into this.  This is fairly important feature for
complex documents, methinks, but my immediate need for it is no longer
urgent (the I-D in question has been or soon will be sent to the IESG).
>From lars.eggert at nokia.com  Wed Oct 24 12:46:14 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Wed Oct 24 01:47:00 2007
Subject: [xml2rfc] more than five authors?
Message-ID: <[email-masked]>

Hi,

I'm using xml2rfc for a non-RFC document that needs to have more than  
five authors on the front page.

How do I stop xml2rfc from complaining about the number of authors?

Thanks,
Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071024/8ebde666/smime.bin
>From mrose at dbc.mtview.ca.us  Wed Oct 24 11:08:47 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Wed Oct 24 08:08:49 2007
Subject: [xml2rfc] more than five authors?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I'm using xml2rfc for a non-RFC document that needs to have more  
> than five authors on the front page.
>
> How do I stop xml2rfc from complaining about the number of authors?

turn strict off.

or

decide who is the primary editor, and do

	<author role='editor' ...>

and get rid of the other <author/> elements.

/mtr

From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed Oct 24 08:31:27 2007
Subject: [xml2rfc] more than five authors?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:

> decide who is the primary editor, and do
> 
>     <author role='editor' ...>
> 
> and get rid of the other <author/> elements.

That always simplifies AUTH48 review and approval, too. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071024/5fe54864/smime.bin

From: pbaker at verisign.com (Hallam-Baker, Phillip)
Date: Thu Nov  1 13:07:45 2007
Subject: [xml2rfc] RE: HTML2xml?
References: <[email-masked]>
Message-ID: <[email-masked]>

On passing out copies of an ID for review I have discovered that most people seem to prefer commenting on the HTML version as opposed to the XML. So I have been reverse engineering changes.
 
It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML.
 
Building a tool would allow checks to ensure that round tripping was in fact possible.
 
<mailto:[email-masked]>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071101/c6c4ce16/attachment.htm
>From carl at media.org  Thu Nov  1 13:31:04 2007
From: carl at media.org (Carl Malamud)
Date: Thu Nov  1 13:31:11 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi -

I'm afraid we originally conceived of this as a one-way
transformation.  Although somebody at one of the better
schools wrote a doctoral dissertation saying that in
theory the transformation is reversable, no programs
have been found "in the wild" to do this.

If you're up for that level of coding, maybe you could 
do a program to transform the text RFCs into XML?  It
would be wonderful to have the whole series available
in that format.

Carl

> On passing out copies of an ID for review I have discovered that most people seem to prefer commenting on the HTML version as opposed to the XML. So I have been reverse engineering changes.
>  
> It then occurred to me that ideally this process would be performed automatically and that if this was supported it would then be possible to take an RFC in HTML form and recover the original XML for editing. I would much rather do this if I was going to produce a new version of a published RFC rather than rely on someone having kept the correct version of the XML.
>  
> Building a tool would allow checks to ensure that round tripping was in fact possible.
>  
> <mailto:[email-masked]>  

> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From Dale.Worley at comcast.net  Thu Nov  1 16:34:15 2007
From: Dale.Worley at comcast.net ([email-masked])
Date: Thu Nov  1 13:34:23 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: 
	<[email-masked]>
	([email-masked])
References: 
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

   From: "Hallam-Baker, Phillip" <[email-masked]>

   It then occurred to me that ideally this process would be performed
   automatically and that if this was supported it would then be possible
   to take an RFC in HTML form and recover the original XML for editing. I
   would much rather do this if I was going to produce a new version of a
   published RFC rather than rely on someone having kept the correct
   version of the XML.

The XML to HTML transformation is information-losing, so I wouldn't
expect reversing it to be easy.  But it might be feasible to create a
tool that takes the XML, the original HTML, and edited HTML and
back-ports the changes into the XML.

Dale
>From tony at att.com  Thu Nov  1 18:25:14 2007
From: tony at att.com (Tony Hansen)
Date: Thu Nov  1 14:26:32 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Alternatively, judicious use of XML comments or <somenamespace:tags>
could be placed in the HTML output that allowed the XML to be recreated.

	Tony Hansen
	[email-masked]

[email-masked] wrote:
>    From: "Hallam-Baker, Phillip" <[email-masked]>
> 
>    It then occurred to me that ideally this process would be performed
>    automatically and that if this was supported it would then be possible
>    to take an RFC in HTML form and recover the original XML for editing. I
>    would much rather do this if I was going to produce a new version of a
>    published RFC rather than rely on someone having kept the correct
>    version of the XML.
> 
> The XML to HTML transformation is information-losing, so I wouldn't
> expect reversing it to be easy.  But it might be feasible to create a
> tool that takes the XML, the original HTML, and edited HTML and
> back-ports the changes into the XML.
> 
> Dale

From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu Nov  1 14:34:45 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References:  <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>>    From: "Hallam-Baker, Phillip" <[email-masked]>
>>
>>    I would much rather do this if I was going to produce a new version of
>>    a published RFC rather than rely on someone having kept the correct
>>    version of the XML.

Dare I suggest that the IETF tools team could make a source control
repository available to the IETF community? I keep all my I-Ds in SVN,
but perhaps I'm strange in that way.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071101/145fb1ec/smime.bin
>From Miguel.Garcia at nsn.com  Fri Nov  2 11:50:05 2007
From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Fri Nov  2 01:51:04 2007
Subject: [xml2rfc] dupes in bibxml3
Message-ID: <[email-masked]>

Hi:

I was revising the index file of the I-D bibliography,
http://xml.resource.org/public/rfc/bibxml3/index.xml

and I noticed that the file lists several versions of the same 
Internet-Draft. For example, take draft-ietf-simple-xcap-diff and there 
are versions 03, 04, 05, and 06.

I was wondering if this is done on purpose or is it an oversight? I was 
expecting that the index file contains only the most recent version of a 
given draft.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: pbaker at verisign.com (Hallam-Baker, Phillip)
Date: Fri Nov  2 06:06:00 2007
Subject: [xml2rfc] RE: HTML2xml?
References:  <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss.
 
I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver.

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Thu 01/11/2007 4:34 PM
To: [email-masked]
Subject: Re: [xml2rfc] RE: HTML2xml?

   From: "Hallam-Baker, Phillip" <[email-masked]>

   It then occurred to me that ideally this process would be performed
   automatically and that if this was supported it would then be possible
   to take an RFC in HTML form and recover the original XML for editing. I
   would much rather do this if I was going to produce a new version of a
   published RFC rather than rely on someone having kept the correct
   version of the XML.

The XML to HTML transformation is information-losing, so I wouldn't
expect reversing it to be easy.  But it might be feasible to create a
tool that takes the XML, the original HTML, and edited HTML and
back-ports the changes into the XML.

Dale
_______________________________________________
xml2rfc mailing list
[email-masked]
http://lists.xml.resource.org/mailman/listinfo/xml2rfc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071102/b8588605/attachment-0001.htm
>From julian.reschke at gmx.de  Fri Nov  2 15:20:27 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Nov  2 06:20:38 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hallam-Baker, Phillip wrote:
> Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss.
>  
> I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver.

Well,

I'm always happy to give rfc2629.xslt new capabilities. What I'm not so 
sure about is...: what's the chance that the XML source is lost, but the 
HTML version is available?

BR, Julian
>From pbaker at verisign.com  Fri Nov  2 07:36:53 2007
From: pbaker at verisign.com (Hallam-Baker, Phillip)
Date: Fri Nov  2 06:37:33 2007
Subject: [xml2rfc] RE: HTML2xml?
References: 
	<[email-masked]><[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

I would say very high.
 
The problem is not just losing a copy of the XML, its losing a copy of the final XML used to generate the RFC and thus getting out of sync.
 
Its a question of what the canonical version is. The HTML version is going to survive because its the one people are going to build to (or alternatively the O'Riely book). Its probably possible to recover the information by screen scraping but RDFa is easier.

Semantic Web is only a fancy name for 'don't throw away information that might be useful'.

________________________________

From: Julian Reschke [mailto:[email-masked]]
Sent: Fri 02/11/2007 9:20 AM
To: Hallam-Baker, Phillip
Cc: [email-masked]; [email-masked]
Subject: Re: [xml2rfc] RE: HTML2xml?

Hallam-Baker, Phillip wrote:
> Thats actually my point, the xml to HTML transformation probably does lose information, but that does not have to be the case. In fact RDFa was designed expressly to avoid information loss.
> 
> I have to get my drafts out today but I might get a chance to put a few hours in on this before Vancouver.

Well,

I'm always happy to give rfc2629.xslt new capabilities. What I'm not so
sure about is...: what's the chance that the XML source is lost, but the
HTML version is available?

BR, Julian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071102/d7c19435/attachment.htm
>From swb at employees.org  Fri Nov  2 11:04:47 2007
From: swb at employees.org (Scott Brim)
Date: Fri Nov  2 07:05:18 2007
Subject: [xml2rfc] dupes in bibxml3
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Excerpts from Miguel Garcia on Fri, Nov 02, 2007 10:50:05AM +0200:
> Hi:
>
> I was revising the index file of the I-D bibliography,
> http://xml.resource.org/public/rfc/bibxml3/index.xml
>
> and I noticed that the file lists several versions of the same 
> Internet-Draft. For example, take draft-ietf-simple-xcap-diff and there are 
> versions 03, 04, 05, and 06.
>
> I was wondering if this is done on purpose or is it an oversight? I was 
> expecting that the index file contains only the most recent version of a 
> given draft.

I'm (still) in favor of keeping all of them.  That allows you to refer
to a specific version.  If you want to refer to the latest version,
whatever it is, you can leave off the version number.
>From mrose at dbc.mtview.ca.us  Fri Nov  2 10:57:10 2007
From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Nov  2 07:57:31 2007
Subject: [xml2rfc] dupes in bibxml3
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> I was wondering if this is done on purpose or is it an oversight?  
>> I was
>> expecting that the index file contains only the most recent  
>> version of a
>> given draft.
>
> I'm (still) in favor of keeping all of them.  That allows you to refer
> to a specific version.  If you want to refer to the latest version,
> whatever it is, you can leave off the version number.

miguel - it is that way on purpose, precisely for the reason that  
scott gives.

/mtr

From: fenner at gmail.com (Bill Fenner)
Date: Fri Nov  2 11:10:04 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Julian asked what the likelyhood of not having the XML but yes having
the HTML version of the final version of an existing RFC, and
On 11/2/07, Hallam-Baker, Phillip <[email-masked]> wrote:
> I would say very high.
>
> The problem is not just losing a copy of the XML, its losing a copy of the
> final XML used to generate the RFC and thus getting out of sync.
>
> Its a question of what the canonical version is. The HTML version is going
> to survive because its the one people are going to build to (or
> alternatively the O'Riely book). Its probably possible to recover the
> information by screen scraping but RDFa is easier.

Pardon my ignorance, but can you point me to an example HTML version
of an existing RFC?  I missed the central place where these were being
collected but the associated XML file was not.

Thanks,
  Bill
>From jvasseur at cisco.com  Fri Nov  2 15:57:31 2007
From: jvasseur at cisco.com (JP Vasseur)
Date: Fri Nov  2 11:57:55 2007
Subject: [xml2rfc] Cannot open File ...
Message-ID: <[email-masked]>

Hi,

I just re-install XXE, XML2RFC... and I now got an error message when  
opening a .xml file:

Cannot open file "XXX": /Users/jp/IETF/rfc2629.dtd (no such file or  
directory).

Any help would be appreciated.

Many Thanks.

JP.
>From henrik at levkowetz.com  Sat Nov  3 03:44:20 2007
From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Nov  2 18:44:35 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi Peter,

On 2007-11-01 22:36 Peter Saint-Andre said the following:
>>>    From: "Hallam-Baker, Phillip" <[email-masked]>
>>>
>>>    I would much rather do this if I was going to produce a new version of
>>>    a published RFC rather than rely on someone having kept the correct
>>>    version of the XML.
> 
> Dare I suggest that the IETF tools team could make a source control
> repository available to the IETF community? I keep all my I-Ds in SVN,
> but perhaps I'm strange in that way.

This seems to have been moving closer to the top of the wish list over
the last year or so.  We'll try to set something up.

	Henrik
>From julian.reschke at gmx.de  Sat Nov  3 14:32:54 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Nov  3 05:33:03 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Bill Fenner wrote:
> Julian asked what the likelyhood of not having the XML but yes having
> the HTML version of the final version of an existing RFC, and
> On 11/2/07, Hallam-Baker, Phillip <[email-masked]> wrote:
>> I would say very high.
>>
>> The problem is not just losing a copy of the XML, its losing a copy of the
>> final XML used to generate the RFC and thus getting out of sync.
>>
>> Its a question of what the canonical version is. The HTML version is going
>> to survive because its the one people are going to build to (or
>> alternatively the O'Riely book). Its probably possible to recover the
>> information by screen scraping but RDFa is easier.
> 
> Pardon my ignorance, but can you point me to an example HTML version
> of an existing RFC?  I missed the central place where these were being
> collected but the associated XML file was not.

I've been working on RCF2629 related tools for over six years now, and I 
also have translated several specs to XML format (RFC2396, RFC2616, 
RFC2518...).

All that time, I never saw an HTML version, but no XML version -- I was 
always using the ASCII version as a base.

So Philip, if this happened to you maybe it makes sense to find out what 
happened there, and try to fix that.

Best regards, Julian
>From tony at att.com  Sat Nov  3 09:44:43 2007
From: tony at att.com (Tony Hansen)
Date: Sat Nov  3 05:46:02 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]>
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

I've got several RFCs that I've worked on with co-authors. When
reviewing drafts with my co-authors, I have to agree with Phillip that
the HTML versions are usually easier on the eyes for reading. Variable
sized fonts, highlighted figures and colors all add in.

When I generate an updated version to send to my co-authors, I've taken
to sending them all three versions: .txt, .xml and .html.

	Tony Hansen
	[email-masked]

Julian Reschke wrote:
>>
>> Pardon my ignorance, but can you point me to an example HTML version
>> of an existing RFC?  I missed the central place where these were being
>> collected but the associated XML file was not.
> 
> I've been working on RCF2629 related tools for over six years now, and I
> also have translated several specs to XML format (RFC2396, RFC2616,
> RFC2518...).
> 
> All that time, I never saw an HTML version, but no XML version -- I was
> always using the ASCII version as a base.
> 
> So Philip, if this happened to you maybe it makes sense to find out what
> happened there, and try to fix that.

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Sat Nov  3 09:04:28 2007
Subject: [xml2rfc] Including files in the input?
Message-ID: <p06240803c3524c1345a3@[10.0.0.108]>

Hi again. What is the preferred method to include files into the XML 
input for xml2rfc? I have a bunch of ASN.1 modules that are going to 
be figures that will be in play outside of the draft.

--Paul Hoffman, Director
--VPN Consortium
>From Dale.Worley at comcast.net  Sat Nov  3 22:59:15 2007
From: Dale.Worley at comcast.net ([email-masked])
Date: Sat Nov  3 19:59:25 2007
Subject: [xml2rfc] RE: HTML2xml?
In-Reply-To: <[email-masked]> ([email-masked])
References: 
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]>
	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

   From: Tony Hansen <[email-masked]>

   Variable sized fonts, highlighted figures and colors all add in.

What about BLINK and SCROLL?

Dale
>From Miguel.Garcia at nsn.com  Mon Nov  5 10:45:07 2007
From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Mon Nov  5 00:46:32 2007
Subject: [xml2rfc] dupes in bibxml3
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Marshall Rose wrote:
>>> I was wondering if this is done on purpose or is it an oversight? I was
>>> expecting that the index file contains only the most recent version of a
>>> given draft.
>>
>> I'm (still) in favor of keeping all of them.  That allows you to refer
>> to a specific version.  If you want to refer to the latest version,
>> whatever it is, you can leave off the version number.
> 
> miguel - it is that way on purpose, precisely for the reason that scott 
> gives.
> 

OK, no problem if the purpose is to keep the dupes. I was asking because 
of a side-by project, where I am using the bibxml3/index.xml file to 
create a bib file of Internet-Drafts. It seems that Latex complains 
about the dupes, and selects the first one it finds, which usually is 
the older. This is a not a big deal, I can remove dupes myself.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Mon Nov  5 06:11:23 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <p06240803c3524c1345a3@[10.0.0.108]>
References: <p06240803c3524c1345a3@[10.0.0.108]>
Message-ID: <[email-masked]>

On Sat, Nov 03, 2007 at 11:03:39AM -0500,
 Paul Hoffman <[email-masked]> wrote 
 a message of 10 lines which said:

> What is the preferred method to include files into the XML input for
> xml2rfc?

I use entities:

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY info-references SYSTEM "informative-references.xml">
...
]>

&info-references;

If the input file is not XML (your case), I preprocess it for escaping:

<!ENTITY grammar SYSTEM "sm-escaped.abnf">

And in the Makefile:

sm-escaped.abnf: sm.abnf
	xmlstarlet escape < $< > $@
>From paul.hoffman at vpnc.org  Mon Nov  5 08:25:59 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Mon Nov  5 08:26:10 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: <p06240803c3524c1345a3@[10.0.0.108]>
 <[email-masked]>
Message-ID: <p06240809c354f44e0320@[10.20.30.108]>

At 3:11 PM +0100 11/5/07, Stephane Bortzmeyer wrote:
>On Sat, Nov 03, 2007 at 11:03:39AM -0500,
>  Paul Hoffman <[email-masked]> wrote
>  a message of 10 lines which said:
>
>>  What is the preferred method to include files into the XML input for
>>  xml2rfc?
>
>I use entities:
>
><!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
><!ENTITY info-references SYSTEM "informative-references.xml">
>...
>]>
>
>&info-references;

This makes good sense. Thanks!

>If the input file is not XML (your case), I preprocess it for escaping:
>
><!ENTITY grammar SYSTEM "sm-escaped.abnf">
>
>And in the Makefile:
>
>sm-escaped.abnf: sm.abnf
>	xmlstarlet escape < $< > $@

Had not heard of xlmstarlet; looks nice!

--Paul Hoffman, Director
--VPN Consortium
>From paul.hoffman at vpnc.org  Wed Nov  7 13:41:25 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Nov  7 13:41:38 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: <p06240803c3524c1345a3@[10.0.0.108]>
 <[email-masked]>
Message-ID: <p06240813c357e0c87bbd@[10.20.30.150]>

At 3:11 PM +0100 11/5/07, Stephane Bortzmeyer wrote:
>On Sat, Nov 03, 2007 at 11:03:39AM -0500,
>  Paul Hoffman <[email-masked]> wrote
>  a message of 10 lines which said:
>
>>  What is the preferred method to include files into the XML input for
>>  xml2rfc?
>
>I use entities:
>
><!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
><!ENTITY info-references SYSTEM "informative-references.xml">
>...
>]>
>
>&info-references;

OK, here's a wrinkle: the files I'm including are actually figures. 
Therefore I have:

<section title="ASN.1 Module for RFC 2560">

<figure><artwork><![CDATA[
&rfc2560.asn;
]]></artwork></figure>

</section>

This, of course, doesn't work because the entity is not pulled in; 
the text "&rfc2560.asn;" is inserted.

I could, with a lot of effort, make files that wrap the 
"<figure><artwork><![CDATA[ ]]></artwork></figure>" goop around the 
actual included text, but would prefer not to. Any thoughts on an 
easier way to do this? I have a lot of modules....

--Paul Hoffman, Director
--VPN Consortium
>From carl at media.org  Wed Nov  7 15:38:31 2007
From: carl at media.org (Carl Malamud)
Date: Wed Nov  7 15:38:38 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <p06240813c357e0c87bbd@[10.20.30.150]>
Message-ID: <[email-masked]>

> <figure><artwork><![CDATA[
> &rfc2560.asn;
> ]]></artwork></figure>

can you have the relevant lines (<figure><artwork ...)
contained in rfc2560.asn?  That simplifies the above
code to:

&rfc2560.asn;

and, solves your problem.

Carl
>From paul.hoffman at vpnc.org  Wed Nov  7 17:57:26 2007
From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Nov  7 17:57:43 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <p06240822c3581d6bb20d@[10.20.30.150]>

At 3:38 PM -0800 11/7/07, Carl Malamud wrote:
>  > <figure><artwork><![CDATA[
>>  &rfc2560.asn;
>>  ]]></artwork></figure>
>
>can you have the relevant lines (<figure><artwork ...)
>contained in rfc2560.asn?  That simplifies the above
>code to:
>
>&rfc2560.asn;
>
>and, solves your problem.

Right. Barring anything more creative, I have already coded that, but 
wanted to use something less intrusive.

--Paul Hoffman, Director
--VPN Consortium
>From Miguel.Garcia at nsn.com  Thu Nov  8 12:10:32 2007
From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Thu Nov  8 02:11:17 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
Message-ID: <[email-masked]>

Hi:

I just downloaded both the zip and tgz files of the bibxml3 
bibliography, and I cannot extract the files on a Windows platform. 
Winzip reports the following error:

The following invalid filename was encountered in the archive: 
"rdf\index.html?N=D"

I suspect the "?N=D" disturbs the file creation. The are other similar 
errors with the other combinations of letters on the same file. 
Fortunately, the zip file extracts (the rest of the files), but this is 
something you may want to look at.

BR,

      Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: dave at cridland.net (Dave Cridland)
Date: Thu Nov  8 02:20:02 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <p06240813c357e0c87bbd@[10.20.30.150]>
References: <p06240803c3524c1345a3@[10.0.0.108]> <[email-masked]> <p06240813c357e0c87bbd@[10.20.30.150]>
Message-ID: <[email-masked]>

On Wed Nov  7 21:41:25 2007, Paul Hoffman wrote:
> <figure><artwork><![CDATA[
> &rfc2560.asn;
> ]]></artwork></figure>

Why the <![CDATA[ ... ]]>? That will prevent expansion of entity  
references.

Can't you define the external entity as NDATA instead, and do things  
that way?

Erm. Something like <!ENTITY rfc2560.asn SYSTEM "rfc2560.asn" NDATA  
asn>, then do:

<figure><artwork>
&rfc2560;
</artwork></figure>

You might need <!NOTATION asn "urn:x-some-urn"> to declare the  
notation. That ought to work, I'd have thought.

I know SGML allows for CDATA declared external entities, I'm not sure  
if XML does. (I'm not an XML guru, I just happened on this yesterday).

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From bortzmeyer at nic.fr  Thu Nov  8 12:27:35 2007
From: bortzmeyer at nic.fr (Stephane Bortzmeyer)
Date: Thu Nov  8 03:27:39 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <p06240813c357e0c87bbd@[10.20.30.150]>
References: <p06240803c3524c1345a3@[10.0.0.108]>
	<[email-masked]> <p06240813c357e0c87bbd@[10.20.30.150]>
Message-ID: <[email-masked]>

On Wed, Nov 07, 2007 at 01:41:25PM -0800,
 Paul Hoffman <[email-masked]> wrote 
 a message of 38 lines which said:

> OK, here's a wrinkle: the files I'm including are actually figures. 

No problem.

> Therefore I have:
> 
> <section title="ASN.1 Module for RFC 2560">
> 
> <figure><artwork><![CDATA[

Bad. Do not use CDATA (which will prevent entity expansion). And
escape the file with xmlstarlet, as shown in my first message. And use
make to automate the process.

From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Thu Nov  8 03:30:36 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
Message-ID: <[email-masked]>

Hi:

I don't think this is very important, but I suspect there is an error in 
the bibxml3/index.xml file: not all the authors of a draft are listed.

For example, in draft-ietf-mmusic-file-transfer-mech-00, -02, and -03, 
only myself is listed as an author, in spite there are other 3 
co-authors. However, in version -04, the complete list of co-authors is 
included. So, it seems that there is an error in the script that 
generates the file.

The references I am referring to are:

<reference 
target2='reference.I-D.draft-garcia-mmusic-file-transfer-mech-00.xml' 
anchor='I-D.garcia-mmusic-file-transfer-mech'>

<reference 
target2='reference.I-D.draft-ietf-mmusic-file-transfer-mech-02.xml' 
anchor='I-D.ietf-mmusic-file-transfer-mech'>

<reference 
target2='reference.I-D.draft-ietf-mmusic-file-transfer-mech-03.xml' 
anchor='I-D.ietf-mmusic-file-transfer-mech'>

<reference 
target2='reference.I-D.draft-ietf-mmusic-file-transfer-mech-04.xml' 
anchor='I-D.ietf-mmusic-file-transfer-mech'>

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Nov  8 05:08:28 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 2007-11-8, at 3:30, ext Miguel Garcia wrote:
> I don't think this is very important, but I suspect there is an  
> error in the bibxml3/index.xml file: not all the authors of a draft  
> are listed.

I came across this in the past. The issue is that the 1id-index.txt  
issued by the secretariat doesn't have the full author information,  
either.

(I have had a ticket open with them on this for about 2-3 years now...)

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/a8324b88/smime.bin
>From Miguel.Garcia at nsn.com  Thu Nov  8 15:14:25 2007
From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Thu Nov  8 05:14:54 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Lars Eggert wrote:
> On 2007-11-8, at 3:30, ext Miguel Garcia wrote:
>> I don't think this is very important, but I suspect there is an error 
>> in the bibxml3/index.xml file: not all the authors of a draft are listed.
> 
> I came across this in the past. The issue is that the 1id-index.txt 
> issued by the secretariat doesn't have the full author information, either.
> 

I don't buy the argument. First, the 1id-index.txt only contains the 
latest version of a draft. Second, for that latest version, it seems to 
contain the complete list of authors.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Nov  8 05:40:21 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-11-8, at 5:14, Miguel Garcia wrote:
> I don't buy the argument. First, the 1id-index.txt only contains  
> the latest version of a draft. Second, for that latest version, it  
> seems to contain the complete list of authors.

I think the bibxml file is being incrementally added to based on the  
most recent 1id-index.txt.

Older versions of 1id-index.txt had fewer authors. I have an old copy  
of 1id-index.txt from Jan 2007 lying around that has the -00 version  
of your draft with just you as an author:

   "A Session Description Protocol (SDP) Offer/Answer Mechanism to  
Enable File
   Transfer", Miguel Garcia-Martin, 18-Dec-06,
   <draft-ietf-mmusic-file-transfer-mech-00.txt>

The current version has:

   "A Session Description Protocol (SDP) Offer/Answer Mechanism to  
Enable File
   Transfer", Miguel Garcia-Martin, Markus Isomaki, Gonzalo  
Camarillo, Salvatore
   Loreto, 24-Oct-07, <draft-ietf-mmusic-file-transfer-mech-04.txt>

And the secretariat policy on how many authors to list appears to be  
"it varies."

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/b1522440/smime-0001.bin
>From dbharrington at comcast.net  Thu Nov  8 09:33:12 2007
From: dbharrington at comcast.net (David B Harrington)
Date: Thu Nov  8 06:33:41 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: 
	<p06240803c3524c1345a3@[10.0.0.108]><[email-masked]>
	<p06240813c357e0c87bbd@[10.20.30.150]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I've been in the discussion about includes before, so let me explain
what my needs were, so people proposing solutions understand some of
the issues better. 

In my case, the document to be included is a MIB module in text
format, ready to be parsed by MIB module validation tools. You cannot
put the <CDATA> in the MIB module itself without a likelihood of
making the MIB module file invalid, or potentially breaking existing
applications that would not expect to find a <CDATA> tag in a MIB
module.

A MIB module uses a non-XML syntax, so if the entity reference is
XML-parsed when it is included, it will probably cause the XML file to
be invalid.

If you depend on an external application to preprocess the included
file, you need to be sure the preprocessing doesn't modify the MIB
module in a way that would make the MIB specification printed in the
resulting internet-draft an invalid MIB module. The included <figure>
must be able to work for people who use commonly-available tools to
extract the MIB module from internet-drafts or RFCs, and then use the
extracted file with validation/compilation tools. So a preprocessor
that modifies the figure being included is inappropriate.

Some people work in UNIX or Linux, and others work in Windows. Some
people do not work in environments that utilize makefiles (not
everybody working on these documents are software engineers). Solving
the problem by depending on a makefile to call an external
preprocessor application can be problematic for some part of the
intended audience, and that is not desirable either.

So far, I have not found a solution for including a MIB module
effectively.

I suspect that Paul's needs are similar, in that he is trying to
include documents that have their own sets of validity requirements
outside the xml2rfc environment.

I have not experimented with the xmlstarlet tool, but I will look to
see if this can help to solve the problem when including MIB modules.

David Harrington
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Stephane Bortzmeyer
> Sent: Thursday, November 08, 2007 6:28 AM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: [xml2rfc] Re: Including files in the input?
> 
> On Wed, Nov 07, 2007 at 01:41:25PM -0800,
>  Paul Hoffman <[email-masked]> wrote 
>  a message of 38 lines which said:
> 
> > OK, here's a wrinkle: the files I'm including are actually
figures. 
> 
> No problem.
> 
> > Therefore I have:
> > 
> > <section title="ASN.1 Module for RFC 2560">
> > 
> > <figure><artwork><![CDATA[
> 
> Bad. Do not use CDATA (which will prevent entity expansion). And
> escape the file with xmlstarlet, as shown in my first message. And
use
> make to automate the process.
> 
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Nov  8 06:47:28 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References:  <p06240803c3524c1345a3@[10.0.0.108]><[email-masked]> <p06240813c357e0c87bbd@[10.20.30.150]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

David B Harrington wrote:
> Hi,
> 
> I've been in the discussion about includes before, so let me explain
> what my needs were, so people proposing solutions understand some of
> the issues better. 
> ...

When I need this -- for instance for ABNF -- I do the reverse: I edit 
the text inline, but use a tool 
(<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork>) 
to extract the artwork as a text file.

Best regards, Julian
>From fenner at gmail.com  Thu Nov  8 07:42:15 2007
From: fenner at gmail.com (Bill Fenner)
Date: Thu Nov  8 07:42:19 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
	 <[email-masked]>
Message-ID: <[email-masked]>

On 11/8/07, Miguel Garcia <[email-masked]> wrote:
> Lars Eggert wrote:
> > On 2007-11-8, at 3:30, ext Miguel Garcia wrote:
> >> I don't think this is very important, but I suspect there is an error
> >> in the bibxml3/index.xml file: not all the authors of a draft are listed.
> >
> > I came across this in the past. The issue is that the 1id-index.txt
> > issued by the secretariat doesn't have the full author information, either.
> >
>
> I don't buy the argument.

Unfortunately, it's full of correct facts.

> First, the 1id-index.txt only contains the
> latest version of a draft.

And the version -nn.xml files are generated when the 1id-abstracts.txt
(not 1id-index.txt) contains that version as the latest version.

> Second, for that latest version, it seems to
> contain the complete list of authors.

Presumably because you submitted the latest version using the I-D
Submission Tool.

The secretariat's policy for I-Ds submitted via email is to extract
only the first author (or if there are only two authors, extract two
authors).  This policy was implemented a few years ago to save
man-hours.

The I-D Submission Tool does this work itself, so the
1id-abstracts.txt file is back to listing all of the authors for
drafts submitted using the tool.  This means that as more drafts are
submitted using the tool, more of the bibxml3 files will contain
complete author lists - however there is no way to go back in time and
fix the ones that were generated when the author lists were
incomplete.

  Bill
>From lars.eggert at nokia.com  Thu Nov  8 07:47:10 2007
From: lars.eggert at nokia.com (Lars Eggert)
Date: Thu Nov  8 07:48:16 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On 2007-11-8, at 7:42, ext Bill Fenner wrote:
> however there is no way to go back in time and
> fix the ones that were generated when the author lists were
> incomplete

It might be possible to run Jari's authorstats tool over a dump of  
the watersprings archive, and generate bibxml files from that, rather  
than from secretariat data.

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://drakken.dbc.mtview.ca.us/pipermail/xml2rfc/attachments/20071108/5807ab54/smime.bin
>From bortzmeyer at nic.fr  Thu Nov  8 17:08:58 2007
From: bortzmeyer at nic.fr ('Stephane Bortzmeyer')
Date: Thu Nov  8 08:09:02 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: <p06240813c357e0c87bbd@[10.20.30.150]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Thu, Nov 08, 2007 at 09:33:12AM -0500,
 David B Harrington <[email-masked]> wrote 
 a message of 84 lines which said:

> you need to be sure the preprocessing doesn't modify the MIB module
> in a way that would make the MIB specification printed in the
> resulting internet-draft an invalid MIB module.

That's obvious. If you find that xmlstarlet or another program
modifies the content of the file (the infoset, to use proper XML
vocabulary), report it ASAP as a serious bug.

> So a preprocessor that modifies the figure being included is
> inappropriate.

Even more, it would be completely broken.
 
> Some people work in UNIX or Linux, and others work in Windows. 

This last category uses RFC 3285 so they're not on this list :-)

From: bortzmeyer at nic.fr ('Stephane Bortzmeyer')
Date: Thu Nov  8 08:27:46 2007
Subject: [xml2rfc] Re: Including files in the input?
In-Reply-To: <[email-masked]>
References: <p06240813c357e0c87bbd@[10.20.30.150]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Thu, Nov 08, 2007 at 05:08:58PM +0100,
 'Stephane Bortzmeyer' <[email-masked]> wrote 
 a message of 25 lines which said:

> That's obvious. If you find that xmlstarlet or another program
> modifies the content of the file (the infoset, to use proper XML
> vocabulary), report it ASAP as a serious bug.

I just made some tests and everything seems OK. MIBs are much easier
than ABNF files for XML, they do not appear to contain characters that
are special for XML (except in CONTACT-INFO with things like the email
address of the author) so most MIB converted by xmlstartlet yield the
same file, byte for byte.
>From nobody at xyzzy.claranet.de  Thu Nov  8 18:50:07 2007
From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Thu Nov  8 09:50:54 2007
Subject: [xml2rfc] Re: Including files in the input?
References: 
	<p06240813c357e0c87bbd@[10.20.30.150]><[email-masked]><[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Stephane Bortzmeyer wrote:
 
>> Some people work in UNIX or Linux, and others work in Windows. 
> This last category uses RFC 3285 so they're not on this list :-)

I've seriously considered a kind of awk2xml script.  With a text
editor xml2rfc format is rather verbose, and I could live with a
minimal subset of the xml2rfc features, or rather "my" subset...

 Frank
-- 
...some users try to install REXX and XEDIT on _any_ platform ;-)

From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Thu Nov  8 10:20:59 2007
Subject: [xml2rfc] Number of authors in bibxml3/index.xml
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>	 <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Aha.... thanks for the explanation. Yes, I submitted my draft with the 
automatic tool. Hopefully, the manual system will cease at some near 
point in time in the future.

/Miguel

Bill Fenner wrote:
> On 11/8/07, Miguel Garcia <[email-masked]> wrote:
>> Lars Eggert wrote:
>>> On 2007-11-8, at 3:30, ext Miguel Garcia wrote:
>>>> I don't think this is very important, but I suspect there is an error
>>>> in the bibxml3/index.xml file: not all the authors of a draft are listed.
>>> I came across this in the past. The issue is that the 1id-index.txt
>>> issued by the secretariat doesn't have the full author information, either.
>>>
>> I don't buy the argument.
> 
> Unfortunately, it's full of correct facts.
> 
>> First, the 1id-index.txt only contains the
>> latest version of a draft.
> 
> And the version -nn.xml files are generated when the 1id-abstracts.txt
> (not 1id-index.txt) contains that version as the latest version.
> 
>> Second, for that latest version, it seems to
>> contain the complete list of authors.
> 
> Presumably because you submitted the latest version using the I-D
> Submission Tool.
> 
> The secretariat's policy for I-Ds submitted via email is to extract
> only the first author (or if there are only two authors, extract two
> authors).  This policy was implemented a few years ago to save
> man-hours.
> 
> The I-D Submission Tool does this work itself, so the
> 1id-abstracts.txt file is back to listing all of the authors for
> drafts submitted using the tool.  This means that as more drafts are
> submitted using the tool, more of the bibxml3 files will contain
> complete author lists - however there is no way to go back in time and
> fix the ones that were generated when the author lists were
> incomplete.
> 
>   Bill

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Nov  8 11:12:40 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I just downloaded both the zip and tgz files of the bibxml3  
> bibliography, and I cannot extract the files on a Windows platform.  
> Winzip reports the following error:
>
> The following invalid filename was encountered in the archive: "rdf 
> \index.html?N=D"
>
> I suspect the "?N=D" disturbs the file creation. The are other  
> similar errors with the other combinations of letters on the same  
> file. Fortunately, the zip file extracts (the rest of the files),  
> but this is something you may want to look at.

thanks. try this:

go to http://www1.xml.resource.org/

download the .zip file from there.

tell me if that one is broken.

/mtr

From: Miguel.Garcia at nsn.com (Miguel Garcia)
Date: Thu Nov  8 13:00:51 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>> I just downloaded both the zip and tgz files of the bibxml3 
>> bibliography, and I cannot extract the files on a Windows platform. 
>> Winzip reports the following error:
>>
>> The following invalid filename was encountered in the archive: 
>> "rdf\index.html?N=D"
>>
>> I suspect the "?N=D" disturbs the file creation. The are other similar 
>> errors with the other combinations of letters on the same file. 
>> Fortunately, the zip file extracts (the rest of the files), but this 
>> is something you may want to look at.
> 
> thanks. try this:
> 
> go to http://www1.xml.resource.org/
> 
> download the .zip file from there.
> 
> tell me if that one is broken.

That one didn't have the problem.

Thanks

/Miguel

> 
> /mtr
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Thu Nov  8 15:47:57 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> That one didn't have the problem.

interesting.

we'll keep an eye on it.

/mtr

From: henrik at levkowetz.com (Henrik Levkowetz)
Date: Fri Nov  9 01:04:34 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On 2007-11-09 00:47 Marshall Rose said the following:
>> That one didn't have the problem.
> 
> interesting.
> 
> we'll keep an eye on it.

I found some old index.html\?* files lying around on www3.xml.resource.org.
Removed now, so this should be fixed.

	Henrik
>From julian.reschke at gmx.de  Fri Nov  9 15:18:03 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Nov  9 06:18:09 2007
Subject: [xml2rfc] Making document references more powerful
Message-ID: <[email-masked]>

Hi,

I just finished (hopefully) an experimental feature in rfc2629.xslt 
which makes it simpler to handle cross-document references; for instance 
when editing a multi-part spec.

It builds on an earlier extension which allows to augment a document 
reference with section and anchor information, such as in:

	... <xref target="REC-xml" x:fmt="sec" x:sec="2.12" 
x:rel="#sec-lang-tag"/> ...

When generating HTML, this results in

	... <a 
href="http://www.w3.org/TR/2006/REC-xml-20060816#sec-lang-tag">2.12</a> ...

("2.12" becoming a link to the right target section). It's possible to 
"downgrade" source using these extensions (see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#clean-for-dtd>), 
in which case

	... <xref target="REC-xml" x:fmt="sec" x:sec="2.12" 
x:rel="#sec-lang-tag"/> ...

is simply replaced with

	... 2.12 ...

Note that HTML links can only be generated when the reference either has 
a "target" attribute, or if the seriesInfo allows the processor to find 
out how to link to it (for instance, using the HTMLized versions on 
tools.ietf.org).

There are some variations to this, such as choosing a particular output 
format. For instance

	... <xref target="RFC3986" x:fmt="of" x:sec="5.1.1"/> ...

gets you

	... <a href="http://tools.ietf.org/html/rfc3986#section-5.1.1">Section 
5.1.1</a> of <a href="#RFC3986">[RFC3986]</a>

For the details, read 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>.

What's new is that this extends to section references where the XML 
source of the target doc is available.

So for instance in rfc2617.xml 
(<http://greenbytes.de/tech/webdav/rfc2617.xml>), I now use

    ... <xref target="RFC2616" x:fmt="number" x:rel
="#notation.abnf"/> ...

to generate a link to Section 2.1 of RFC2616. This is done by enhancing 
the reference element for RFC2616 with a pointer to the XML source -- 
see 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext.element.source>.

Note that all of this can be used with xml2rfc as well, it just needs 
one additional preprocessing step.

Feedback appreciated,

Julian

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Fri Nov  9 07:13:30 2007
Subject: [xml2rfc] Error uncompressing bibxml3.zip
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> I found some old index.html\?* files lying around on  
> www3.xml.resource.org.
> Removed now, so this should be fixed.

thanks!

/mtr

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Tue Nov 13 04:27:13 2007
Subject: [xml2rfc] New boilerplate
Message-ID: <[email-masked]>

Hi, I just saw that the RFC editor removes the...

| Copyright Notice
|
|   Copyright (C) The IETF Trust (2007).

... and the...

| Acknowledgment
|   Funding for the RFC Editor function is provided by the IETF
|   Administrative Support Activity (IASA).

See <http://rfc-editor.org/news.html> for details.

 Frank

From: dbharrington at comcast.net (David B Harrington)
Date: Tue Nov 13 07:29:36 2007
Subject: [xml2rfc] New boilerplate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

They are dropping the **redundant** copyright from the front page.
They are keeping the copyright that is elsewhere in the document. 

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Frank
Ellermann
> Sent: Tuesday, November 13, 2007 7:21 AM
> To: [email-masked]
> Subject: [xml2rfc] New boilerplate
> 
> Hi, I just saw that the RFC editor removes the...
> 
> | Copyright Notice
> |
> |   Copyright (C) The IETF Trust (2007).
> 
> ... and the...
> 
> | Acknowledgment
> |   Funding for the RFC Editor function is provided by the IETF
> |   Administrative Support Activity (IASA).
> 
> See <http://rfc-editor.org/news.html> for details.
> 
>  Frank
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
> 

From: EdwardB at actelis.com (Edward Beili)
Date: Sun Nov 18 05:22:16 2007
Subject: [xml2rfc] XML Citation Library updates
Message-ID: <[email-masked]>

Hello,
I am trying to update the XML citation library with a newly published
RFC, so I could reference it in the new drafts.
However my repeated emails to [email-masked] (this is the
address specified on http://xml.resource.org/ ) were ignored and the
files I sent are still not on http://xml.resource.org/public/rfc

Is there another address I should the files to?

Regards,
-E.

From: mrose at dbc.mtview.ca.us (Marshall Rose)
Date: Sun Nov 18 14:27:20 2007
Subject: [xml2rfc] XML Citation Library updates
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

> I am trying to update the XML citation library with a newly published
> RFC, so I could reference it in the new drafts.
> However my repeated emails to [email-masked] (this is the
> address specified on http://xml.resource.org/ ) were ignored and the
> files I sent are still not on http://xml.resource.org/public/rfc
>
> Is there another address I should the files to?

the spam filter is probably too aggressive on that address.

send me an email with the files directly.

thanks,

/mtr

From: aaron at serendipity.cx (Aaron Stone)
Date: Wed Dec  5 11:28:59 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
Message-ID: <[email-masked]>

Hi,

In the Sieve mail filter series of documents, we use the [DOCNAME]
citation style rather extensively, and avoid [RFCxxx] references wherever
possible. This dramatically increases readability. For example (from
draft-ietf-sieve-notify-xmpp-07.txt):

1.1. Overview

   The [NOTIFY] extension to the [SIEVE] mail filtering language is a
   framework for providing notifications by employing URIs to specify
   the notification mechanism.  This document defines how xmpp URIs (see
   [XMPP-URI]) are used to generate notifications via the Extensible
   Messaging and Presence Protocol [XMPP], which is widely implemented
   in Jabber instant messaging technologies.

I cannot figure out how to do this in xml2rfc :-(

If there's no mechanism in place, I propose creating one...

I'm thinking either...

 o the document reference database include a friendly name in its xml
   definition.
 o add a 'nickname' mechanism in the <!ENTITY ...> that includes the 
   reference from the common database.

I'm very much against pulling all of the references into the document just
to add a cute name to it. That defeats the purpose of the common database
of references.

Aaron

From: tony at att.com (Tony Hansen)
Date: Wed Dec  5 11:48:25 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

<xref target="RFCXXXX">NOTIFY</xref>

Aaron Stone wrote:
> Hi,
> 
> In the Sieve mail filter series of documents, we use the [DOCNAME]
> citation style rather extensively, and avoid [RFCxxx] references wherever
> possible. This dramatically increases readability. For example (from
> draft-ietf-sieve-notify-xmpp-07.txt):
> 
> 1.1. Overview
> 
>    The [NOTIFY] extension to the [SIEVE] mail filtering language is a
>    framework for providing notifications by employing URIs to specify
>    the notification mechanism.  This document defines how xmpp URIs (see
>    [XMPP-URI]) are used to generate notifications via the Extensible
>    Messaging and Presence Protocol [XMPP], which is widely implemented
>    in Jabber instant messaging technologies.
> 
> I cannot figure out how to do this in xml2rfc :-(
> 
> If there's no mechanism in place, I propose creating one...
> 
> I'm thinking either...
> 
>  o the document reference database include a friendly name in its xml
>    definition.
>  o add a 'nickname' mechanism in the <!ENTITY ...> that includes the 
>    reference from the common database.
> 
> I'm very much against pulling all of the references into the document just
> to add a cute name to it. That defeats the purpose of the common database
> of references.
> 
> Aaron
> 
> _______________________________________________
> xml2rfc mailing list
> [email-masked]
> http://lists.xml.resource.org/mailman/listinfo/xml2rfc
>From dave at cridland.net  Wed Dec  5 19:53:05 2007
From: dave at cridland.net (Dave Cridland)
Date: Wed Dec  5 11:53:29 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed Dec  5 19:29:59 2007, Aaron Stone wrote:
> In the Sieve mail filter series of documents, we use the [DOCNAME]
> citation style rather extensively, and avoid [RFCxxx] references  
> wherever
> possible. This dramatically increases readability. For example (from
> draft-ietf-sieve-notify-xmpp-07.txt):
> 
> 
We do in Lemonade, too.

Take a look at my hacky XSLT preprocessing tools, held in  
http://svn.dave.cridland.net/svn/ietf-drafts/

1) Makefile - simple makefile driver, works with xsltproc.
2) rfc2629-refchk.xsl - generates an XML based report of missing, or  
bad references. In particular, this will check to see if a reference  
is marked normative in usage, and if so, whether it's listed in the  
right section.
3) rfc2629-noinc.xsl - expands all references and <?rfc include ?>  
directives.

An example might be draft-cridland-sasl-tls-sessions.xml, which is  
pretty small.

a) <xref/> elements can be marked with dwdrfc-type='norm' to make the  
refchk XSL think they're normative.
b) So can the <references/> element, to mark the normative section.
c) <references/> can conntain <dwdrfc-ref/> elements, which have a  
src attribute pointing to the fragments, and an anchor attribute to  
specify what goes in the square brackets.

(It's not using namespaces because that appeared to confuse xml2rfc,  
so I did it the hackier way).

I find these useful, YMMV.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From aaron at serendipity.cx  Wed Dec  5 15:19:48 2007
From: aaron at serendipity.cx (Aaron Stone)
Date: Wed Dec  5 15:20:49 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]>
Message-ID: <1196896788.6893.13.camel@localhost>

This input...

    The DSN message MUST follow the requirements of
    <xref target="RFC3464">DSN</xref>

...produces this output:

   The DSN message MUST follow the requirements of DSN [RFC3464]

... but what I'd like to get is:

   The DSN message MUST follow the requirements of [DSN]

Aaron

On Wed, 2007-12-05 at 14:47 -0500, Tony Hansen wrote:
> <xref target="RFCXXXX">NOTIFY</xref>
> 
> Aaron Stone wrote:
> > Hi,
> > 
> > In the Sieve mail filter series of documents, we use the [DOCNAME]
> > citation style rather extensively, and avoid [RFCxxx] references wherever
> > possible. This dramatically increases readability. For example (from
> > draft-ietf-sieve-notify-xmpp-07.txt):
> > 
> > 1.1. Overview
> > 
> >    The [NOTIFY] extension to the [SIEVE] mail filtering language is a
> >    framework for providing notifications by employing URIs to specify
> >    the notification mechanism.  This document defines how xmpp URIs (see
> >    [XMPP-URI]) are used to generate notifications via the Extensible
> >    Messaging and Presence Protocol [XMPP], which is widely implemented
> >    in Jabber instant messaging technologies.
> > 
> > I cannot figure out how to do this in xml2rfc :-(
> > 
> > If there's no mechanism in place, I propose creating one...
> > 
> > I'm thinking either...
> > 
> >  o the document reference database include a friendly name in its xml
> >    definition.
> >  o add a 'nickname' mechanism in the <!ENTITY ...> that includes the 
> >    reference from the common database.
> > 
> > I'm very much against pulling all of the references into the document just
> > to add a cute name to it. That defeats the purpose of the common database
> > of references.
> > 
> > Aaron
> > 
> > _______________________________________________
> > xml2rfc mailing list
> > [email-masked]
> > http://lists.xml.resource.org/mailman/listinfo/xml2rfc

From: nobody at xyzzy.claranet.de (Frank Ellermann)
Date: Wed Dec  5 16:15:30 2007
Subject: [xml2rfc] Re: Using [DOCNAME] citations instead of [RFCxxx]
References: <[email-masked]> <[email-masked]> <1196896788.6893.13.camel@localhost>
Message-ID: <[email-masked]>

Aaron Stone wrote:

> output:
>    The DSN message MUST follow the requirements of DSN [RFC3464]
> but what I'd like to get is:
>    The DSN message MUST follow the requirements of [DSN]

Untested, try to toggle <?rfc symrefs="yes" ?> to symrefs="no".

 Frank

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Dec  5 16:19:06 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <1196896788.6893.13.camel@localhost>
References: <[email-masked]>	 <[email-masked]> <1196896788.6893.13.camel@localhost>
Message-ID: <p06240809c37cf02f6f29@[130.129.36.118]>

At 3:19 PM -0800 12/5/07, Aaron Stone wrote:
>This input...
>
>     The DSN message MUST follow the requirements of
>     <xref target="RFC3464">DSN</xref>
>
>...produces this output:
>
>    The DSN message MUST follow the requirements of DSN [RFC3464]
>
>... but what I'd like to get is:
>
>    The DSN message MUST follow the requirements of [DSN]

This would be grand for many others as well.

--Paul Hoffman, Director
--VPN Consortium
>From julian.reschke at gmx.de  Thu Dec  6 02:13:58 2007
From: julian.reschke at gmx.de (Julian Reschke)
Date: Wed Dec  5 18:44:34 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <p06240809c37cf02f6f29@[130.129.36.118]>
References: <[email-masked]>
	<[email-masked]> <1196896788.6893.13.camel@localhost>
	<p06240809c37cf02f6f29@[130.129.36.118]>
Message-ID: <[email-masked]>

Paul Hoffman wrote:
> At 3:19 PM -0800 12/5/07, Aaron Stone wrote:
>> This input...
>>
>>     The DSN message MUST follow the requirements of
>>     <xref target="RFC3464">DSN</xref>
>>
>> ...produces this output:
>>
>>    The DSN message MUST follow the requirements of DSN [RFC3464]
>>
>> ... but what I'd like to get is:
>>
>>    The DSN message MUST follow the requirements of [DSN]
> 
> This would be grand for many others as well.

I'm really not sure where the problem is :-)

Just modify the anchor attribute in the reference element into whatever 
you like. So...

<xref target="DSN" />

and then later on:

<reference anchor='DSN'>
<front>
<title>An Extensible Message Format for Delivery Status 
Notifications</title>
  ....
</reference>

Am I missing something?

BR, Julian

From: paul.hoffman at vpnc.org (Paul Hoffman)
Date: Wed Dec  5 22:51:52 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1196896788.6893.13.camel@localhost> <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]>
Message-ID: <p06240812c37d4c14e122@[130.129.36.118]>

At 2:13 AM +0100 12/6/07, Julian Reschke wrote:
>I'm really not sure where the problem is :-)
>
>Just modify the anchor attribute in the reference element into 
>whatever you like. So...
>
><xref target="DSN" />
>
>and then later on:
>
><reference anchor='DSN'>
><front>
><title>An Extensible Message Format for Delivery Status Notifications</title>
>  ....
></reference>
>
>Am I missing something?

Yes. What was requested was the ability to use ENTITY references from 
xml.resource.org, using our own names.

--Paul Hoffman, Director
--VPN Consortium
>From dave at cridland.net  Thu Dec  6 09:25:32 2007
From: dave at cridland.net (Dave Cridland)
Date: Thu Dec  6 01:26:01 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <p06240812c37d4c14e122@[130.129.36.118]>
References: <[email-masked]>
 <[email-masked]> <1196896788.6893.13.camel@localhost>
 <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]>
 <p06240812c37d4c14e122@[130.129.36.118]>
Message-ID: <[email-masked]>

On Thu Dec  6 06:51:36 2007, Paul Hoffman wrote:
> At 2:13 AM +0100 12/6/07, Julian Reschke wrote:
>> I'm really not sure where the problem is :-)
>> 
>> Just modify the anchor attribute in the reference element into  
>> whatever you like. So...

>> Am I missing something?
> 
> Yes. What was requested was the ability to use ENTITY references  
> from xml.resource.org, using our own names.

... which is (mostly) what my hacky XSLT stuff is doing - it just  
includes and rewrites the references as Julian suggested.

The additional stuff, to do with tracking normative references, was  
stuff that came up on the list, and I wondered how well it worked in  
practise. It caught a few in draft-ietf-lemonade-profile-bis, which  
has a huge wodge of references, so I've kept on using it - I should  
really have it sort out the references into Normative and Informative  
itself, rather than merely checking.

I won't claim that my hacky XSLT is a good way of doing all this, but  
it has the notable advantage of doing what I want, as well as  
producing a complete, single-file XML source for use in submissions.

If there's interest, I'll tidy it up and stick a formal permissive  
license on it, otherwise, assume you're free to copy and redistribute  
it. 
Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From aaron at serendipity.cx  Thu Dec 13 21:21:03 2007
From: aaron at serendipity.cx (Aaron Stone)
Date: Thu Dec 13 21:22:16 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	 <[email-masked]> <1196896788.6893.13.camel@localhost>
	 <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]>
	 <p06240812c37d4c14e122@[130.129.36.118]>
	 <[email-masked]>
Message-ID: <1197609663.7568.6.camel@localhost>

On Thu, 2007-12-06 at 09:25 +0000, Dave Cridland wrote:
> On Thu Dec  6 06:51:36 2007, Paul Hoffman wrote:
> > At 2:13 AM +0100 12/6/07, Julian Reschke wrote:
> >> I'm really not sure where the problem is :-)
> >> 
> >> Just modify the anchor attribute in the reference element into  
> >> whatever you like. So...
> 
> 
> >> Am I missing something?
> > 
> > Yes. What was requested was the ability to use ENTITY references  
> > from xml.resource.org, using our own names.
> 
> ... which is (mostly) what my hacky XSLT stuff is doing - it just  
> includes and rewrites the references as Julian suggested.
> 
> The additional stuff, to do with tracking normative references, was  
> stuff that came up on the list, and I wondered how well it worked in  
> practise. It caught a few in draft-ietf-lemonade-profile-bis, which  
> has a huge wodge of references, so I've kept on using it - I should  
> really have it sort out the references into Normative and Informative  
> itself, rather than merely checking.
> 
> I won't claim that my hacky XSLT is a good way of doing all this, but  
> it has the notable advantage of doing what I want, as well as  
> producing a complete, single-file XML source for use in submissions.
> 
> If there's interest, I'll tidy it up and stick a formal permissive  
> license on it, otherwise, assume you're free to copy and redistribute  
> it. 
> Dave.

I've finally had time to sit down and finish converting the Sieve Reject
extension to xml2rfc, and I your XSLT totally saved the day. Thanks!

Here's another thought I've had: it'd be nice to do section references
from within the xref tag. That would at least break out the semantic
information necessary to check that such a section exists, and perhaps
in HTML versions, to use the section's title as a tool tip on the link.

Aaron

From: dave at cridland.net (Dave Cridland)
Date: Fri Dec 14 02:15:26 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <1197609663.7568.6.camel@localhost>
References: <[email-masked]> <[email-masked]> <1196896788.6893.13.camel@localhost> <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]> <p06240812c37d4c14e122@[130.129.36.118]> <[email-masked]> <1197609663.7568.6.camel@localhost>
Message-ID: <7870.1197627300.352049@invsysm1>

On Fri Dec 14 05:21:03 2007, Aaron Stone wrote:
> I've finally had time to sit down and finish converting the Sieve  
> Reject
> extension to xml2rfc, and I your XSLT totally saved the day. Thanks!
> 
> 
Glad it helped.

> Here's another thought I've had: it'd be nice to do section  
> references
> from within the xref tag. That would at least break out the semantic
> information necessary to check that such a section exists, and  
> perhaps
> in HTML versions, to use the section's title as a tool tip on the  
> link.

I'm not clear what you mean - you can stick an anchor attribute onto  
a section, and then use it as the target of an xref. Did you mean  
something different?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
>From aaron at serendipity.cx  Fri Dec 14 02:28:55 2007
From: aaron at serendipity.cx (Aaron Stone)
Date: Fri Dec 14 02:30:06 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <7870.1197627300.352049@invsysm1>
References: <[email-masked]>
	<[email-masked]> <1196896788.6893.13.camel@localhost>
	<p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]>
	<p06240812c37d4c14e122@[130.129.36.118]>
	<[email-masked]>
	<7870.1197627300.352049@invsysm1>
Message-ID: <1197628135.7568.12.camel@localhost>

On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote:
> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote:
> > Here's another thought I've had: it'd be nice to do section  
> > references
> > from within the xref tag. That would at least break out the semantic
> > information necessary to check that such a section exists, and  
> > perhaps
> > in HTML versions, to use the section's title as a tool tip on the  
> > link.
> 
> I'm not clear what you mean - you can stick an anchor attribute onto  
> a section, and then use it as the target of an xref. Did you mean  
> something different?

I want to reference a specific section in another document...

Input:
  For details, see <xref target="RFC12345" section="2.4.5"/>

Output (text):
  For details, see [RFC12345] Section 2.4.5.

Output (html)
  For details, see <a href="rfc12345.html#2.4.5" title="The chapter
    name from the other document">[RFC12345] Section 2.4.5</a>

Aaron

From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri Dec 14 02:38:31 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <1197628135.7568.12.camel@localhost>
References: <[email-masked]> <[email-masked]> <1196896788.6893.13.camel@localhost> <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]> <p06240812c37d4c14e122@[130.129.36.118]> <[email-masked]> <7870.1197627300.352049@invsysm1> <1197628135.7568.12.camel@localhost>
Message-ID: <[email-masked]>

Aaron Stone wrote:
> On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote:
>> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote:
>>> Here's another thought I've had: it'd be nice to do section  
>>> references
>>> from within the xref tag. That would at least break out the semantic
>>> information necessary to check that such a section exists, and  
>>> perhaps
>>> in HTML versions, to use the section's title as a tool tip on the  
>>> link.
>> I'm not clear what you mean - you can stick an anchor attribute onto  
>> a section, and then use it as the target of an xref. Did you mean  
>> something different?
> 
> I want to reference a specific section in another document...
> 
> Input:
>   For details, see <xref target="RFC12345" section="2.4.5"/>
> 
> Output (text):
>   For details, see [RFC12345] Section 2.4.5.
> 
> Output (html)
>   For details, see <a href="rfc12345.html#2.4.5" title="The chapter
>     name from the other document">[RFC12345] Section 2.4.5</a>
> 
> Aaron

<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>

BR, Julian
>From aaron at serendipity.cx  Fri Dec 14 04:03:37 2007
From: aaron at serendipity.cx (Aaron Stone)
Date: Fri Dec 14 04:18:58 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]> <1196896788.6893.13.camel@localhost>
	<p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]>
	<p06240812c37d4c14e122@[130.129.36.118]>
	<[email-masked]>
	<1197628135.7568.12.camel@localhost>	 <[email-masked]>
Message-ID: <1197633817.7568.30.camel@localhost>

On Fri, 2007-12-14 at 11:38 +0100, Julian Reschke wrote:
> Aaron Stone wrote:
> > On Fri, 2007-12-14 at 10:15 +0000, Dave Cridland wrote:
> >> On Fri Dec 14 05:21:03 2007, Aaron Stone wrote:
> >>> Here's another thought I've had: it'd be nice to do section  
> >>> references
> >>> from within the xref tag. That would at least break out the semantic
> >>> information necessary to check that such a section exists, and  
> >>> perhaps
> >>> in HTML versions, to use the section's title as a tool tip on the  
> >>> link.
> >> I'm not clear what you mean - you can stick an anchor attribute onto  
> >> a section, and then use it as the target of an xref. Did you mean  
> >> something different?
> > 
> > I want to reference a specific section in another document...
> > 
> > Input:
> >   For details, see <xref target="RFC12345" section="2.4.5"/>
> > 
> > Output (text):
> >   For details, see [RFC12345] Section 2.4.5.
> > 
> > Output (html)
> >   For details, see <a href="rfc12345.html#2.4.5" title="The chapter
> >     name from the other document">[RFC12345] Section 2.4.5</a>
> > 
> > Aaron
> 
> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>
> 
> BR, Julian

Nice! Thanks! Though I haven't tested if this work with Dave's XSLT to
get [DOCNAME], Section 1.2.3...

Aaron

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Fri Dec 14 06:39:35 2007
Subject: [xml2rfc] Using [DOCNAME] citations instead of [RFCxxx]
References: <[email-masked]> <[email-masked]> <1196896788.6893.13.camel@localhost> <p06240809c37cf02f6f29@[130.129.36.118]> <[email-masked]> <p06240812c37d4c14e122@[130.129.36.118]> <[email-masked]> <1197628135.7568.12.camel@localhost> <[email-masked]> <1197633817.7568.30.camel@localhost>
Message-ID: <[email-masked]>

I know it's an artifact of some people being on the to: list directly while 
I'm on the mailing list and processing is different, but I saw Julian's 
reply BEFORE I saw Aaron's explanation of what he was asking for, and it's 
just not that hard to imagine the people who do so much work in support of 
the community answering questions before they've actually been asked...

... which may be an ubergeeky way to say "thank you", but ... "thank you" 
guys for all that you do (he said as he kicked out another ID that passed 
all the nit-checking)

Spencer

>> >>> Here's another thought I've had: it'd be nice to do section
>> >>> references
>> >>> from within the xref tag. That would at least break out the semantic
>> >>> information necessary to check that such a section exists, and
>> >>> perhaps
>> >>> in HTML versions, to use the section's title as a tool tip on the
>> >>> link.
>> >> I'm not clear what you mean - you can stick an anchor attribute onto
>> >> a section, and then use it as the target of an xref. Did you mean
>> >> something different?
>> >
>> > I want to reference a specific section in another document...
>> >
>> > Input:
>> >   For details, see <xref target="RFC12345" section="2.4.5"/>
>> >
>> > Output (text):
>> >   For details, see [RFC12345] Section 2.4.5.
>> >
>> > Output (html)
>> >   For details, see <a href="rfc12345.html#2.4.5" title="The chapter
>> >     name from the other document">[RFC12345] Section 2.4.5</a>
>> >
>> > Aaron
>>
>> <http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#ext-rfc2629.xref>
>>
>> BR, Julian
>
> Nice! Thanks! Though I haven't tested if this work with Dave's XSLT to
> get [DOCNAME], Section 1.2.3...
>
> Aaron 

From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Sat Dec 15 14:17:28 2007
Subject: [xml2rfc] formatting inside texttable cells?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Lars Eggert wrote:
 >
 > I'm trying to use vspace to structure the contents of a texttable call,
 > but apparently that isn't possible? Is there another way to do what I want?

I am using <vspace blankLines="n"/> inside of <c> elements and it is nominally 
working for my purposes, in .html output -- I haven't looked at the .txt output 
as yet (this is for a whitepaper I'm writing, not an I-D). I think I'm only 
using an n of "1" at this time in all cases tho. In any case, it does work to 
break the text in a <c> element into "paragraphs" and to provide space above 
and below the text.

=JeffH

From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Sat Dec 15 14:19:49 2007
Subject: [xml2rfc] Tables/Lists of Figures and Tables?
Message-ID: <[email-masked]>

Is there an automagic way to generate Tables/Lists of Figures and Tables?

I realize I can gen them manually with <xref>.

thanks,

=JeffH
>From Jeff.Hodges at neustar.biz  Fri Dec 21 13:31:50 2007
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Fri Dec 21 13:32:07 2007
Subject: [xml2rfc] pushing tables hard in xml2rfc
Message-ID: <[email-masked]>

just fyi/fwiw, I pushed <texttable>'s kinda hard in this paper..

   http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html

..and am not unhappy with the results in .html output (I haven't looked at the 
.txt output for a while for this paper).

Anyway, there's figures inside of texttables, and it works. Pretty cool.

=JeffH
>From Jeff.Hodges at neustar.biz  Fri Dec 21 13:36:11 2007
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Fri Dec 21 13:36:19 2007
Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

oh, yeah, and I made extensive use of <vspace> both within and without the tables.

=JeffH
>From Jeff.Hodges at neustar.biz  Fri Dec 21 15:32:49 2007
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Fri Dec 21 15:32:57 2007
Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

I got asked about what my xml source looks like. Here's relevant to the 
terminlogy section and figures-in-tables (use fixed pitch font)..

         <vspace blankLines="2"/>
         <section anchor="sctn-term" title="Terminology">

             <t>
                 <list style="hanging" hangIndent="20">

                     <t hangText="deployer">
                         <vspace blankLines="1"/>

                         In this document, the
                         term <spanx style="emph">deployer</spanx>
                         refers to one who installs (and configures)
                         one or more <spanx
                         style="emph">implementations</spanx>, of one
                         or more of the protocols or profiles discussed
                         herein, onto systems for use by some group of
                         <spanx style="emph">users</spanx>. Also, the
                         deployer role is considered distinct from the
                         <spanx style="emph">implementor</spanx> role.
                     </t>
                 <vspace blankLines="2"/>

             <t hangText="deployment">
                 <vspace blankLines="1"/>

                 A <spanx style="emph">deployment</spanx> is the
                 operating installation of <spanx
                 style="emph">implementations</spanx>, of one or more
                 of the protocols or profiles discussed
                 herein. Deployments are created by <spanx
                 style="emph">deployers</spanx>.
             </t>
             <vspace blankLines="2"/>

             <t hangText="key-value">
                 <vspace blankLines="1"/>
                 A shorthand <spanx style="emph">OpenID</spanx>
                 term describing a
                 &quot;<spanx style="emph">key</spanx> and
                 <spanx style="emph">value</spanx>&quot;
                 pair, or, more generally, the overall
                 notion of conveying information as sets of key-value
                 pairs. This term is used in both senses in <xref
                 target="OpenID.openid-authentication-2_0"/>.

                 <vspace blankLines="1"/>

                 Note: often, this &quot;key-value&quot; notion
                 is also
                 referred to as &quot;name-value&quot; or
                 &quot;name-value pairs&quot;.  Also, in the LDAP/X.500
                 world(s), similar constructs are referred to as
                 &quot;attribute value assertions&quot; (AVAs).
             </t>
             <vspace blankLines="2"/>

                 <vspace blankLines="2"/>
                 <section  title="Web Browser SSO with Association">
                 <t>
                     <xref target="tbl-openid-saml-sso-cmp-w-assoc"/>: <xref
                     target="tbl-openid-saml-sso-cmp-w-assoc" format="title"/>,
                     below,
                     illustrates web browser SSO where no
                     &quot;callbacks&quot; from the RP to the OP/IDP
                     are employed.

                     As can be seen from <xref
                     target="fig-openid-authn-assoc"/> and <xref
                     target="fig-saml-sso-no-artifact"/> therein, the flows for
                     both OpenID authentication and SAML web browser
                     SSO Profile are the same for this variation where
                     the RP has already been introduced to the
                     OP/IDP.

                     In the OpenID case, this means that RP
                     discovered (if necessary) and formed an
                     association with the OP/IDP prior to beginning the
                     flow in <xref target="fig-openid-authn-assoc"/>.
                     In SAML it means that the RP discovered the
                     IDP before the flow (via some unspecified means, though
                     possibly using the
                     OpenID initiation and discovery mechanism
                     <xref target="draft-hodges-saml-openid-profile-02"/>),

                     or had been configured with the information (this
                     is a subtle-but-key point in that SAML per se
                     is not wedded to particular initiation and
                     discovery mechanisms as discussed in <xref
                     target="sctn-idents-compare"/>: <xref
                     target="sctn-idents-compare" format="title"/>, above, and
                     <xref target="sctn-disco"/>: <xref
                     target="sctn-disco" format="title"/>, below).
                 </t>

                 <texttable anchor="tbl-openid-saml-sso-cmp-w-assoc" style="all"
                     title="Web Browser SSO with Association"
                     >

                 <ttcol width="50%" align="left">
                     OpenID
                 </ttcol>

                 <ttcol width="50%" align="left">
                     SAML
                 </ttcol>

            <!--    OpenID  -->
                 <c>
         <vspace blankLines="1"/>

                 <figure title="OpenID Authentication with an Established
                         Association"
                     anchor="fig-openid-authn-assoc">
                     <artwork>
                         <![CDATA[
  +----+                  +----+               +--------+
  | UA |                  | RP |               | OP/IDP |
  +-+--+                  +-+--+               +---+----+
    |                       |                      |
    | 1. Authentication Req |                      |
    | and assoc_handle!=null|                      |
  +<- - - - - - - - - - - - |                      |
  . | (HTTP redirect resp)  |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |  (HTTP GET or POST)   |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2. OP/IDP authenticates user                 |
    | (methods vary, realization is out of scope)  |
    |<============================================>|
    |(Step 2 transparent to user if openid.mode is |
    | checkid_immediate)    |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 3. Authentication Resp|                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . | (HTTP redirect resp)  |                      |
  . |                       |                      |
  +------------------------>|                      |
    |  (HTTP GET or POST)   |                      |
    |                       |                      |
    |                       |                      |
    | 4. User is signed-on  |                      |
    | or some form of       |                      |
    | error msg is displayed|                      |
    |<----------------------|                      |
    |                       |                      |
                        ]]>
                     </artwork>
                 </figure>
         <vspace blankLines="1"/>
                 </c>

                     <!--    SAML  -->
                     <c>
                         <vspace blankLines="1"/>

                     <figure title="SAML HTTP Redirect- or HTTP POST-based Web
                         Broswer SSO Profile"
                     anchor="fig-saml-sso-no-artifact">
                         <artwork>
                             <![CDATA[
  +----+                  +----+                +-----+
  | UA |                  | RP |                | IDP |
  +-+--+                  +-+--+                +--+--+
    |                       |                      |
    | 1. <AuthnRequest> msg |                      |
  +<- - - - - - - - - - - - |                      |
  . |   (redirect to IDP)   |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |  (HTTP GET OR POST)   |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2. Identity Provider authenticates user      |
    | (methods vary, realization is out of scope)  |
    |<============================================>|
    |(this step transparent to user if IsPassive=T)|
    |                       |                      |
    |                       |                      |
    | 3. <Response> message |                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . |   (redirect to SP)    |                      |
  . |                       |                      |
  +------------------------>|                      |
    |  (HTTP GET OR POST)   |                      |
    |                       |                      |
    |                       |                      |
    | 4. user is signed-on  |                      |
    | or some form of       |                      |
    | error msg is returned |                      |
    |<----------------------|                      |
    |                       |                      |
                             ]]>
                         </artwork>
                     </figure>

                     <vspace blankLines="1"/>
                 </c>
                 </texttable>
                     <vspace blankLines="2"/>

                 </section>

             <!--  =========== M E S S A G E   F O R M A T S =============  -->
             <vspace blankLines="2"/>
             <section anchor="sctn-msg-formats"
                 title="Message Formats and Protocol Bindings">

             <t>
                 <texttable anchor="tbl-msg-formats" style="all"
                     title="Message Formats and Protocol Bindings"
                     >

                 <ttcol width="10%" align="left">
                     Topic
                 </ttcol>

                 <ttcol width="40%" align="left">
                     OpenID
                 </ttcol>

                 <ttcol width="40%" align="left">
                     SAML
                 </ttcol>

                     <!--  topic  -->

                     <c>
                         Overall message formats:
                     </c>

                 <!--  OpenID  -->
                 <c>
                     <vspace blankLines="1"/>

                     OpenID Authentication
                     protocol messages are
                         comprised of
                     sets of
                     <spanx style="emph">key-value</spanx>
                         pairs, e.g this figure from
                         <xref target="OpenID.openid-authentication-2_0"/>
                         section 4...

                 <figure>
                     <artwork>
                         <![CDATA[
Key     | Value
--------+---------------------------
mode    | error
error   | This is an example message
                         ]]>
                     </artwork>
                 </figure>

                 ...which are encoded into HTTP messages, in varying
                 fashions dependent upon
                 whether the underlying HTTP message is an HTTP request or
                 response, and also whether (if it is a request)
                 the HTTP method being employed
                 is GET or POST. These variations are delineated in
                 <xref target="OpenID.openid-authentication-2_0"/>
                 by the notions of
                 &quot;Data Formats&quot; (section 4) and
                 &quot;Communication Types&quot; (section 5).

                 <vspace blankLines="1"/>
                 </c>

                 <!--  SAML  -->
                 <c>
                     <vspace blankLines="1"/>

                     Abstract SAML Messages are defined in
                     <xref target="OASIS.saml-core-2.0-os"/>, are
                     expressed in XML
                     <xref target="W3C.REC-xml"/>, and are structured
                     according to message definitions expressed in
                     XML Schema <xref target="W3C.REC-xmlschema-1"/>.
                     This is regardless of the particular underlying
                     protocol messages they are ultimately bound to.

                     <vspace blankLines="1"/>

                     SAML assertions and protocol messages are
                     comprised of many various &quot;parameters&quot;
                     &mdash; essentially corresponding to the OpenID
                     notion of <spanx style="emph">keys</spanx> &mdash;
                     and are configurable (i.e. various parameters are
                     optional), thus explicitly extensible.

                     <vspace blankLines="1"/>
                 </c>

---
end

From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat Dec 22 02:48:19 2007
Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

...I'll have to say you're pushing them too hard, at least if you're 
concerned about the ability to produce TXT from it, or to run it trhough 
a different implementation :-).
>From Jeff.Hodges at neustar.biz  Wed Dec 26 22:12:51 2007
From: Jeff.Hodges at neustar.biz (=JeffH)
Date: Wed Dec 26 22:13:04 2007
Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Julian Reschke wrote:
> ...I'll have to say you're pushing them too hard,

no such thing given the code didn't core-dump and produces reasonable, useful 
output.

> at least if you're 
> concerned about the ability to produce TXT from it,

not for this paper.

> or to run it trhough 
> a different implementation :-).

i'm not aware of any other xml2rfc impl, are you?

=JeffH

From: julian.reschke at gmx.de (Julian Reschke)
Date: Thu Dec 27 01:11:56 2007
Subject: [xml2rfc] Re: [Tools-discuss] pushing tables hard in xml2rfc
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

=JeffH wrote:
> i'm not aware of any other xml2rfc impl, are you?

There's one from Bill Fenner, and there's also 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html>.

BR, Julian