draft-ietf-genarea-datatracker-community-05.txt   draft-ietf-genarea-datatracker-community-06.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational January 28, 2011 Intended status: Informational February 22, 2011
Expires: August 1, 2011 Expires: August 26, 2011
Requirements for Draft Tracking by the IETF Community in the Datatracker Requirements for Internet-Draft Tracking by the IETF Community in the
draft-ietf-genarea-datatracker-community-05 Datatracker
draft-ietf-genarea-datatracker-community-06
Abstract Abstract
The document gives a set of requirements for extending the IETF The document gives a set of requirements for extending the IETF
Datatracker to give individual IETF community members, including the Datatracker to give individual IETF community members, including the
IETF leadership, easy methods for tracking the progress of the IETF leadership, easy methods for tracking the progress of the
Internet Drafts and RFCs of interest to them. Internet-Drafts and RFCs of interest to them.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2011. This Internet-Draft will expire on August 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
1.2. Context for This Document . . . . . . . . . . . . . . . . 5 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
1.3. Definitions Used in This Document . . . . . . . . . . . . 6 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
1.4. Expected user interactions . . . . . . . . . . . . . . . . 7 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7
1.5. Discussion of These Requirements . . . . . . . . . . . . . 7 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
2. Requirements for Tools Features . . . . . . . . . . . . . . . 7 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Requirement: Lists of drafts and RFCs can be large . . 7 2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 7
2.1.2. Requirement: Every Datatracker user can create a 2.1.2. Requirement: Every Datatracker user can create a
list . . . . . . . . . . . . . . . . . . . . . . . . . 8 list . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Requirement: Read-only views of private lists can 2.1.3. Requirement: Read-only views of private lists can
be made visible to others . . . . . . . . . . . . . . 8 be made visible to others . . . . . . . . . . . . . . 8
2.1.4. Requirement: The Datatracker must support optional 2.1.4. Requirement: The Datatracker must support optional
publicly-readable lists for WGs and Area Directors . . 8 publicly-readable lists for WGs and Area Directors . . 8
2.1.5. Requirement: Specifying the drafts and RFCs that 2.1.5. Requirement: Specifying the I-Ds and RFCs that are
are in a list must be simple . . . . . . . . . . . . . 9 in a list must be simple . . . . . . . . . . . . . . . 9
2.1.6. Requirement: Adding groups of drafts to a list by 2.1.6. Requirement: Adding groups of I-Ds to a list by
attribute must be simple . . . . . . . . . . . . . . . 9 attribute must be simple . . . . . . . . . . . . . . . 9
2.1.7. Requirement: These extensions must not make the 2.1.7. Requirement: Private information must not be
Datatracker take up too many resources . . . . . . . . 10
2.1.8. Requirement: Private information must not be
exposed in lists . . . . . . . . . . . . . . . . . . . 10 exposed in lists . . . . . . . . . . . . . . . . . . . 10
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Requirement: Users can be notified when a draft 2.2.1. Requirement: Users can be notified when an I-D
changes status . . . . . . . . . . . . . . . . . . . . 10 changes status . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Requirement: Every list has Atom feeds associated 2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 11 with it . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. Requirement: Every list has mail streams 2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 11 associated with it . . . . . . . . . . . . . . . . . . 10
2.2.4. Requirement: Notifications need to specify which 2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 11 list caused the notification . . . . . . . . . . . . . 11
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 11 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 11
2.3.1. Requirement: Users can define how the rows are 2.3.1. Requirement: Users can define their Datatracker
sorted in a display . . . . . . . . . . . . . . . . . 12 document view . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Requirement: Users can choose which attributes to 2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 13 display . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3. Requirement: Users can flag drafts with dates in 2.3.3. Requirement: Users can flag I-Ds with dates in the
the future . . . . . . . . . . . . . . . . . . . . . . 13 future . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4. Requirement: Users can specify highlighting of 2.3.4. Requirement: Users can specify highlighting of
drafts and RFCs with recent changes . . . . . . . . . 14 I-Ds and RFCs with recent changes . . . . . . . . . . 13
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.1. Requirement: Users can get their current list as a 2.4.1. Requirement: Users can get their current list as a
single file . . . . . . . . . . . . . . . . . . . . . 14 single file . . . . . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
6. Informative References . . . . . . . . . . . . . . . . . . . . 15 6. Informative References . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Possible Tracking of Other Documents . . . . . . . . 16 Appendix A. Possible Tracking of Other Documents . . . . . . . . 15
A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 16 A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15
A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 16 A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
A.3. Tracking Changes in the Liason Statement Directory . . . . 16 A.3. Tracking Changes in the Liason Statement Directory . . . . 16
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16 A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16
Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17 A.5. Tracking Additions to the IPR Statement Repository . . . . 16
Appendix C. Ideas that Might Be Implemented Later . . . . . . . . 17 Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16
Appendix D. Differences Between -04 and -05 . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The IETF Datatracker is used by many IETF community members to find The IETF Datatracker is used by many IETF community members to find
the status of Internet Drafts (I-Ds) and RFCs, and view drafts and the status of Internet-Drafts (I-Ds) and RFCs, and view I-Ds and RFCs
RFCs that meet particular criteria. The current Datatracker, found that meet particular criteria. The current Datatracker, found at
at <https://datatracker.ietf.org/>, allows anyone to search for <https://datatracker.ietf.org/>, allows anyone to search for active
active I-Ds and RFCs, and get a list matching the given criteria. I-Ds and RFCs, and get a list matching the given criteria. (The
(The Datatracker also allows for expired I-Ds, but those are not Datatracker also allows for expired I-Ds, but those are not relevant
relevant to this discussion.) to this discussion.)
Users can search in the Datatracker by the filename of the draft, Users can search in the Datatracker by the filename of the I-D, words
words in the draft's title, author, associated Working Group (WG) or in the I-D title, I-D author list, associated Working Group (WG),
IETF area, the responsible Area Director (AD), or IESG status. They IETF area, the responsible Area Director (AD), or IESG status. They
can search for RFCs by number or words in the title. The returned can search for RFCs by number or words in the title. The returned
list of drafts and/or RFCs includes five columns: filename or RFC list of I-Ds and/or RFCs includes five columns: filename or RFC
number (with an active link to an HTMLized version maintained by the number (with an active link to an HTMLized version maintained by the
IETF tools team), the document's title, the date it was published, IETF tools team), the document's title, the date it was published,
its status in the IETF or RFC process, and the responsible AD (if its status in the IETF or RFC process, and the responsible AD (if
any). For example, the output of a search in the current Datatracker any). For example, the output of a search in the current Datatracker
can be seen at <http://imgur.com/DD3AL>. can be seen at <http://imgur.com/DD3AL>.
Instead of using the search capability of the Datatracker to manually Instead of using the search capability of the Datatracker to manually
find I-Ds and RFCs of interest, users might want to create a list of find I-Ds and RFCs of interest, users might want to create a list of
drafts that they normally follow. Some users will want to keep their I-Ds that they normally follow. Some users will want to keep their
list to themselves, but others will want to allow others to view list to themselves, but others will want to allow others to view
their list. their list.
Different users in the IETF community will have different ways that Different users in the IETF community will have different ways that
they want to get information on draft and RFC updates and status. they want to get information on I-D and RFC updates and status. Many
Many users will want to be notified immediately, such as through an users will want to be notified immediately, such as through an Atom
Atom feed (see [RFC4287]) or automatically-generated email. Many feed (see [RFC4287]) or automatically-generated email. Many users
users will want to only find out about updates when they go to a web will want to only find out about updates when they go to a web page.
page. Many users might want to get the data for a list as input to Many users might want to get the data for a list as input to other
other tools. And, of course, some users will want all three. All of tools. And, of course, some users will want all three. All of these
these desires are related to the overall desire to track drafts assist users in tracking I-Ds through their lifecycle.
through their lifecycle.
1.1. Usage Scenarios 1.1. Usage Scenarios
The main motivation for these proposed changes to the Datatracker is The main motivation for these proposed changes to the Datatracker is
to allow a variety of potential users to be able to track drafts and to allow a variety of potential users to be able to track I-Ds and
RFCs, and thus be better able to see when important events happen. A RFCs, and thus be better able to see when important events happen. A
few examples include: few examples include:
o A WG chair might want to keep a list of all the drafts from other o A WG chair might want to keep a list of all the I-Ds from other
WGs that relate to active drafts in his or her WG. WGs that relate to active I-Ds in his or her WG.
o That same WG chair might want to help WG members be able to follow o That same WG chair might want to help WG members be able to follow
the same drafts that he or she is following. the same I-Ds that he or she is following.
o Someone who cares about an established topic such as the DNS may o Someone who cares about an established topic such as the DNS may
want to follow the various drafts that might make changes to the want to follow the various I-Ds that might make changes to the
DNS, as well as seeing if any of the DNS RFCs are later updated DNS, as well as seeing if any of the DNS RFCs are later updated
and/or have errata posted against them. This would include not and/or have errata posted against them. This would include not
only drafts that are in the many WGs that directly are changing only I-Ds that are in the many WGs that directly are changing the
the DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual
submissions, IAB drafts, and even IRTF research. It would also submissions, IAB I-Ds, and even IRTF research. It would also
include RFCs from before when WGs were tracked. include RFCs from before when WGs were tracked.
o Developers who are not active in the IETF process might want to o Developers who are not active in the IETF process might want to
lightly follow drafts and RFCs on a particular topic to watch for lightly follow I-Ds and RFCs on a particular topic to watch for
things that might affect their implementations. things that might affect their implementations.
o An IETF "regular" might want to follow parts of the process by o An IETF "regular" might want to follow parts of the process by
focusing on all the drafts that are being shepherded by a focusing on all the I-Ds that are being shepherded by a particular
particular Area Director. Area Director.
1.2. Context for This Document 1.2. Context for This Document
This document describes the requirements for extending the This document describes the requirements for extending the
Datatracker for such capabilities. When complete, this document may Datatracker for such capabilities. When complete, this document may
be used to issue an RFP for the design and development of these be used to issue an RFP for the design and development of these
enhancements to the Datatracker. This document was prepared at the enhancements to the Datatracker.
request of the IAOC.
Some of the requirements in this document are listed as "later Some of the requirements in this document are listed as "later
requirements". This means that these requirements might not be part requirements". It is expected that items listed in this document
of the first RFP for adding these enhancements. would be part of the initial RFP because they provide the highest
benefit to the community; the later requirements might be part of a
later RFP.
The statement of work that led to this document says "The tools that The initial general requirements that led to the specific
will eventually be provided to individuals in the community include": requirements this document described tools that include:
o the ability to create one or more (possibly large) lists of I-Ds o the ability to create one or more (possibly large) lists of I-Ds
that they want to follow that they want to follow
o the ability to get notifications when individual drafts from a o the ability to get notifications when individual I-Ds from a list
list changes state changes state
o the ability to see all of the state changes that have occurred on o the ability to see all of the state changes that have occurred on
all the drafts in a list over a specified range of dates all the I-Ds in a list over a specified range of dates
o the ability to set the granularity of the changes (such as "every o the ability to set the granularity of the changes (such as "every
change", "just approvals and publication", and so on) change", "just approvals and publication", and so on)
o the ability to organize their views of a list in many fashions o the ability to organize their views of a list in many fashions
that would be useful to different types of community members that would be useful to different types of community members
o the ability to share and merge lists with other community members o the ability to share and merge lists with other community members
Note that [RFC2026] describes the process that Internet Drafts go Note that [RFC2026] describes the process that I-Ds go through before
through before they either become RFCs or are abandoned. The they either become RFCs or are abandoned. The Datatracker does not
Datatracker does not control this process: instead, it simply reports control this process: instead, it simply reports on the current state
on the current state of individual drafts as they go through the of each I-D as it goes through the process.
process.
1.3. Definitions Used in This Document 1.3. Definitions Used in This Document
A "user" is an individual person who is member of the IETF community. A "user" is an individual person who is member of the IETF community.
A "list" is an unordered set of RFCs, Internet Drafts, and groups of A "list" is an unordered set of RFCs, I-Ds, and groups of I-Ds.
Internet Drafts. Lists are specified by users. In some cases, the Lists are specified by users. In some cases, the authors are role-
authors are role-based, such as a WG chair being the specifier of the based, such as a WG chair being the specifier of the list associated
list associated with that WG. with that WG.
An "attribute" is a feature of a draft or RFC, such as its filename An "attribute" is a feature of an I-D or RFC, such as its filename or
or RFC number, its current state in the IETF or RFC process, and so RFC number, its current state in the IETF or RFC process, and so on.
on. Attributes are usually displayed as columns in the Datatracker. Attributes are usually displayed as columns in the Datatracker.
A "row" is a set of attributes about a single draft or RFC that is A "row" is a set of attributes about a single I-D or RFC that is
displayed in the Datatracker. displayed in the Datatracker.
A "significant change in status" is all approvals and disposition of A "significant change in status" is all approvals and disposition of
a draft. Assuming that the changes to the Datatracker specified in an I-D. Assuming that the changes to the Datatracker specified in
[WGSTATES] and [ALTSTREAMS] are made, "all approvals" means the [WGSTATES] and [ALTSTREAMS] are made, "all approvals" means the
following: following:
o IETF stream: the WG states "Adopted by a WG", "In WG Last Call", o IETF stream: the WG states "Adopted by a WG", "In WG Last Call",
"WG Consensus: Waiting for Write-up", "Parked WG document", and "WG Consensus: Waiting for Write-up", "Parked WG document", and
"Dead WG document"; the IESG states "Publication Requested", "In "Dead WG document"; the IESG states "Publication Requested", "In
Last Call", and "IESG Evaluation" Last Call", and "IESG Evaluation"
o IAB stream: "Active IAB Document", "Community Review", and "Sent o IAB stream: "Active IAB Document", "Community Review", and "Sent
to the RFC Editor" to the RFC Editor"
skipping to change at page 7, line 14 skipping to change at page 7, line 9
o All streams: in addition to the above, the disposition states o All streams: in addition to the above, the disposition states
"Approved", "RFC Published", and "Dead" are also included "Approved", "RFC Published", and "Dead" are also included
An "update to an RFC" is the announcement of a newer RFC that updates An "update to an RFC" is the announcement of a newer RFC that updates
or obsoletes the base RFC, or an announcement of an errata posted for or obsoletes the base RFC, or an announcement of an errata posted for
the base RFC. the base RFC.
1.4. Expected user interactions 1.4. Expected user interactions
When a user wants to follow a group of drafts and/or RFCs, he or she When a user wants to follow a group of I-Ds and/or RFCs, he or she
goes to the Datatracker and creates a new list. The requirements for goes to the Datatracker and creates a new list. The requirements for
lists are given in Section 2.1. After a list is created, the user lists are given in Section 2.1. After a list is created, the user
has three ways that he or she might see when drafts and/or RFCs in has three ways that he or she might see when I-Ds and/or RFCs in the
the list are updated: list are updated:
o By going to the Datatracker page for the list (see Section 2.3) o By going to the Datatracker page for the list (see Section 2.3)
o By subscribing to the Atom feed for the list (see Section 2.2.2) o By subscribing to the Atom feed for the list (see Section 2.2.2)
in a feed reader that automatically fetches updates in a feed reader that automatically fetches updates
o By subscribing to the mail stream for the list (see Section 2.2.3) o By subscribing to the mail stream for the list (see Section 2.2.3)
and reading the stream in their mail reader and reading the mail stream in their mail reader
1.5. Discussion of These Requirements 1.5. Discussion of These Requirements
[[ This section is to be removed before the RFC is published. ]]
This document is being discussed on the datatracker-rqmts@ietf.org This document is being discussed on the datatracker-rqmts@ietf.org
mailing list. For more information, see mailing list. For more information, see
<https://www.ietf.org/mailman/listinfo/datatracker-rqmts>. <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>.
There will probably be virtual interim meetings to discuss this There will probably be virtual interim meetings to discuss this
document in early 2011. document in early 2011.
2. Requirements for Tools Features 2. Requirements for Tools Features
This section defines the requirements for the tool described earlier This section defines the requirements for the tool described earlier
in this document. The eventual tool, if implemented, may have more in this document. The eventual tool, if implemented, may have more
features than are listed here; however, before this document is features than are listed here; however, before this document is
finished, it should contain as many requirements as possible upon finished, it should contain as many requirements as possible upon
which the IETF community can agree. which the IETF community can agree.
2.1. Lists 2.1. Lists
2.1.1. Requirement: Lists of drafts and RFCs can be large 2.1.1. Requirement: Lists of I-Ds and RFCs can be large
An active IETF participant might want to follow the status of An active IETF participant might want to follow the status of
hundreds of drafts and dozens of RFCs. For example, some ADs have hundreds of I-Ds and dozens of RFCs. For example, some ADs have 100
100 drafts in their area, and they may also want to follow drafts I-Ds in their area, and they may also want to follow I-Ds outside
outside their area that affect documents in their area. their area that affect documents in their area.
2.1.2. Requirement: Every Datatracker user can create a list 2.1.2. Requirement: Every Datatracker user can create a list
When a user gets a Datatracker account, that account comes with an When a user gets a Datatracker account, that account comes with an
empty list pre-defined. The list can normally be modified only by empty list pre-defined. The list can normally be modified only by
the owner of the account, although the Secretariat can also modify the owner of the account, although the Secretariat can also modify
the list as part of its support role for the Datatracker. the list as part of its support role for the Datatracker.
In order for this requirement to be met, it must be easy for any In order for this requirement to be met, it must be easy for any
community member to get a Datatracker account. Account setup must community member to get a Datatracker account. Account setup must
skipping to change at page 8, line 30 skipping to change at page 8, line 29
The only person who can edit the contents of a private list is the The only person who can edit the contents of a private list is the
person who knows the password to the account with which the list is person who knows the password to the account with which the list is
associated. associated.
2.1.3. Requirement: Read-only views of private lists can be made 2.1.3. Requirement: Read-only views of private lists can be made
visible to others visible to others
Some users will want to make available a read-only view of their Some users will want to make available a read-only view of their
list. Each private list will have a URL that leads to the list. Each private list will have a URL that leads to the
Datatracker view of the list; that URL must be able to be safely Datatracker view of the list; that URL must be able to be shared
shared with others. In this case, "safely" means "will not help without giving others the ability to edit the list. Similarly, the
others be able to edit the list". Similarly, the Atom feed Atom feed associated with a private list must be able to be shared
associated with a private list should be able to be safely shared without giving others the ability to edit the list.
with others>
2.1.4. Requirement: The Datatracker must support optional publicly- 2.1.4. Requirement: The Datatracker must support optional publicly-
readable lists for WGs and Area Directors readable lists for WGs and Area Directors
It is common in the IETF for users to follow the work of an entire It is common in the IETF for users to follow the work of an entire
WG, not just individual drafts and RFCs within a WG. It is also very WG, not just single I-Ds and RFCs within a WG. It is also very
common that some work that is related to a WG happens outside the WG, common that some work that is related to a WG happens outside the WG,
either in other WGs or as individual efforts. Many WG chairs monitor either in other WGs or as individual efforts. Many WG chairs monitor
this outside-the-WG activity for various reasons. this outside-the-WG activity for various reasons.
A smaller number of community members to follow an entire Area's A smaller number of community members to follow an entire Area's
worth of topics. Again, these topics often happen within the WGs of worth of topics. Again, these topics often happen within the WGs of
an area, but not always; for example, some topics related to the an area, but not always; for example, some topics related to the
Security Area happen in WGs in the Applications Area. Security Area happen in WGs in the Applications Area.
Because of this, it would be useful for community members to be able Because of this, it would be useful for community members to be able
to find a list which corresponds to the WGs or Areas in which they to find a list which corresponds to the WGs or Areas in which they
are interested. The WG lists could be maintained by the WG chairs; are interested. The WG lists could be maintained by the WG chairs;
the Area lists would likely be maintained by the ADs. Note that such the Area lists would likely be maintained by the ADs. Note that such
lists are not mandatory; for example, a WG chair might not choose to lists are not mandatory; for example, a WG chair might not choose to
maintain such a list for a WG whose topic is extremely broad. maintain such a list for a WG whose topic is extremely broad.
Both Working Group chairs and Area Directors currently already have Both Working Group chairs and Area Directors currently already have
Datatracker accounts, so fulfilling this requirement only involves Datatracker accounts, so fulfilling this requirement only involves
associating those accounts with the role that controls the list. associating those accounts with the role that controls the list.
2.1.5. Requirement: Specifying the drafts and RFCs that are in a list 2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list
must be simple must be simple
When a user creates a new list, it must be easy to add individual When a user creates a new list, it must be easy to add single I-Ds
drafts and RFCs to the list. This could be done using the and RFCs to the list. This could be done using the Datatracker's
Datatracker's current search facility, and simply adding a "add to current search facility, and simply adding a "add to list" option to
list" option for Further, when editing an existing list, it must be the display of searched-for I-Ds. Further, when editing an existing
easy to add additional drafts and RFCs, and it must be easy to remove list, it must be easy to add additional I-Ds and RFCs, and it must be
drafts and RFCs from a list. easy to remove I-Ds and RFCs from a list.
2.1.6. Requirement: Adding groups of drafts to a list by attribute must 2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must
be simple be simple
Drafts have many attributes, and some users might want to follow all I-Ds have many attributes, and some users might want to follow all of
of the drafts that have a particular attribute. Some, but not all, the I-Ds that have a particular attribute. Some, but not all,
attributes have values that make sense in specifying lists. It attributes have values that make sense in specifying lists. It
should be easy to add each of the following attributes when adding to should be easy to add each of the following attributes when adding to
or editing a list: or editing a list:
o All drafts associated with an individual WG o All I-Ds associated with an particular WG
o All drafts associated with all WGs in an individual Area o All I-Ds associated with all WGs in an particular Area
o All drafts with a particular responsible AD o All I-Ds with a particular responsible AD
o All drafts with a particular author o All I-Ds with a particular author
o All drafts with a particular document shepherd o All I-Ds with a particular document shepherd
o All drafts that have a reference to a particular RFC o All I-Ds that have a reference to a particular RFC
o All drafts that have a reference to a particular draft o All I-Ds that have a reference to a particular I-D
o All drafts that are referenced by a particular RFC o All I-Ds that are referenced by a particular RFC
o All drafts that are referenced by a particular draft o All I-Ds that are referenced by a particular I-D
o All drafts that contain a particular text string o All I-Ds that contain a particular text string
These attributes are dynamic, and thus the list of drafts that have a
These attributes are dynamic, and thus the list of I-Ds that have a
particular attribute will change after the user adds that attribute particular attribute will change after the user adds that attribute
to a list. The Datatracker should update lists with dynamic to a list. The Datatracker should update lists with dynamic
attributes as often as is sensible for the server environment, such attributes as often as is sensible for the server environment, such
as once an hour or more. as once an hour or more.
Note that some of these attributes are derived by programs created by Note that some of these attributes are based on heuristics derived by
the IETF Tools Team that parse drafts and are therefore inherently programs that parse I-Ds, and are therefore inherently not completely
not completely reliable. reliable.
2.1.7. Requirement: These extensions must not make the Datatracker take
up too many resources
Currently, the only state that the Datatracker keeps for its users is
a very small set of attributes assigned to a username-password pair.
The extensions described here will cause the Datatracker to need to
keep more information, namely lists. Each list might have additional
associated state as well. This could lead to the Datatracker needing
a larger amount of storage and other resources. When this document
is near completion, it would probably be good to list exactly which
new state will be kept on the Datatracker server.
In order to reduce the chance that these extensions would strain the
Datatracker, some sort of denial-of-service prevention should be used
when the extensions are added.
Culling presents a problem, however, for user-based lists that are
made public. The creator of a list might no longer be using it, but
others might be. Thus, it is likely that the Datatracker needs to be
be able to maintain lists long-term even if their creators are no
longer using them.
2.1.8. Requirement: Private information must not be exposed in lists 2.1.7. Requirement: Private information must not be exposed in lists
Any private information in the Datatracker must be excluded from any Any private information in the Datatracker must be excluded from any
displays of the lists or streams created in this document. This displays of the lists or mail streams. This private information
private information includes private notes in the IESG balloting for includes private notes in the IESG balloting for an I-D, and probably
a draft, and probably other data that currently is restricted to other data that currently is restricted to being seen by certain
being seen by certain members of the IETF leadership. members of the IETF leadership.
2.2. Notifications 2.2. Notifications
2.2.1. Requirement: Users can be notified when a draft changes status 2.2.1. Requirement: Users can be notified when an I-D changes status
Some users do not want to go to the Datatracker's display page to Some users do not want to go to the Datatracker's display page to
find out when a draft or RFC has been updated. Instead, they want to find out when an I-D or RFC has been updated. Instead, they want to
be notified immediately after the change. The Datatracker needs to be notified immediately after the change. The Datatracker needs to
support this type of immediate notification, where "immediate" means support this type of immediate notification, where "immediate" means
"within an hour of a change to any draft or RFC in the list". This within an hour of a change to any I-D or RFC in the list. This
requirement can be met with Atom feeds and mail streams, as described requirement can be met with Atom feeds and mail streams, as described
in the next two sections. in the next two sections.
The Datatracker might create a generic "notifications engine" that The Datatracker might create a generic "notifications engine" that
can be used to generate the Atom feeds and mail streams. This engine can be used to generate the Atom feeds and mail streams. This engine
can then be used to later add other notification types, such as a can then be used to later add other notification types, such as a
Jabber feed. Jabber feed.
2.2.2. Requirement: Every list has Atom feeds associated with it 2.2.2. Requirement: Every list has Atom feeds associated with it
The list will have two Atom feeds that are generated from the changes The list will have two Atom feeds that are generated from the changes
to the list: one for every change in status, and another for to the list: one for every change in status, and another for
significant change of status. Each Atom feed will have a stable URL significant change of status. Each Atom feed will have a stable URL
that can be used by feed readers. that can be used by feed readers.
Many IETF users are already using Atom feeds created by the IETF Many IETF users are already using Atom feeds created by the IETF
Tools Team for individual drafts. Using the new feeds for lists Tools Team for single I-Ds. Using the new feeds for lists described
described here will allow them to have better selection capabilities here will allow them to have better selection capabilities to reduce
to reduce the number of feeds they need to follow. the number of feeds they need to follow.
2.2.3. Requirement: Every list has mail streams associated with it 2.2.3. Requirement: Every list has mail streams associated with it
A user can subscribe to two email streams that are generated from the A user can subscribe to two mail streams that are generated from the
changes to the list: one for every change in status, and another for changes to the list: one for every change in status, and another for
significant change of status. significant change of status.
Note that the mail streams are for each change; they are not batched Note that the mail streams are for each change; they are not batched
(such as one message per day). Users who want less frequent but (such as one message per day). Users who want less frequent but
batched notifications need to use the Atom feeds instead of the mail batched notifications need to use the Atom feeds instead of the mail
streams. streams.
2.2.4. Requirement: Notifications need to specify which list caused the 2.2.4. Requirement: Notifications need to specify which list caused the
notification notification
Users might have feeds and/or subscriptions to multiple lists. In Users might have feeds and/or subscriptions to multiple lists. In
order to disambiguate duplicate notifications from multiple lists, order to disambiguate duplicate notifications from multiple lists,
the body of the message in the Atom feed or mail stream needs to say the body of the message in the Atom feed or mail stream needs to say
which list generated the notification. (Ideally, a user who wants which list generated the notification. (Ideally, a user who wants
notifications will make one list based on multiple lists, but if they notifications will make one list based on multiple lists, but if they
subscribe to multiple lists, this requirement will at least suggest subscribe to multiple lists, this requirement will at least suggest
to them that they want to limit their overlapping subscriptions.) to them that they want to limit their overlapping subscriptions.)
2.3. Display in the Datatracker 2.3. Display in the Datatracker
2.3.1. Requirement: Users can define how the rows are sorted in a
display 2.3.1. Requirement: Users can define their Datatracker document view
There are many ways that a user might want to see the Datatracker's There are many ways that a user might want to see the Datatracker's
HTML view of a list. For example, a user might want to normally see HTML view of a list. For example, a user might want the view
it in alphabetical order by the drafts' filenames and RFC numbers, displayed in alphabetical order by the I-Ds' filenames and RFC
but after the user is of the net for a week, he or she might want to numbers, but after the user is of the net for a week, he or she might
see the list in order of changes of status so that those drafts and want the view displayed in order of changes of status so that those
RFCs changed recently appear at the top of the list. I-Ds and RFCs changed recently appear at the top.
The default is to first list the groups first in alphabetical order The default is to first list the groups first in alphabetical order
by group name, then individual drafts in alphabetical order by draft by group name, then single I-Ds in alphabetical order by I-D
filename, with RFCs at the end. When displaying a list, the filename, with RFCs at the end. When displaying a list, the
Datatracker should allow easy sorting of the drafts with the Datatracker should allow easy sorting of the I-Ds with the following
following collation orders: collation orders:
o Alphabetical order by group name followed by individual drafts and o Alphabetical order by group name followed by single I-Ds and RFCs
RFCs (default) (default)
o Alphabetical by draft filename and RFC number o Alphabetical by I-D filename and RFC number
o Alphabetical by document title o Alphabetical by document title
o Alphabetical by associated WG o Alphabetical by associated WG
o Date of publication of current version of the document o Date of publication of current version of the document
o Date of most recent change of status of any type o Date of most recent change of status of any type
o Date of most recent significant change of status o Date of most recent significant change of status
In displays, a particular draft or RFC should only included once; for In displays, a particular I-D or RFC should only included once; for
example, if someone manually adds draft-ietf-cuteacronym-sometopic to example, if someone manually adds draft-ietf-cuteacronym-sometopic to
his list and also specifies that all drafts from the "cuteacronym" WG his list and also specifies that all I-Ds from the "cuteacronym" WG
are included in the list, that draft should only appear once in the are included in the list, that I-D should only appear once in the
display. The column saying which included list(s) contain this draft display. The column saying which included list(s) contain this I-D
helps alleviate this loss of information. helps alleviate this loss of information.
The user might also want to group the drafts using the groupings in The user might also want to group the I-Ds using the groupings in the
the list, such as "all drafts from this WG" and "all drafts that list, such as "all I-Ds from this WG" and "all I-Ds that contain this
contain this word in the title". word in the title".
The Datatracker should save the last-chosen sorting for display with The Datatracker should save the last-chosen sorting for display with
the definition of the list. the definition of the list.
2.3.2. Requirement: Users can choose which attributes to display 2.3.2. Requirement: Users can choose which attributes to display
There are many attributes that might be displayed, and different There are many attributes that might be displayed, and different
users will have different information that they want to see. Also, users will have different information that they want to see. Also,
users will have different display technologies: someone might users will have different display technologies: someone might
normally use a web browser on a large screen, but at other times use normally use a web browser on a large screen, but at other times use
the browser on their phone. the browser on their phone.
Choosing which attributes should be displayed should be simple for Choosing which attributes should be displayed should be simple for
the user. The Datatracker should save the last-chosen set of the user. The Datatracker should save the last-chosen set of
attributes for display with the definition of the list. The default attributes for display with the definition of the list. The default
is to display is draft filename or RFC number, document title, date is to display is I-D filename or RFC number, document title, date of
of current draft or RFC publication date, status in stream or RFC current I-D or RFC publication date, status in the RFC stream or RFC
process, associated WG or RG, whether it was changed within the last process, associated WG or RG, whether it was changed within the last
7 days, and included list(s) which contain this draft. 7 days, and included list(s) which contain this I-D.
The Datatracker should support display of the following attributes: The Datatracker should support display of the following attributes:
o Draft filename o I-D filename
o Draft title o I-D title
o Date of current draft o Date of current I-D
o Status in the IETF process o Status in the IETF process
o Associated WG or RG o Associated WG or RG
o Associated AD, if any o Associated AD, if any
o Changed within the last 1 day o Changed within the last 1 day
o Changed within the last 2 days o Changed within the last 2 days
o Changed within the last 7 days o Changed within the last 7 days
There is some leeway for how the Datatracker might display these There is some leeway for how the Datatracker might display these
attributes. For example, the "changed within" attributes might be attributes. For example, the "changed within" attributes might be
shown with a check mark or a colored box. shown with a check mark or a colored box.
2.3.3. Requirement: Users can flag drafts with dates in the future 2.3.3. Requirement: Users can flag I-Ds with dates in the future
When tracking drafts, some users want to be able to say "tell me if When tracking I-Ds, some users want to be able to say "tell me if
this draft has not changes state by a particular date" such as when a this I-D has not changes state by a particular date" such as when an
draft is starting a two-week last call or a draft author has promised I-D is starting a two-week last call or an I-D author has promised a
a new version by the end of the week. This feature gives the user a new version by the end of the week. This feature gives the user a
"dashboard" style capability. "dashboard" style capability.
For each draft in a list, the user should be able to set one date- For each I-D, the user should be able to set a marker date by which
based deadline. When using the display version of the Datatracker, an update is expected. The Datatracker display will provide a visual
if that date has passed and no change in status happened between the indication if the marker date has passed but no change in status has
time that the user set the deadline and the set date, the Datatracker occurred. It must be very easy for the user to remove these update-
will highlight the deadline in red. It must also be easy to remove expected markers.
these deadlines.
2.3.4. Requirement: Users can specify highlighting of drafts and RFCs 2.3.4. Requirement: Users can specify highlighting of I-Ds and RFCs
with recent changes with recent changes
The Datatracker cannot easily keep track of when a user last looked The Datatracker cannot easily keep track of when a user last looked
at the page for a particular list. Thus, it instead needs to let a at the page for a particular list. Thus, it instead needs to let a
user say which range of dates they are most interested in. To that user say which range of dates they are most interested in. To that
end, the user needs to be able to easily specify the amount of time end, the user needs to be able to easily specify the amount of time
they consider recent, either as "the past nnn hours", "the past nnn they consider recent, either as "the past nnn hours", "the past nnn
days", or "since this particular date". days", or "since this particular date".
2.4. File Output 2.4. File Output
2.4.1. Requirement: Users can get their current list as a single file 2.4.1. Requirement: Users can get their current list as a single file
Some users have their own tools for displaying and otherwise Some users have their own tools for displaying and otherwise
processing lists of drafts and RFCs. To make this easier, users processing lists of I-Ds and RFCs. To make this easier, users should
should be able to get a machine-parsable file that has a well-known be able to get a machine-parsable file that has a well-known format
format and syntax that contains all the data that was used to create and syntax that contains all the data that was used to create the
the current display. The order of the records in the file is not current display. The order of the records in the file is not
important because it is assumed that the user's program will sort the important because it is assumed that the user's program will sort the
results themselves. All attributes will be included because it is results themselves. All attributes will be included because it is
assumed that the user's programs will only deal with the ones the assumed that the user's programs will only deal with the ones the
care about. user cares about.
When a list is marshaled into a data file, each record in the file When a list is marshaled into a data file, each record in the file
format represents a single draft or RFC. In a file, a particular format represents a single I-D or RFC. In a file, a particular I-D
draft or RFC is only included once; for example, if someone manually or RFC is only included once; for example, if someone manually adds
adds draft-ietf-cuteacronym-sometopic to his list and also specifies draft-ietf-cuteacronym-sometopic to his list and also specifies that
that all drafts from the "cuteacronym" WG are included in the list, all I-Ds from the "cuteacronym" WG are included in the list, that I-D
that draft only appears once. only appears once.
This feature will allow anyone to create mash-ups of their own and This feature will allow anyone to create mash-ups of their own and
create their own web sites based on the IETF data. This is create their own web sites based on the IETF data. This is
significantly easier than adding features to the Datatracker, and is significantly easier than adding features to the Datatracker, and is
able to cater to narrower audiences. able to cater to narrow audiences. The format of this file has yet
to be determined.
3. IANA Considerations 3. IANA Considerations
None. None.
4. Security Considerations 4. Security Considerations
A tool for tracking the status of Internet Drafts and RFCs can affect A tool for tracking the status of I-Ds and RFCs can affect the
the privacy of its users. Someone could possibly determine relevant privacy of its users. Someone could possibly determine relevant
information about a user if they knew what that user was tracking. information about a user if they knew what that user was tracking.
Web applications, particularly those that store data on a web server, Web applications, particularly those that store data on a web server,
are a common source of security issues such as cross-site scripting are a common source of security issues such as cross-site scripting
attacks. The tool described in this document might also use access attacks. The tool described in this document might also use access
control for lists, and access control and authentication also cause control for lists, and access control and authentication also cause
security issues if not implemented properly. security issues if not implemented properly.
5. Acknowledgements 5. Acknowledgements
skipping to change at page 16, line 9 skipping to change at page 15, line 23
[WGSTATES] [WGSTATES]
Juskevicius, E., "Definition of IETF Working Group Juskevicius, E., "Definition of IETF Working Group
Document States", draft-ietf-proto-wgdocument-states (work Document States", draft-ietf-proto-wgdocument-states (work
in progress), October 2010. in progress), October 2010.
Appendix A. Possible Tracking of Other Documents Appendix A. Possible Tracking of Other Documents
It is not at all clear if any of these will be a requirement, a later It is not at all clear if any of these will be a requirement, a later
requirement, or a non-requirement. Further, even if one or more of requirement, or a non-requirement. Further, even if one or more of
these non-draft items is made a requirement, it is not clear whether these non-I-D items is made a requirement, it is not clear whether
they will be included in the same lists with drafts. That is, if they will be included in the same lists with I-Ds. That is, if
tracking IANA registry changes are considered a requirement, it is tracking IANA registry changes are considered a requirement, it is
not clear whether a user would include the registries in a list that not clear whether a user would include the registries in a list that
also contains draft, or whether they would need to create two lists, also contains I-Ds, or whether they would need to create two lists,
one for drafts and one for IANA registries. one for I-Ds and one for IANA registries.
A.1. Tracking WG Charter Changes A.1. Tracking WG Charter Changes
It will soon be easier to track changes in WG charters and It will soon be easier to track changes in WG charters and
milestones; see [CHARTERTOOL] for more information. Someone milestones; see [CHARTERTOOL] for more information. Someone
subscribing to the stream for a WG would be able to see each of these subscribing to the mail stream for a WG would be able to see each of
changes. With the expected changes, the Datatracker would be able to these changes. With the expected changes, the Datatracker would be
update WGs in a list without any polling. able to update WGs in a list without any polling.
A.2. Tracking IANA Registry Changes A.2. Tracking IANA Registry Changes
Developers may need to get values from IANA registries for their Developers may need to get values from IANA registries for their
software/hardware implementations. They might want to know when the software/hardware implementations. They might want to know when the
registry changes, such as additional entries or updates to current registry changes, such as additional entries or updates to current
entries. Thus, being able to be notified when a registry changes entries. Thus, being able to be notified when a registry changes
would be valuable to them. would be valuable to them.
Adding this functionality may be tricky for some registries. For Adding this functionality may be tricky for some registries. For
skipping to change at page 17, line 5 skipping to change at page 16, line 21
IETF, or when one is received by the IETF. IETF, or when one is received by the IETF.
A.4. Tracking Changes in Documents Outside the IETF Sphere A.4. Tracking Changes in Documents Outside the IETF Sphere
Users might want to track documents that relate to IETF activities Users might want to track documents that relate to IETF activities
but are produced by other standards development organizations (SDOs) but are produced by other standards development organizations (SDOs)
such as the W3C, the IEEE, the Unicode Consortium, the ITU, and such as the W3C, the IEEE, the Unicode Consortium, the ITU, and
others. In order for the tracker to track these documents, it would others. In order for the tracker to track these documents, it would
need to poll occasionally and possibly scrape listings from HTML. need to poll occasionally and possibly scrape listings from HTML.
Appendix B. Some Known Open Issues A.5. Tracking Additions to the IPR Statement Repository
This list is mostly meant to remind the author of topics that need to
be updated in future versions of the document, and to spur readers to
think of even more open issues.
o When an AD agrees to sponsor an individual submission, does the
Datatracker consider that draft associated with the AD? If not,
that needs to be dealt with here.
o The format of the export file will be XML or JSON or tab-separated Users might want to know when a new IPR statement is submitted.
fields in a text file. Regardless of the format chosen, a syntax
will need to be specified.
Appendix C. Ideas that Might Be Implemented Later Appendix B. Ideas that Might Be Implemented Later
The following are ideas for the new tool that are not currently being The following are ideas for the new tool that are not currently being
considered for the first round of development, but are being considered for the first round of development, but are being
documented for possible future use. Items here might move between documented for possible future use. Items here might move between
this list and the list of requirements that are expected to be in the this list and the list of requirements that are expected to be in the
first round. first round.
o The Datatracker could list all of the publicly-readable lists (or o The Datatracker could list all of the publicly-readable lists (or
certainly at least the ones associated with IETF activities), and certainly at least the ones associated with IETF activities), and
have links from WG pages in Datatracker to the publicly-readable have links from WG pages in Datatracker to the publicly-readable
lists maintained by the WG chairs. lists maintained by the WG chairs.
o Earlier versions of this draft had a requirement that lists needed o Earlier versions of this I-D had a requirement that lists needed
to be able to include other lists. While this may still be to be able to include other lists. While this may still be
desired, it was decided that implementing this in a safe and desired, it was decided that implementing this in a safe and
understandable way would be too difficult. Later versions of the understandable way would be too difficult. In particular, there
Datatracker might include this feature. was a concern about detecting and handling loops. Later versions
of the Datatracker might include this feature.
o In public lists, it might be useful for someone to be able to o In public lists, it might be useful for someone to be able to
understand why particular drafts and/or groups are added. understand why particular I-Ds and/or groups are added. Allowing
Allowing the user who put together the list to add a comment field the user who put together the list to add a comment field would
would help someone else see the motivation. help someone else see the motivation.
o The Datatracker might cull lists if it seems that storing them on o The Datatracker might cull lists if it seems that storing them on
the Datatracker is taking too many resources. The Datatracker can the Datatracker is taking too many resources. The Datatracker can
periodically send mail to the user reminding them to delete lists periodically send mail to the user reminding them to delete lists
that are no longer needed. that are no longer needed.
o The normal Datatracker display could have a button to add a o The normal Datatracker display could have a button to add a
particular draft to the user's personal list. particular I-D to the user's personal list.
o Allow each user to determine what "significant change in status" o Allow each user to determine what "significant change in status"
is for the list they create. This could be done by a series of is for the list they create. This could be done by a series of
check boxes for every possible status change. check boxes for every possible status change.
o A list creator can add a list-level comment about who might be o A list creator can add a list-level comment about who might be
interested in following the list. interested in following the list.
o If the agendas for an upcoming meeting are scraped for draft o If the agendas for an upcoming meeting are scraped for I-D names,
names, it would be possible to add an attribute to a draft that it would be possible to add an attribute to an I-D that lists that
lists that WG agenda(s) on which it appears. WG agenda(s) on which it appears.
o In the section on "Adding groups of drafts to a list by o In the section on "Adding groups of I-Ds to a list by attribute",
attribute", add an attribute for "all drafts that are referenced add an attribute for "all I-Ds that are referenced by any I-D in a
by any draft in a particular list". particular list".
o Make it possible to add all drafts that have a certain section to o Make it possible to add all I-Ds that have a certain section to a
a list (non-trivial IANA considerations, ASN.1 modules in list (non-trivial IANA considerations, ASN.1 modules in
appendices, ...). appendices, MIBs, ABNF, XML modules, ...).
o Even though Atom feeds have been around for years, they are new to o Even though Atom feeds have been around for years, they are new to
many Internet users, and even experienced users only know how to many Internet users, and even experienced users only know how to
use them in limited ways. The Datatracker should have at least a use them in limited ways. The Datatracker should have at least a
few paragraphs explaining how the Atom feeds that it provides can few paragraphs explaining how the Atom feeds that it provides can
be used in different tools such as dedicated feed readers, online be used in different tools such as dedicated feed readers, online
feed-display services, and so on. feed-display services, and so on.
Appendix D. Differences Between -04 and -05
Removed another "early" note from the intro.
Moved "later" requirements from the body of the document to the
appendix.
Moved the open issue of the file format into the open issues list.
Throughout, made RFC status part of what is in a list.
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 107 change blocks. 
258 lines changed or deleted 213 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/