Hi David,
thanks for your review. Before I comment on individual parts let me
explain how we got here:
- RFC 2731 is an Informational RFC describing how to put Dublin Core
metadata into HTML, and was published almost 10 years ago.
- It hasn't been touched since then.
- The Dublic Core Metadata Initiative took over further development a
few months later
(<http://dublincore.org/documents/2000/08/15/dcq-html/>), and has
maintained this specification since. Note that this isn't a different
format but just mainly maintenance work, keeping it up-to-date with
current W3C specs.
The current situation causes people to potentially implement RFC 2731,
and not being aware of the newer work. This has happened to me, and thus
I decided that something needs to be done.
I asked the DCMI people whether they were interested in *updating* RFC
2731, and it turned out they aren't (and it would make little sense to
publish this in two places).
I also asked the IESG for feedback on how to update the status of an
existing RFC in the RFC Index, and the answer I got was that the easiest
approach is to replace it with a newer RFC saying what needs to be said.
BTW: It's good to have this discussion right now, as we may have to do
something similar with a much more important RFC (2854) soonish.
More comments in-line:
David Harrington wrote:
Hi,
I find the title irritating. I had to go open the draft to know what
it was obsoleting.
I thought the title says what it's obsoleting.
Reading the abstract, I find that the draft proposes declaring RFC2731
Historic (not Obsolete)
So the title is actually misleading.
It is, and sorry for that.
As far as I recall, I borrowed structure and text from RFC 4794 ("RFC
1264 Is Obsolete", moving RFC 1264 to *historic*). (Steal with Pride).
That RFC was written by Bill Fenner (a former AD), so I assumed he knows
what to do.
That being said, I really do not care about this detail, as long as the
outcome is that the RFC Index points consumers of RFC 2731 to the place
where the specification really is maintained today.
But wait. According to the heading, if approved, this draft will
obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you
do both simultaneously?)
Sort of. RFC 2731 would be classified as "Historic", and be obsoleted by
this spec. At least this is what happened in the example above.
In actuality, what this draft is doing is transferring responsibility
for further development of the "Encoding Dublin Core Metadata in HTML"
to Dublin Core Metadata Initiative.
No, it does not. The responsibility has been transferred long ago; it
just documents that fact.
Neither RFC2731 nor this draft make it clear whether RFC2731 was a
snapshot of work that was done by the Dublin Core Metadata Initiative
and simply published as an Informational draft to inform the IETF, or
whether RFC2731 was contributed to the IETF with the intent of
developing an IETF standard (and subsequently failed). There is almost
no discussion of why RFC2731 is being declared obsolete/Historic and
why further development has moved to the Dublin Core Metadata
Initiative.
I don't have that information. I would support adding it, but I don't
think the reasons are really important.
I had occasion to coordinate the transfer of responsibility from the
IETF to IEEE for some work, and had to spend significant effort
working through the copyright issues and the migration issues
(RFC4663). The work being transferred in RFC4663 is an IETF standard,
whereas RFC2731 is only Informational, so that could make a lot of
difference, but there is simply no discussion at all of copyright
issues and migration issues. And the reasons why RFC2731 is not still
considered valid (just an earlier version), or why this step to
declare the RFC Historic is being done are extremely light. Is it to
prevent it being used because this old version and the updated work
cannot coexist? or do we just not like this one any more?
Well, it's not up-to-date anymore. Don't use it. Look elsewhere.
If this means that moving it to "Historic" is the wrong thing, I'll be
happy to remove that part.
Is it because the effort to standardize failed? (Did the Initiative
want to keep editorial control, and when they found out they couldn't
if it was standard, they took their ball and went home? Is this draft
to provide a pointer to the Initiative because providing this pointer
It's about telling readers where they find the current specification.
The politics why it's not an IETF spec anymore are certainly
interesting, but IMHO not essential for documenting what is clearly the
situation today.
in an RFC sort of implies that IETF endorses the Initiative as the SDO
for setting a standard(?) for this metadata? (I notice there are
Editorial notes to remove some text; are all mentions of the
Initiative being removed? I couldn't tell the scope of the Editorial
note. It might be better to see an updated version that has been
cleaned up, so there are no misunderstandings about what should be in
the published RFC.)
I'm not sure what you're trying to say. Those sections marked "(to be
removed by RFC Editor before publication)" should be removed. This is
common practice when publishing Internet Drafts.
Or are you saying that some of this material, potentially Appendix A,
should stay in?
RFC2731 contains perl code. They are published with this text that
appears to be a license: "They may be
taken and freely adapted for local organizational needs, research
proposals, venture capital bids, etc."
If RFC2731 is obsoleted, does this in any way affect the license and
the legal rights of implementers of RFC2731? This is not discussed.
And I don't think it needs to discussed. An RFC obsoleting another RFC
doesn't change any license that came with the previous version.
I find this draft not very satisfying because it simply ignores so
much.
In security considerations sections, it is acceptable to say "hey, we
considered this and reached the conclusion that authentication and
authorization and other security features are not needed." It is not
considered acceptable to simply omit any discussion of the security
considerations.
This is a purely administrative RFC. It doesn't define any protocol or
format. It just says: "look somewhere else for up-to-date versions".
That really does not require Security Considerations.
I don't want new boilerplates, but there are a bunch of issues related
to this document that are simply not discussed. I think this document
should include (very small) sections that reflect that copyright
issues have been considered; that authors rights in RFC2731 have been
I disagree that there are copyright considerations that need to be
considered. This document doesn't change what RFC 2731 says; it just
updates the RFC Index so that readers can find out about newer work.
considered; that migration issues for implementers of RFC2731 have
In the meantime I have verified that this document has the support of
the original author John Kunze, and have added him as Co-Author, which
should address this point (this is an unpublished change for now, as we
are in LC).
been considered; that licensing issues for the contained code have
That would be a requirement for the DC-HTML specs, and as far as I can
tell, they have. In *particular*, this spec highlights a change
implementers need to be aware of (so yes, it has been considered).
been considered. None of this has been documented, so a reader cannot
They haven't been considered, nor do I think they need to.
know whether these have been considered and not documented, or simply
overlooked.
I do not think this document is ready for publication as an RFC.
I think the issue of historic-vs-obsolete can be resolved based on the
feedback we're collecting here. I'm not attached to any particular way
of doing this, as long as the end result is that the combination of RFC
2731 and RFC Index isn't misleading anymore.
Adding more historic information would be nice, but requires somebody
involved in this transition that happened almost ten years ago to
provide it. Furthermore, I don't think it's really relevant for what the
proposal intends to achieve.
With respect to Copyrights and Licensing of code in RFC 2731: I disagree
that this spec needs to address this; in particular I'm pretty sure
there's nothing that needs to be addressed. But then, I'm not a lawyer.
BR, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf