Chris Bowers | 27 Aug 01:10 2015
Picon

direct link to non-javascript version of mail archives

Would it be possible to add a link from the javascript version of the mail archives directly to the non-JS version of the archives?
So:
would have a link directly to:
 
It is likely that most IETF old-timers know how to access the non-JS version of the archives, but new participants might not know there are two views.
 
I currently am experiencing an issue with Firefox 40.0.2 on Windows 7 where the window will not scroll past the first 21 messages displayed in the Javascript version.  I had to spend 15 minutes figuring out how to find the old non-JS view in order to be able to see the archive.  A direct link would be helpful.
 
Thanks,
Chris
 
 
 
--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org
Tony Hansen | 26 Aug 18:27 2015
Picon

Re: spam subscriptions using + subaddresses

Suresh Krishnan found a solution for this. I just put the regular expressions into my Privacy section -- hope it works.

    Tony Hansen

On August 25, Suresh Krishnan wrote:
Hi all, One of the lists I moderate was inundated with a flood of subscribe messages from emails of the pattern nkymtky+NNNNNNNN at gmail.com kemo.mart+NNNNNNNN at gmail.com melthehybrid+NNNNNNNN at gmail.com Two other moderators and I cleared up about 60 of these requests by discarding manually but they kept coming. Looking for a better solution to the problem, we found a ban_list in the Privacy options for the mailman lists. This ban_list allows a regex for people who will automatically be banned from joining. I added the following emails to the ban_list and the flood stopped. ^kemo\.mart.* <at> gmail.com ^nkymtky.* <at> gmail.com ^melthehybrid.* <at> gmail.com I heard there are other lists that are having the same problems. Hope this can help. Thanks Suresh


On 8/24/15 11:30 AM, Scott O. Bradner wrote:
I am also seeing these on two of the lists I manage it would be great be able to ban an address prefix (e.g. melthehybrid) but seeing that the mailing list management is Mailman it may not be easy to fix this Scott
On Aug 24, 2015, at 11:23 AM, Tony Hansen <tony <at> att.com> wrote: This morning, there were close to 20 spam subscriptions to one of the mailing lists of which I'm an adminstrator. A reminder message was sent later on, which is appended to the end of this message. As you can see, they all are of the form melthehybride+subaddress <at> gmail.com, nkymtky+subaddress <at> gmail.com and kemo.mart+subaddress <at> gmail.com. Using the admin interface, I can individually discard each address and ban that address from subscribing in the future. I would like to see an option to not only do that, but also to ban that address >>and all subaddresses<< for that user from subscribing in the future. Any hopes of seeing such an option? Tony Hansen The ... mailing list has 18 request(s) waiting for your consideration at: https://www.ietf.org/mailman/admindb/... Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending subscriptions: melthehybrid+19819395 <at> gmail.com Mon Aug 24 02:54:13 2015 melthehybrid+33161026 <at> gmail.com Mon Aug 24 03:05:10 2015 nkymtky+82613960 <at> gmail.com Mon Aug 24 03:11:11 2015 melthehybrid+21919817 <at> gmail.com Mon Aug 24 03:35:45 2015 kemo.mart+34746317 <at> gmail.com Mon Aug 24 03:37:07 2015 kemo.mart+98378946 <at> gmail.com Mon Aug 24 03:41:26 2015 melthehybrid+25921869 <at> gmail.com Mon Aug 24 03:42:33 2015 nkymtky+80059775 <at> gmail.com Mon Aug 24 04:12:14 2015 melthehybrid+37518046 <at> gmail.com Mon Aug 24 04:17:58 2015 nkymtky+44285674 <at> gmail.com Mon Aug 24 04:20:00 2015 kemo.mart+64715691 <at> gmail.com Mon Aug 24 04:24:38 2015 kemo.mart+96537012 <at> gmail.com Mon Aug 24 04:32:40 2015 kemo.mart+87865270 <at> gmail.com Mon Aug 24 04:55:01 2015 melthehybrid+63307273 <at> gmail.com Mon Aug 24 05:39:08 2015 melthehybrid+93276538 <at> gmail.com Mon Aug 24 05:45:13 2015 nkymtky+43297761 <at> gmail.com Mon Aug 24 06:34:37 2015 nkymtky+91110227 <at> gmail.com Mon Aug 24 07:05:28 2015 kemo.mart+81607935 <at> gmail.com Mon Aug 24 07:40:28 2015 -- Tools-discuss mailing list Tools-discuss <at> ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or send email to webmaster <at> tools.ietf.org

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org
Hadriel Kaplan | 21 Aug 14:24 2015
Picon

IETF xml2rfc online tool transform as a GET query

Howdy,
You have a very useful online tool to convert XML to RFC format online
at xml2rfc.ietf.org, which makes it easy to view the XML source in the
various formats without installing the xml2rfc tool and all. Thank you
for providing the online means of doing that!

What I'd like to ask is if it would be possible to provide a way to
use that tool through an HTTP GET URI request, instead of the current
forms-based input mode which requires a POST with multipart form data.
In other words, instead of having to go on the site and clicking
through the buttons and pasting a URL for the source and clicking
"Submit", instead could we use a specially-formatted URL/URI link to
do the same thing.

For example, a URI like this:

http://xml2rfc.ietf.org/transform?url=https%3A%2F%2Fraw.githubusercontent.com%2Fpcapng%2Fpcapng%2Fmaster%2Fdraft-tuexen-opsawg-pcapng.xml&mode=html&format=ascii&type=ascii

That's virtually identical to the form data in the current web page,
except it would use a GET request and does not include the "Submit"
action.

This would only work for converting XML from URLs, not by uploading a
file, obviously.

The reason for this request is so that we can put that as an HTTP URL
link in emails, docs, etc. Web browsers can dereference that URL link
and immediately show the results, without having to clik on the
submission form. For my particular use-case, it would allow me to keep
an IETF draft on github and put the URL link in a README markdown page
there, which github will render, and then users can click the link and
be sent to the transformed page on xml2rfc.ietf.org.

-hadriel

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Chris Bowers | 19 Aug 20:40 2015
Picon

using the xml2rfc tool with a URL as a parameter

I was wondering if there is a way to use the xml2rfc tool in a way that I can pass the location of the XML source as a parameter in the URL, kind of like rfcdiff does. 
except that I want the parameter to be a fully qualified URL so it can point to a file on github for example.
 
I am using github for ietf drafts, and would like to be able to generate the most recent text with a single URL.  Or have a Travis job that does it.  The instructions I currently give are shown below, but these are kind of ugly with cutting and pasting the URL.  Is there a better way to do this?
 
Thanks,
Chris
 
You can generate the text version of the most recent XML commit by pasting the raw github content URL into the xml2rfc tool at:
 
 
--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org
Hadriel Kaplan | 24 Aug 21:02 2015
Picon

xml2rfc online tool transform as a GET query

Howdy,

You have a very useful online tool to convert XML to RFC format online
at xml2rfc.ietf.org, which makes it easy to view the XML source in the
various formats without installing the xml2rfc tool and all. Thank you
for providing the online means of doing that!

What I'd like to ask is if it would be possible to provide a way to
use that tool through an HTTP GET URI request, instead of the current
forms-based input mode which requires a POST with multipart form data.
In other words, instead of having to go on the site and clicking
through the buttons and pasting a URL for the source and clicking
"Submit", instead could we use a specially-formatted URL/URI link to
do the same thing.

For example, a URL like this:

http://xml2rfc.ietf.org/transform?url=https%3A%2F%2Fraw.githubusercontent.com%2Fpcapng%2Fpcapng%2Fmaster%2Fdraft-tuexen-opsawg-pcapng.xml&mode=html&format=ascii&type=ascii

That's virtually identical to the form data in the current web page,
except it would use a GET request and does not include the "Submit"
action.

This would only work for converting XML from URLs, not by uploading a
file, obviously.

The reason for this request is so that we can put that as an HTTP URL
link in emails, docs, etc. Web browsers can dereference that URL link
and immediately show the results, without having to clik on the
submission form. For my particular use-case, it would allow me to keep
an IETF draft on github and put the URL link in a README markdown page
there, which github will render, and then users can click the link and
be sent to the transformed page on xml2rfc.ietf.org.

-hadriel

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Tony Hansen | 24 Aug 17:23 2015
Picon

spam subscriptions using + subaddresses

This morning, there were close to 20 spam subscriptions to one of the
mailing lists of which I'm an adminstrator. A reminder message was sent
later on, which is appended to the end of this message.

As you can see, they all are of the form
melthehybride+subaddress <at> gmail.com, nkymtky+subaddress <at> gmail.com and
kemo.mart+subaddress <at> gmail.com.

Using the admin interface, I can individually discard each address and
ban that address from subscribing in the future.

I would like to see an option to not only do that, but also to ban that
address >>and all subaddresses<< for that user from subscribing in the
future.

Any hopes of seeing such an option?

    Tony Hansen

The ... mailing list has 18 request(s) waiting for
your consideration at:

	https://www.ietf.org/mailman/admindb/...
	
Please attend to this at your earliest convenience.  This notice of
pending requests, if any, will be sent out daily.

Pending subscriptions:
    melthehybrid+19819395 <at> gmail.com Mon Aug 24 02:54:13 2015
    melthehybrid+33161026 <at> gmail.com Mon Aug 24 03:05:10 2015
    nkymtky+82613960 <at> gmail.com Mon Aug 24 03:11:11 2015
    melthehybrid+21919817 <at> gmail.com Mon Aug 24 03:35:45 2015
    kemo.mart+34746317 <at> gmail.com Mon Aug 24 03:37:07 2015
    kemo.mart+98378946 <at> gmail.com Mon Aug 24 03:41:26 2015
    melthehybrid+25921869 <at> gmail.com Mon Aug 24 03:42:33 2015
    nkymtky+80059775 <at> gmail.com Mon Aug 24 04:12:14 2015
    melthehybrid+37518046 <at> gmail.com Mon Aug 24 04:17:58 2015
    nkymtky+44285674 <at> gmail.com Mon Aug 24 04:20:00 2015
    kemo.mart+64715691 <at> gmail.com Mon Aug 24 04:24:38 2015
    kemo.mart+96537012 <at> gmail.com Mon Aug 24 04:32:40 2015
    kemo.mart+87865270 <at> gmail.com Mon Aug 24 04:55:01 2015
    melthehybrid+63307273 <at> gmail.com Mon Aug 24 05:39:08 2015
    melthehybrid+93276538 <at> gmail.com Mon Aug 24 05:45:13 2015
    nkymtky+43297761 <at> gmail.com Mon Aug 24 06:34:37 2015
    nkymtky+91110227 <at> gmail.com Mon Aug 24 07:05:28 2015
    kemo.mart+81607935 <at> gmail.com Mon Aug 24 07:40:28 2015

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Robert Sparks | 11 Aug 16:41 2015

Help test IMAP access to the IETF archives.

Folks -

We are in the last stages of testing IMAP access to the IETF archives.

To get a simple measure of load, we'd like to have a hundred or so
geographically-distributed, simultaneous users accessing our test instance
this Thursday with various clients.

The test instance is getting mail with a slight delay after it comes 
into the lists - you should
see current traffic.

Please resist the temptation to download the entire archive of every list.
I've done it - it's huge (~28G when MailMate does it) and it it's a severe
torture test for clients. Interrupt your client if it starts trying to 
do that for you.
Caching a copy of this test instance will not be useful to you when we 
deploy.

Instead, what would help us the most is to configure your client to 
access those lists you normally
subscribe to, and to spend some time Thursday browsing/searching those 
lists, and exploring a
few lists that are new to you.

If you're willing to take the time to do this, please drop me a note 
directly (I've set reply-to on this message)
so I have a feel for whether I need to ask a bigger set of people. Feel 
free to pass this note along to other
folks you think would be good constructive testers.

You can find the details for where the test instance is listening, and 
some rudimentary instructions for
setting up a few clients, at 
<http://trac.tools.ietf.org/group/tools/trac/wiki/ImapTesting>. Please
improve that page as you see the opportunity. It's ok to start setting 
up the clients now, but remember
that Thursday is when we really want people to exercise the instance.

Also, please report any issues directly to me. Don't open tickets with 
the secretariat right now.
We can also use tools-discuss <at> ietf.org for general conversation.

(I've crossposted this to the chairs list. Again, reply directly to me, 
and steer general conversation towards tools-discuss).

Thanks in advance for any time you can give this.

RjS

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Daniel Kahn Gillmor | 10 Aug 21:08 2015
Picon

[Barry Leiba] Re: [Editorial Errata Reported] RFC3207 (4442)

hi IETF tools-ers--

I submitted the attached (rejected) erratum about RFC 3207, which has an
appendix that describes its changes from RFC 2487.  Since the RFC editor
believes that there is no problem with the text of the RFC, the only
problem is in the HTML-ization at
https://tools.ietf.org/html/rfc3207#page-8

Looks like the HTML links in that appendix should be adjusted to point
to the older document's sections instead of the sections of the current
document.

If this should be reported somewhere else, please let me know, i'm happy
to forward it.

Regards,

        --dkg

Picon
From: Barry Leiba <barryleiba <at> computer.org>
Subject: Re: [Editorial Errata Reported] RFC3207 (4442)
Date: 2015-08-10 18:20:59 GMT
Daniel, the tools-based HTML rendering is not the definitive version,
and the errata system is not for recording problems with that version.
There's no error in http://www.rfc-editor.org/rfc/rfc3207.txt

I'm going to mark this report "Rejected".

Barry

On Mon, Aug 10, 2015 at 10:19 AM, RFC Errata System
<rfc-editor <at> rfc-editor.org> wrote:
> The following errata report has been submitted for RFC3207,
> "SMTP Service Extension for Secure SMTP over Transport Layer Security".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3207&eid=4442
>
> --------------------------------------
> Type: Editorial
> Reported by: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
>
> Section: Appendix
>
> Original Text
> -------------
>    -  Section 5 and 7: More discussion of the man-in-the-middle attacks
>    -  Section 5: Additional discussion of when a server should and
>       should not advertise the STARTTLS extension
>    -  Section 5: Changed the requirements on SMTP clients after
>       receiving a 220 response.
>    -  Section 5.1: Clarified description of verifying certificates.
>    -  Section 5.3: Added the section on "STARTTLS on the Submission
>       Port"
>    -  Section 6: Bug fix in the example to indicate that the client
>       needs to issue a new EHLO command, as already is described in
>       section 5.2.
>    -  Section 7: Clarification of the paragraph on acceptable degree of
>       privacy. Significant change to the discussion of how to avoid a
>       man-in-the-middle attack.
>    -  Section A: Update reference from RFC 821 to RFC 2821.
>
>
> Corrected Text
> --------------
>    -  Section 4 and 6: More discussion of the man-in-the-middle attacks
>    -  Section 4: Additional discussion of when a server should and
>       should not advertise the STARTTLS extension
>    -  Section 4: Changed the requirements on SMTP clients after
>       receiving a 220 response.
>    -  Section 4.1: Clarified description of verifying certificates.
>    -  Section 4.3: Added the section on "STARTTLS on the Submission
>       Port"
>    -  Section 5: Bug fix in the example to indicate that the client
>       needs to issue a new EHLO command, as already is described in
>       section 4.2.
>    -  Section 5: Clarification of the paragraph on acceptable degree of
>       privacy. Significant change to the discussion of how to avoid a
>       man-in-the-middle attack.
>    -  Section 7: Update reference from RFC 821 to RFC 2821.
>
>
> Notes
> -----
> The appendix lists the changes as they apply to the sections of rfc 2487, but the links in
https://tools.ietf.org/html/rfc3207#page-8 point back to the section numbers in RFC 3207.  Either the
section numbers referred to should be RFC 3207 numbers (the correction i'm proposing here), or the links
within the HTML version should point back to RFC 2487 instead.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3207 (draft-hoffman-rfc2487bis-06)
> --------------------------------------
> Title               : SMTP Service Extension for Secure SMTP over Transport Layer Security
> Publication Date    : February 2002
> Author(s)           : P. Hoffman
> Category            : PROPOSED STANDARD
> Source              : Legacy
> Area                : Legacy
> Stream              : IETF
> Verifying Party     : IESG
>
--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org
Martin Vigoureux | 24 Jul 19:09 2015

heritage through replacement?

Hi,

as Shepherd of draft-ietf-l2vpn-spbm-evpn-02 I had prepared the write-up 
for the document. I had also done a review of the doc.
The author decided to republish as draft-ietf-bess-spbm-evpn-00.
I had no opposition to that since the item is being handled by BESS 
since the closure of L2VPN.
However when I marked draft-ietf-l2vpn-... as replaced by 
draft-ietf-bess-... I realized that the latter did not inherit the 
characteristics of the former (intended status, state, write-up, 
shepherd, ...).

I had no precise expectation regarding that rather I was curious to know 
what would be the result.

Now that I know, I wonder if some characteristics shouldn't be copied 
from one to the other, or even ideally that we be given the choice of 
what to replicate.

Thoughts?

-m

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Stephen Farrell | 24 Jul 11:59 2015
Picon
Picon

weird tokbind wg page results


Hiya,

Yoav (cc'd) and I are accessing [1] and his browser shows
this as a concluded wG, whereas mine correctly shows this
as an active WG. Using wget both of us see it as active.

I guess this is some weird scripting thing somewhere. Yoav
can tell you browser details. (Mine's FF-latest/ubuntu-latest).

Any ideas?

Ta,
S.

[1] https://tools.ietf.org/wg/tokbind/

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org

Tony Hansen | 19 Jul 12:49 2015
Picon

question on datatracker access to particular I-D version

I'm working on generating bibxml3 (bibxml for internet drafts) via
django and the datatracker database.

Is there a way to pull up a >particular version< of an I-D on the
datatracker via the URL?

That is, URLs such as

http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02
http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf?version=02
http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt
http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02

as opposed to

http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf

which pulls up the final document and lets you get at the earlier
versions after additional clicks.

    Tony Hansen

Full discussion:

I'm also looking at the possibility of making an update to remove the
<format> entries and replacing them with a target on the <reference>
element.

I had *thought* that I could do this using a reference to the
datatracker copy of the internet drafts. But there is an issue.

For each internet draft, e.g. draft-ietf-example-foo-*, there are at
least two entries:

    reference.I-D.draft-ietf-example-foo-00.xml       
    reference.I-D.ietf-example-foo.xml

That is, there is a specific entry for each version of the document with
the complete name of the document and version, PLUS a single entry for
the document >series< that does not have any version number or the
leading "draft-" prefix. This last entry is updated whenever a new
version is created

Picking a draft at random, and doing an ls -l on its variants shows this:

-r--r--r-- 1 tony tony      986 Jun 26  2014
reference.I-D.draft-hansen-rfc-use-of-pdf-00.xml
-r--r--r-- 1 tony tony     1096 Jul 21  2014
reference.I-D.draft-hansen-rfc-use-of-pdf-01.xml
-r--r--r-- 1 tony tony     1089 Jul 22  2014
reference.I-D.draft-hansen-rfc-use-of-pdf-02.xml
-r--r--r-- 1 tony tony      982 Oct 27  2014
reference.I-D.draft-hansen-rfc-use-of-pdf-03.xml
-r--r--r-- 1 tony tony      982 Jan 23 00:00
reference.I-D.draft-hansen-rfc-use-of-pdf-04.xml
-r--r--r-- 1 tony tony      983 Feb 17 00:00
reference.I-D.draft-hansen-rfc-use-of-pdf-05.xml
-r--r--r-- 1 tony tony     1089 Mar  9 00:00
reference.I-D.draft-hansen-rfc-use-of-pdf-06.xml
-r--r--r-- 1 tony tony     1090 Mar 25 00:00
reference.I-D.draft-hansen-rfc-use-of-pdf-07.xml

-r--r--r-- 1 tony tony     1090 Mar 25 00:00
reference.I-D.hansen-rfc-use-of-pdf.xml

Currently the document series entry is always identical to the
largest-numbered entry.

The relevant bits of one of these files (-02) for this discussion are:

<reference anchor='I-D.hansen-rfc-use-of-pdf'>
    <seriesInfo name='Internet-Draft'
value='draft-hansen-rfc-use-of-pdf-02' />
    <format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt'
/>
</reference>

I could certainly do a direct move of the existing target so that we get

<reference anchor='I-D.hansen-rfc-use-of-pdf'
target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt'>
    <seriesInfo name='Internet-Draft'
value='draft-hansen-rfc-use-of-pdf-02' />
</reference>

But that doesn't use the datatracker like I wanted.

I could make the document series entry different from the
individual-document entry, as in:

<reference anchor='I-D.hansen-rfc-use-of-pdf'
target='http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf'>
    <seriesInfo name='Internet-Draft'
value='draft-hansen-rfc-use-of-pdf-07' />
</reference>

But I don't know of any way to pull up a particular version of the I-D
on the datatracker via the command line. That is, URLs such as

http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02
http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt
http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02

So, unless I can find a way to reference the individual version of a
document on the datatracker, the individual-document entries would need
to continue using the www.ietf.org/internet-drafts URL instead of a
datatracker URL.

--

-- 
Tools-discuss mailing list
Tools-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/tools-discuss

Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
send email to webmaster <at> tools.ietf.org


Gmane