- From: Sam Ruby <rubys@intertwingly.net>
- Date: Mon, 24 Aug 2009 07:20:57 -0400
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: "public-html@w3.org WG" <public-html@w3.org>, Larry Masinter <masinter@adobe.com>
Julian Reschke wrote: > Maciej Stachowiak wrote: >> >> On Aug 21, 2009, at 1:23 AM, Julian Reschke wrote: >> >>> Maciej Stachowiak wrote: >>>> ... >>>> An RFC can be moved to "Historic" status (the formal term for >>>> "obsolete") without the need for a superseding RFC. See RFC2026 "The >>>> Internet Standards Process", particularly sections 4.2.4 and 6.4. >>>> ... >>> >>> It needs a Standards Action. >>> >>> I'm in the process of doing this with RFC 2731, asked the IESG for >>> advice, and got the recommendation to draft a document that would >>> replace RFC 2731. >> >> Would you be willing to ask the IESG for advice on RFC 2854, in light >> of HTML5 containing an updated registration? Perhaps their opinion >> will be different, or perhaps not, in which case someone needs to >> draft a superseding document. > > I'll do that once we have made a decision not to simply revise RFC 2854, > which seems to be by far the simplest approach. > > BR, Julian > > PS: and yes, if we want to do that, and Dan and Larry are ok with that, > I'd do the editorial work on it. Issue 53 is simply "Need to update media type registrations". Outside of Larry, this part seems uncontroversial. As to Larry, it simply seems to me a matter of question asked and answered[1]. Larry is welcome to correct me if I am misunderstanding. There are some technical details[2], but it seems to me that Ian is willing to accept bug reports on these. The issue could be reopened should it turn out that Ian marks one or more of these bugs as WONTFIX, but we only would need to deal with that if it actually occurred and everything I see indicates that it will not. So, all that remains is the work. From what I can see in section 13, the work has been done. Other specs do it this way (in fact, I was associated with Atom, which is in the IETF and it did it this way -- see section 7 of RFC 4287), and it doesn't seem to me be a particularly egregious approach, so frankly I'm struggling to try to figure out what the real issue is here. Julian, you indicated that the IETF recommended an approach, and you were willing to do the work. I fully appreciate that, but apparently that recommendation was made without the knowledge that the work is already done. I guess what I am asking here is: 1) Is there some significant technical issue with the approach that has been taken, or is this simply a matter of bug reports that have yet to be written? 2) Is there reason to believe that the IESG would not accept the work that has already been done? If not, I am having trouble understanding why ripping out this work and starting over would be simpler. If there are no technical issues (modulo a few bug reports, and from what I can see, there is an agreement that these are bugs), and what currently exists is workable, I'm inclined to recommend closing this issue. - Sam Ruby [1] http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.html [2] http://lists.w3.org/Archives/Public/public-html/2009Aug/1138.html
Received on Monday, 24 August 2009 11:21:39 UTC