Subject: [apps-discuss] Status of draft-ietf-appsawg-media-type-suffix-regs

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Jul 2012 12:31:52 -0700

Apps folks,

Tony has posted a new version of this draft that appears to address most
comments.  Please review it and comment, especially if you provided
comments previously.

Some time ago, Mark Nottingham posted comments that have not been
thoroughly addressed:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html

As document shepherd, it seems to me that the absence of concurring opinion
in the archive suggests that Mark is alone in his concerns, and that those
concerns are overshadowed by the existence of media type suffixes and the
need to more clearly document them.  However, in the interests of tying up
loose ends, I'd like the working group to consider his questions once more
before sending the document to the IESG.

Therefore: If you agree with some or all of Mark's concerns, please post
your thoughts here in the next two weeks.  At the end of the Vancouver
meeting, we will determine how to proceed based on the response to this.
Also, please post if you disagree, with reasons.  Silence will be taken to
mean the working group is okay with the document going forward as-is.

Thank you,

-MSK, APPSAWG co-chair

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 18 Jul 2012 22:03:13 +0200

On Jul 18, 2012, at 9:31 PM, Murray S. Kucherawy wrote:

> Apps folks,
> 
> Tony has posted a new version of this draft that appears to address most comments.  Please review it and comment, especially if you provided comments previously.
> 
> Some time ago, Mark Nottingham posted comments that have not been thoroughly addressed: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html

Thanks for bringing this up.

> 
> As document shepherd, it seems to me that the absence of concurring opinion in the archive suggests that Mark is alone in his concerns, and that those concerns are overshadowed by the existence of media type suffixes and the need to more clearly document them.  However, in the interests of tying up loose ends, I'd like the working group to consider his questions once more before sending the document to the IESG.
> 
> Therefore: If you agree with some or all of Mark's concerns, please post your thoughts here in the next two weeks.  

I agree with Mark's concern about the existence of real use cases that are addressed by this. Can the authors provide some examples to illustrator the point?

All the message processing stacks I have worked with dispatch on the full media type identifier. Might be that the spec is YAGNI ?

Having said that, I see one potential case: intermediaries (needing no knowledge of the application semantics) that turn payload running through them into general data structures:

Search for 'entity introspection' in http://jalg.net/2011/11/esi-facelift/ 

Jan

> At the end of the Vancouver meeting, we will determine how to proceed based on the response to this.  Also, please post if you disagree, with reasons.  Silence will be taken to mean the working group is okay with the document going forward as-is.
> 
> Thank you,
> 
> -MSK, APPSAWG co-chair
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 22:12:48 +0200

On 2012-07-18 22:03, Jan Algermissen wrote:
> ...
> ...

-> <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06012.html>

I encourage to also read the *responses* to Mark's mail :-)

Best regards, Julian

---

From: Ned Freed <[email-masked]>
Date: Wed, 18 Jul 2012 14:46:23 -0700 (PDT)

> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05998.html

Those comments were and are out of order and I see no point in responding to
them. Questioning the utility of the +format suffixes was a matter to be dealt 
when the media type registration procedure was updated to define the registry.
All the current document does is seed the already registry that is already
specified and approved.

If Mark has questions about or objections to specific prefixes being
registered, or to the contents of those registrations, he needs to separate
those out and represent them as such.

Futhermore, if you look in the archives, the entire topic of having suffixes
has in fact been discussed, both in the process leading up to the approval of
the revised registration document as well as in the original discussions about
the XML-MIME RFC. I see no point in rehashing those discussions again.

> need to more clearly document them.

This document doesn't do that. All it does is seed the registry. As I see it,
the only comments that are in order are about the content of those registration
entries. 

> However, in the interests of tying up

> mean the working group is okay with the document going forward as-is.

In case it isn't obvious: I disgree with his concerns, but even if I didn't
I fail to see how they are relevant at this point.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2012 11:17:31 +1000

On 19/07/2012, at 7:46 AM, Ned Freed wrote:

> them.

"Out of order"? Seriously? Last I checked, you don't Chair this WG.

> Questioning the utility of the +format suffixes was a matter to be dealt 

I did question it in my apps area review of the registration procedure document <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05837.html>:

"""
* Section 4.2.8 introduces structured suffixes. These may be very popular, but I don't see any description of their value, nor appropriate vs. inappropriate use (and I suspect there are many opportunities for abuse here). Also, I suspect that having many of these will be very counterproductive, and therefore wonder whether DE is the appropriate registry policy here.
"""

You subsequently dodged the question <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05857.html>:

"""
This document didn't introduce them; RFC 3023 did. See above for why the sort
of text you're asking for doesn't belong here.

As for this being the right registration process, that's a consensus issue, not
a document editing issue, and certainly not at this stage. I've heard no
objections other than this one, and if past experience is any indication,
worries about "opening the floodgates" have rarely proved to be well founded.
If fact we usually end up with the opposite: Overly onerous processes that
prevent people from getting things done.
 
Anyway, if you want to try and get consensus that the current process is
insufficiently restrictive feel free to do so. But until such a consensus
emerges I'm not going to change it.
"""

The Chairs chose not to pursue it (I considered the issued raised as part of the review). I had other things to do. I posted the follow message only to get *some* sense of why we're doing this, and what constraints are around it. 

> those out and represent them as such.

That's beside the point, and plainly NOT the issue at hand.

> the XML-MIME RFC. I see no point in rehashing those discussions again.
 
And you could have pointed me to those discussions, but chose not to. You could have even suggested I look for them, but chose not to do so.

> the only comments that are in order are about the content of those registration

My question wasn't specific to that document, it was reiterating the concern I expressed earlier, and the fact that it hadn't been addressed, as evidenced by the later document. 

> I fail to see how they are relevant at this point.

A reasoned reply (or pointers) would be nice, instead of what looks like stonewalling and diversionary tactics.

I'm fine if no one else is concerned about this, but I don't think it's unreasonable for me to raise my concerns and ask a few questions. 

--
Mark Nottingham   http://www.mnot.net/

---

From: Ned Freed <[email-masked]>
Date: Wed, 18 Jul 2012 18:43:49 -0700 (PDT)

> "Out of order"? Seriously? Last I checked, you don't Chair this WG.

You need to brush up on your understanding of basic rules of committee
procedure if you believe the Chair is the only one who can call something out
of order.

If we followed Robert's Rules here I would have called it a point of order.
Points of order can be raised by anyone. But we're less formal, so I didn't 
use that term.

That said, the Chairs are of course free to overrule me on this point. But in
that case I'll flip the question around: Suppose your objection(s) regarding
the appropriateness of the use of +suffixes were to be sustained. What then?
How can those objections possibly be addressed in a document that does nothing
but register the initial set of suffixes?

That's why your objections are out of order. And again, if you care to rephrase
them as objections to specific registrations, or to the content of those
regitrations, that would make perfect sense for the present document.

> I did question it in my apps area review of the registration procedure
> document <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05837.html>:

And your concerns were noted, and addressed to the extent we believed was
necessary and appropriate. You subsequently chose not to pursue those
objections further. That was your call. And now the document has been approved.

> You subsequently dodged the question
> <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg05857.html>:

I don't care if I set the question to tap dancing with a collection of angels
on the head of a pin. The only relevant point is that you did not object
further, the IESG has considered the document along with the reviews it
received and approved it, and the document defining the mechanism and procedure
you are now objecting to is in the RFC Editor queue.

This is a standards process. Not a debating society where nothing is ever
settled and every issue can be reopened on a whim. We have to have closure, and
this particular process has gone on far too long as it is.

And if you're regretting not saying more at an earlier point in the process,
you should know you're hardly alone in having this happen to you. I've lost
track of the number of times I've let something slide, or not reviewed
something carefully enough, or not implemented something in a timely enough
fashion, only to discover when later reviewing the resulting  RFC that it
contains something I consider to be egregiously wrong, or broken, or stupid, or
whatever. (It happened to me today, as a matter of fact. And it's even
happened when I coauthored the document in question. *cough* RFC 2231 *cough*

I kick myself about this sort of stuff all the time. But what I don't do is try
an unring bells that have already rung.

And finally, I also try not to let the best be the enemy of the good. Suppose
for a moment that media type suffixes, their clear popularity in actual
use notwithstanding, have no real value. Is there a significant downside
to having them? Or alternately, if the rules and process for them is not
the best, is that going to cause harm?

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 19 Jul 2012 12:34:01 +1000

> Points of order can be raised by anyone. But we're less formal, so I didn't 

My rule of thumb is that when you refer to things like Roberts' Rules, something has already failed. Anyway.

> regitrations, that would make perfect sense for the present document.

Where have you seen me object to anything on this topic, Ned? At what point did I raise an objection -- please point to it?

I asked a few questions and expressed some concern. Kindly stop misreading my intent.

> this particular process has gone on far too long as it is.

Oh, absolutely. I'm just a bit bewildered by the defensiveness and aggression instigated by a couple of questions.

> an unring bells that have already rung.

You're reading a LOT into my motivations, and I'd ask you to stop. 

My concerns were first about the technical issues at hand, and later that my (timely) comments seemed not to be addressed. 

> the best, is that going to cause harm?

I suppose that's a response, of sorts.

---

From: Ned Freed <[email-masked]>
Date: Sat, 21 Jul 2012 09:08:12 -0700 (PDT)

> something has already failed. Anyway.

Which is exactly my point: Something *has* failed.

> Where have you seen me object to anything on this topic, Ned? At what point
> did I raise an objection -- please point to it?

Fine. Let's call it them questions then. Or if you prefer, concerns. But
regardless of what you call it, it is still out of order for the current last
call.

> I asked a few questions and expressed some concern. Kindly stop misreading my

Well, it was never *my* intention to read anything into your intentions here,
because they are frankly irrelevant to the matter at hand. I only care about
the effects your questions/concerns are having on the process.

> instigated by a couple of questions.

I calls them as I sees them. And what I see here are some out of order
questions/concerns holding up the process for a document that needs to be
approved before a document I coauthored can be published.

If you don't think that warrants the tone I've used, then we'll just have to
disagree about that.

> You're reading a LOT into my motivations, and I'd ask you to stop.

Please note the conditional in the first sentence. This doesn't apply to you,
then it doesn't apply to you.

> My concerns were first about the technical issues at hand, and later that my
> (timely) comments seemed not to be addressed.

Really? Your questions/concerns are from:

Your questions/concerns are about the appropriateness of using media type
suffixes in general. The paragraph you cited in the present draft is just
collecting the principles behind suffix use in one place, which seemed to us to
be a good thing to do when you're seeding the registry. As such, any comments
on it are effectively about the text in the registration procedure document it
is based on, or section 7 of the RFC 3023 where this originated.

I see nothing in your comments that's specific to the suffixes the document in
last call registers. Indeed, the title of your message was "Questions about
Structured Syntax Suffixes (SSS)", not "Questions about the contents of the
initial registry" or anything similar.

I suppose one way to address this would be to sidestep it by dropping the "when
to use" paragraph from the present document. I would have no objection to doing
that if it will make people happier, although I think that capturing that
information here is useful, although it is clearly secondary to the purpose of
the document. But this is Tony's call, not mine.

				Ned

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 Jul 2012 10:37:49 +1000

> If you don't think that warrants the tone I've used, then we'll just have to

I think there would have been a lot more light and less heat without the tone you've used.

> initial registry" or anything similar.

Indeed. As far as I can see, the horse has well and truly bolted. 

> the document. But this is Tony's call, not mine.

I don't think any changes, or blocking, the current document will help; my issues were always with the media type registry doc and the process around it.

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Jul 2012 19:17:45 +0100

On 18/07/2012 20:31, Murray S. Kucherawy wrote:
> Apps folks,
>
> Tony has posted a new version of this draft that appears to address 
> most comments.  Please review it and comment, especially if you 
> provided comments previously.

I am mostly happy with draft-ietf-appsawg-media-type-suffix-regs-02. I 
have noticed that the new text about fragment identifier handling was 
added to definitions of XML related suffixes (good), +zip (?) and not to 
+ber/+der. I would like to have a discussion about why +zip was included 
but +ber/+der weren't.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jul 2012 20:26:43 +0200

> +ber/+der. I would like to have a discussion about why +zip was included

Also, I was assuming that we define "+gz" or "+gzip", as this appears to 
have a proper use case (use of "svz" content inside data URIs using 
base64 encoding).

Best regards, Julian

---

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Jul 2012 12:12:21 -0700

There is now a "First Public Working Draft" of the W3C TAG document on "Best Practices for Fragment Identifiers and Media Type Definitions". Although late in the process (and still a 'work in progress', until it reaches W3C 'recommendation' status), perhaps it might be helpful, if only as an informational reference for possible future guidelines.

============

The [W3C] Technical Architecture Group (http://www.w3.org/2001/tag/  ) has published the First Public Working Draft of Best Practices for Fragment Identifiers and Media Type Definitions (http://www.w3.org/TR/2012/WD-fragid-best-practices-20120726/). Fragment identifiers within URIs are specified as being interpreted based on the media type of a representation. Media type definitions therefore have to provide details about how fragment identifiers are interpreted for that media type. This document recommends best practices for the authors of media type definitions, for the authors of structured syntax suffix definitions (such as +xml), for the authors of specifications that define syntax for fragment identifiers, and for authors that publish documents that are intended to be used with fragment identifiers or who refer to URIs using fragment identifiers.