Subject: [xml2rfc] #164: No warning fro missing docName in the <rfc/> element

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 17 Apr 2013 22:56:19 -0000

#164: No warning fro missing docName in the <rfc/> element

 If the <rfc/> element for a draft contains no docName attribute, no draft-
 name is placed in the output, and no warning is given.

 If the <rfc/> element is for an RFC (i.e., has a numbers="NNNN"
 attribute), this is OK, but for drafts, it should cause a warning.

-- 
----------------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:  [email-masked]
     Type:  defect                |     Status:  new
 Priority:  medium                |  Milestone:
Component:  Version 2 cli         |    Version:  2.4.x
 Keywords:                        |
----------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/164>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Wed, 17 Apr 2013 22:56:41 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Fixed in [857]

-- 
-----------------------------------+----------------------------------
  Reporter:  [email-masked]  |      Owner:  [email-masked]
      Type:  defect                |     Status:  closed
  Priority:  medium                |  Milestone:
 Component:  Version 2 cli         |    Version:  2.4.x
Resolution:  fixed                 |   Keywords:
-----------------------------------+----------------------------------

Ticket URL: <http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/164#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Apr 2013 09:41:56 -0400

>   attribute), this is OK, but for drafts, it should cause a warning.

It would be really nice if the docname could be managed in a way that 
didn't require it to be updated for each new version - that it figured 
out what version number to use. Perhaps if there is no version number in 
the name it could the last submitted version number plus one.

	Thanks,
	Paul

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Apr 2013 15:48:20 +0200

> the name it could the last submitted version number plus one.

...which would make the output of the formatting process depend on what 
was submitted; that sounds like a bad idea for sources of archived versions.

Best regards, Julian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Apr 2013 10:18:29 -0400

> was submitted; that sounds like a bad idea for sources of archived

It already has that property for <date/> doesn't it? Also for references.

Perhaps there could be a special xml2rfc option that generates a new 
version of the xml with all the contextual defaults replaced by their 
current values. That could be applied as part of the submission process 
when an xml is submitted.

	Thanks,
	Paul

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Apr 2013 16:49:05 +0200

> It already has that property for <date/> doesn't it? Also for references.

For incomplete dates, you'll at least get a warning once the specified 
parts do not match the system date.

For references -- I recommend not to use includes.

> ...

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Apr 2013 10:17:51 -0500

> was submitted; that sounds like a bad idea for sources of archived versions.

We use to have RCS and such VCSes embed version numbers and other things in
our files.  That was a bad idea, and it took decades to see as much, it
took a changeset concept to get there.  Why does the same not apply
-roughly- here?  I think it does, and I know that Paul is not alone i.
being annoyed by this missing feature.  The I-D submission page already
requires one to verify various things; making it verify that hey, this will
be -07 of your I-D is not much extra work (and no, a lock need not be held
across the interaction).

Nico
--

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Apr 2013 14:04:24 -0400

> parts do not match the system date.

But if you just use <date/> then there won't be an mismatched parts.
And that seems the most convenient form to use.

> For references -- I recommend not to use includes.

That feature was one of the features that most convinced me to move to 
xml2rfc in the first place. It is an incredible pain to maintain correct 
versions in references as drafts evolve.

	Thanks,
	Paul

---

From: Julian Reschke <[email-masked]>
Date: Thu, 18 Apr 2013 20:15:31 +0200

> And that seems the most convenient form to use.

That is true.

> versions in references as drafts evolve.

For me it's not a big pain; I copy the references and use 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references> 
to check whether everything is still up to date (and that' checks RFCs 
and W3C specs as well).

Best regards, Julian