ietf
[Top] [All Lists]

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

2013-10-15 03:55:35


--On Monday, October 14, 2013 14:45 -0500 Pete Resnick
<presnick(_at_)qti(_dot_)qualcomm(_dot_)com> 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.