Subject: RE: Last Call: draft-reschke-rfc2731bis (RFC 2731 is Obsolete) toInformational RFC

From: "David Harrington" <[email-masked]>
Date: Wed, 9 Sep 2009 11:37:28 -0400

Hi,

I find the title irritating. I had to go open the draft to know what
it was obsoleting. 

Reading the abstract, I find that the draft proposes declaring RFC2731
Historic (not Obsolete)
So the title is actually misleading. 

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?)

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. 

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 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? 

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
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.)

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.

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.

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
considered; that migration issues for implementers of RFC2731 have
been considered; that licensing issues for the contained code have
been considered. None of this has been documented, so a reader cannot
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.

David Harrington
[email-masked]
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Wednesday, September 09, 2009 9:31 AM
> To: IETF-Announce
> Subject: Last Call: draft-reschke-rfc2731bis (RFC 2731 is 
> Obsolete) toInformational RFC
> 
> The IESG has received a request from an individual submitter 
> to consider 
> the following document:
> 
> - 'RFC 2731 is Obsolete '
>    <draft-reschke-rfc2731bis-02.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and
solicits
> final comments on this action.  Please send substantive 
> comments to the
> [email-masked] mailing lists by 2009-10-07. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case,
please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-reschke-rfc2731bis-02.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=vie
w_id&dTag=18624&rfc_flag=0
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Sep 2009 19:40:46 +0200

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:

> I find the title irritating. I had to go open the draft to know what

I thought the title says what it's obsoleting.

> 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.

> obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you

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.

> to Dublin Core Metadata Initiative. 

No, it does not. The responsibility has been transferred long ago; it 
just documents that fact.

> why further development has moved to the Dublin Core Metadata

I don't have that information. I would support adding it, but I don't 
think the reasons are really important.

> 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.

> 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.

> cleaned up, so there are no misunderstandings about what should be in

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?

> 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.

> considered acceptable to simply omit any discussion of the security

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.

> 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.

> 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

---

From: SM <[email-masked]>
Date: Wed, 09 Sep 2009 22:49:11 -0700

Hi David,
>obsolete RFC2731. Which are we doing Historic, or Obsolete? (can you

There is a subtlety between Obsolete and Historic.

>if it was standard, they took their ball and went home? Is this draft

That's an interesting question.

RFC 5013 has an Informative reference to RFC 2731.

>the legal rights of implementers of RFC2731? This is not discussed.

This is only a reclassification.  The RFC will still be there.  In my 
opinion (this is not legal advice), it does not affect how the code 
can be used.

>issues have been considered; that authors rights in RFC2731 have been

It's problematic to discuss copyright issues in the document.

>know whether these have been considered and not documented, or simply

It's the same stance as for "IPR".

You brought up valid concerns.  I would have some apprehension to put 
them in a draft.

At 10:40 09-09-2009, Julian Reschke wrote:
>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).

I would not steal that RFC as its topic is different from the one you 
are writing about. :-)

>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.

You could say something along those lines in the Security 
Considerations section.

Regards,
-sm

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Sep 2009 09:05:52 +0200

SM wrote:
> ...
> ...

I note that RFC 5013 has a reference to RFC 2731, but that reference 
never is used in the prose.

> ...
> You could say something along those lines in the Security Considerations 
> section.
> ...

Agreed.

BR, Julian