On Jan 3, 2008, at 12:35 PM, Bill de hOra wrote:
1. deleted-entry is now part of the Atom namespace
"The Atom namespace is reserved for future forward-compatible
revisions
of Atom." RFC4287, 6.2.
The rfc-editor should have picked this up.
Since it's just an Internet-Draft, neither IANA nor the RFC Editor
have had a chance to review the proposed namespace. I'm not involved
officially either because I haven't been asked to sponsor this, nor
is it a work item of a WG I advise.
Picked what up? The rfc-editor is not involved in the
publishing of
I-D's. If this I-D is published as a Standards Track RFC, it would
specifically indicate that it is an update to RFC 4287 and would
qualify
as a "forward-compatible revision of Atom". I believe that it's
up to
the Area Director to determine whether or not to allow individual
submissions such as this to proceed along that route or whether
a WG is
required.
You seem to be assuming this won't get implemented before it gets to
standards track. Until that time, I suggest you revert the
namespace. Or
make it clear that you intend to use this to create a forward
compatible
revision of Atom.
Until (and if) it gets to the standards track, the deleted-entry
element
is no different than any other unknown extension element an
application
may add to a feed; conformant implementations are required to
ignore it
and validators will be right to point it out as a validation error.
[cc'd to the AD]
I still read the list, though often a few days behind. My
(individual hat on) guess at interpreting the phrase "future forward-
compatible revisions" is that the authors preferred to limit the core
namespace to core features and not to optional extensions; otherwise
there would be text about use by standards-track vs. Informational or
Experimental extensions (or even non-IETF extensions).
I am not on call here to make a final decision as the document's
still a draft. But if it fell to me to decide due to lack of a WG,
I'd check the intent with the authors and see if consensus could be
gauged on this mailing list. Lack of clear consensus or somebody
responsible to gauge consensus (a WG chair) might well stall
documents like this one over any open issue.
BTW, Informational RFCs extending Atom can get published through the
RFC Editor as Independent submissions without IETF review (and the
disclaimer indicates these are not IETF documents), again because
there's no WG for the independent work to conflict with. Such
independent submissions could not update or revise the Atom RFC and
thus I'm fairly confident those documents could not use the Atom core
namespace.
Lisa
[.] As an even more pedantic digression, the word "updates", as in
"this draft updates RFC4287", has been the cause of Talmudic debate
in the IESG and elsewhere. It's used sometimes to indicate that a
draft describes an extension to a previous document, even when the
extension is completely optional. Other extensions omit the
"updates" marker on the logic that if an extension is purely
optional, then it doesn't have to be read in order to implement the
older spec, and marking the older spec as "udpated by" the newer spec
merely adds confusion. I believe there's solid agreement that when a
new spec makes changes in the behavior of the older spec, then it has
to use either "updates" or "obsoletes". Note that RFC2616 is not
updated by RFC2617, while it is updated by RFC2817, and I haven't
looked whether there's really solid logic behind that difference in
treatement.
