I think we need to go a little more slowly given the magnitude of change
proposed in these last five days (I'm not quite back from vacation last
week, but this seems worth addressing now).
I don't know how long you've been participating in the DCMI community,
but RFC 2731  was originally intended to reach out to the larger IETF
community. At the moment, it also offers a rather briefer and simpler
introduction to HTML encoding than DC-HTML , which also ends with:
"This document draws on the existing recommendations for
encoding Dublin Core metadata in HTML, including ..."
Shouldn't this spec be the first place for DCMI to assert that other
specs are obsolete (assuming that's the case)?
In any case, another approach to reconciling  and  is to revise the
old RFC and re-issue it under a new number that obsoletes the old RFC.
This might work if  has sufficient pedagogical value and isn't too
difficult to update.
--- On Wed, 27 May 2009, Pete Johnston wrote:
> > I recently noticed that <http://dublincore.org/documents/dc-html/>
> > obsoletes RFC 2731 (<http://tools.ietf.org/html/rfc2731>),
> > but readers who aren't aware of that are likely not to find
> > out, as RFC 2731 has not been obsoleted.
> > I asked the IESG for advice, and they told me the best way to
> > handle this is to publish a new RFC, obsoleting RFC 2731, and
> > stating that maintenance has moved to DCMI.
> > Here's a proposed draft:
> > Feedback appreciated,
> I do think this is the message we want to convey, and if the most
> appropriate way of conveying it is to obsolete the RFC, I would support
> this approach.
> If I understand the procedure correctly, the proposed draft text would
> take the form of a new RFC (number to be determined), referring back to
> RFC 2731, and the text of RFC 2731 would remain in place, with the
> addition of an indication that its status was "Historic" and that it had
> been obsoleted by the new doc? Have I got that right, Julian?
> Re the proposed text, I notice it makes a point of mentioning the
> profile attribute as a new requirement. There are some other areas where
> the conventions diverge (e.g. the use of name values like
> "DC.date.created"), but I'm not sure that the new text needs to list
> them all.
> Is there agreement that this is the right approach to take? Are there
> any objections/reasons why we shouldn't take this approach?
> Pete Johnston
> Technical Researcher, Eduserv
> [log in to unmask]
> +44 (0)1225 474323