Re: Last Call: Adding a fragment identifier to the text/csv media type(see <draft-hausenblas-csv-fragment-06.txt>)

[John C Klensin <[e-mail]>]

--On Monday, October 14, 2013 14:45 -0500 Pete Resnick
<[e-mail]> wrote:

> I don't know that everyone is really understanding the request
> that is being made here. It is a bit unusual.
> 
> RFC 4180 <http://tools.ietf.org/html/rfc4180> contains the
> current registration for text/csv. That registration has the
> "Change Controller" as "IESG", which is to say it's a
> registration from an IETF document. Barring any change, that
> registration would remain exactly as it is (including its
> current Security Considerations).
>...
> This Last Call is to find out if the IETF is OK with a
> non-IETF document updating an IETF registration. If the answer
> is "no", then we leave the 4180 registration in place, or we
> tell the ISE that draft-hausenblas is not conforming to IETF
> processes and that we want it to be an IETF-stream document.
> If the answer is "yes", we go ahead with the registration
> change based on whatever the ISE publishes. We can send
> comments to the author and to the ISE asking for changes, but
> it's not an IETF document; IETF consensus is not required and
> the ISE can publish it anyway.
>...

In a slightly broader interpretation of that question, I believe
that having Independent (or even IAB) stream documents modify
registrations that are required, either by the registration
procedure or the registration itself, to be under IETF change
control is a bad idea.  If we don't like that constrain, we
should modify the registration, not conduct odd Last Calls.  I
would strongly support processing this document in the IETF
Stream as an individual submission (and, while that slips over
into the substantive part, approving it for publication and
modification of the registration on that basis).  

My reasoning is that, while the change seems fine, the precedent
seems atrocious.  If this is approved via Independent Stream
publication and the next case that comes along is, unlike this
one, generally hated by the community, the amount of
hair-splitting required to deny that one having approved this
one would be impressive.. and bad for the IETF.

Of course, the ISE could go ahead and publish this document and
the IESG could block the registration, leading to a confusing
situation.  I hope we don't have to go there.

       john

p.s. W3C is circulating a draft charter for a WG that might
affect CSV on the web.  Because having a hard-to-change
Informational RFC and IANA registration that was inconsistent
with W3C recommendations would be a generally bad idea, some
coordination may be in order, especially to verify that the
current draft is not an end run around W3C efforts.