Feed Paging and Archiving
RFC 5005

[Ballot discuss]
Is there a reason not to have an fh:paged element in the paged feeds?

In
  Paged feed documents MUST have at least one of these link relations
  present, and should contain as many as practical and applicable.
seems like it would be better to chance should to SHOULD

In the archive feeds, it is very confusing about the relationship between current and the linked list of archive documents. Doe the next of the "most next" document point at current? Is the text
    Additionally, archive documents SHOULD have "next-
    archive" and "current" link relations.
correct for the "most next" end of the list? I think this could use some clarification.

In IANA section, I think the  "previous", "next" and "current"  registrations need to be updated to point at this document.

Do you think the RSS folks would be bothered we are publishing what looks like an RSS extension?

[Ballot discuss]
The opening paragraph in the Security Considerations section is misleading.  It states:

  Feeds using this mechanism have the same authentication and channel
  security concerns as explained in Atom [RFC4287].

First, the word "channel" never appears in RFC 4287.  I suspect that the authors are referring
to the XML encryption mechanism in 4287, but that mechanism protects a feed rather than
the entire channel.  (To me, "channel security" implies all the communications between the
two parties are protected.  This secures communications in a single direction.)

In addition, based on my limited  understanding of their XML formats, I believe that a logical
feed may include a mixture of encrypted or unencrypted data, signed and unsigned data.  Is
there any guidance for atompub servers regarding selective signing or encryption of the feed
or entry???  This guidance might be different for the different classes of feeds...

I would suggest replacing the first sentence with a paragraph stating this specification assumes
that encryption or authentication security services are obtained by encrypting or signing the
feed, as descrribed in RFC 4287.  Other services are out of scope, and syndication formats that
cannot be similarly protected may be inappropriate for use with this mechanism if security
services are required. 

The security considerations should also address the utility of secure transport (e.g., IPsec) or
client authentication at the application layer.  If an application's security requirements can not
be met by signing or encrypting all or part of a feed, then these would seem the logical
mechanisms to apply.

[Ballot discuss]
The opening paragraph in the Security Considerations section is misleading.  It states:

  Feeds using this mechanism have the same authentication and channel
  security concerns as explained in Atom [RFC4287].

First, the word "channel" never appears in RFC 4287.  I suspect that the authors are referring
to the XML encryption mechanism in 4287, but that mechanism protects a feed rather than
the entire channel.  (To me, "channel security" implies all the communications between the
two parties are protected.  This secures communications in a single direction.)

In addition, based on my limited  understanding of their XML formats, I believe that a logical
feed may include a mixture of encrypted or unencrypted data, signed and unsigned data.  Is
there any guidance for atompub servers regarding selective signing or encryption of the feed
or entry???  This guidance might be different for the different classes of feeds...

I would suggest replacing the first sentence with a paragraph stating this specification assumes
that encryption or authentication security services are obtained by encrypting or signing the
feed, as descrribed in RFC 4287.  Other services are out of scope, and syndication formats that
cannot be similarly protected may be inappropriate for use with this mechanism if security
services are required. 

The security considerations should also address the utility of secure transport (e.g., IPsec) or client authentication at the application layer.  If an application's security requirements can not be met by signing or encrypting all or part of a feed, then these would seem the logical mechanisms to apply.

[Ballot discuss]
The opening paragraph in the Security Considerations section is misleading.  It states:

  Feeds using this mechanism have the same authentication and channel
  security concerns as explained in Atom [RFC4287].

First, the word "channel" never appears in RFC 4287.  I suspect that the authors are referring to the XML encryption mechanism in 4287, but that mechanism protects a feed rather than the entire channel.  (To me, "channel security" implies all the communications between the two parties are protected.  This secures communications in a single direction.)

In addition, based on my limited  understanding of their XML formats, I believe that a logical feed may include a mixture of encrypted or unencrypted data, signed and unsigned data.  Is there any guidance for atompub servers regarding selective signing or encryption of the feed or entry???  This guidance might be different for the different classes of feeds...

I would suggest replacing the first sentence with a paragraph stating this specification assumes that encryption or authentication security services are obtained by encrypting or signing the feed, as descrribed in RFC 4287.  Other services are out of scope, and syndication formats that cannot be similarly protected may be inappropriate for use with this mechanism if security services are required. 

The security considerations should also address the utility of secure transport (e.g., IPsec) or client authentication at the application layer.  If an application's security requirements can not be met by signing or encrypting all or part of a feed, then these would seem the logical mechanisms to apply.

[Ballot discuss]
The opening paragraph in the Security Considerations section is misleading.  It states:

  Feeds using this mechanism have the same authentication and channel
  security concerns as explained in Atom [RFC4287].

First, the word "channel" never appears in RFC 4287.  I suspect that the authors are pointing to the encryption mechanisms in 4287 ias channel security, but that mechanism protects a feed rather than the entire channel.  (To me, "channel security" implies all the communications between the two parties are protected.  This secures communications in a single direction.)

In addition, based on my limited  understanding of their XML formats, I believe that a logical feed may include a mixture of encrypted or unencrypted data, signed and unsigned data.  Is there any guidance for atompub servers regarding selective signing or encryption of the feed or entry???  This guidance might be different for the different classes of feeds...

I would suggest replacing the first sentence with a paragraph stating this specification assumes that encryption or authentication security services are obtained by encrypting or signing the feed, as descrribed in RFC 4287.  Other services are out of scope.  Syndication formats that cannot be similarly protected may be inappropriate for use with this mechanism if security services are required. 

The security considerations should also address the utility of secure transport (e.g., IPsec) or client authentication at the application layer.  If an application's security requirements can not be met by signing or encrypting all or part of a feed, then these would seem the logical mechanisms to apply.

[Ballot discuss]
The opening paragraph in the Security Considerations section is misleading.  It states:

  Feeds using this mechanism have the same authentication and channel
  security concerns as explained in Atom [RFC4287].

First, the word "channel" never appears in RFC 4287.  I suspect that the authors are pointing to the encryption mechanisms in 4287 instead, but that mechanism protects a feed rather than the entire channel.  To me, "channel security" implies all the communications between the two parties are protected.  This secures communications in a single direction.

In addition, based on my limited  understanding of their XML formats, I believe that a logical feed may include a mixture of encrypted or unencrypted data, signed and unsigned data.  Is there any guidance for atompub servers regarding selective signing or encryption of the feed or entry???  This guidance might be different for the different classes of feeds...

I would suggest replacing the first sentence with a paragraph stating this specification assumes that encryption or authentication security services are obtained by encrypting or signing the feed, as descrribed in RFC 4287.  Other services are out of scope.  Syndication formats that cannot be similarly protected may be inappropriate for use with this mechanism if security services are required. 

The security considerations should also address the utility of secure transport (e.g., IPsec) or client authentication at the application layer.  If an application's security requirements can not be met by signing or encrypting all or part of a feed, then these would seem the logical mechanisms to apply.

IANA Last Call Comment:

Upon approval of this document, IANA understands that
there is a single action that needs to be completed.

In the link relations registry, located at:

http://www.iana.org/assignments/link-relations.html

two new values will be added to this registry:

prev-archive which will point to a file that contains:

Attribute Value: prev-archive
Description: A URI that refers to the immediately
preceding archive document.

Expected display characteristics: none
Security considerations:
    See [ RFC-nottingham-atompub-feed-history-08.txt ]

and

next-archive which will point to a file that contains:

Attribute Value: next-archive
Description: A URI that refers to the immediately
following archive document.

Expected display characteristics: none
Security considerations:
  See [ RFC-nottingham-atompub-feed-history-08.txt ]

IANA understands that this is the only IANA Action
required upon approval of this document.

This document can't be progressed as is.  It's got examples including RSS, but there's no reference to RSS, which would be difficult anyhow as there's no known stable way to refer to a version of RSS.  I'm marking this as "dead" until I get a plan from the author, either a greatly revised draft or a way to refer to an RSS version.