Subject: [apps-discuss] Bilated issue with draft-ietf-appsawg-media-type-suffix-regs-02.txt: fragment identifier rules

From: Alexey Melnikov <[email-masked]>
Date: Tue, 14 Aug 2012 11:00:02 +0100

Sorry for not reporting this earlier, but after rereading the latest 
version the following bothers me:

>  For cases defined in +json, where the
>  fragment identifier resolves per the +json
>  rules, then as specified in +json.
>
>  For cases defined in +json, where the
>  fragment identifier does not resolve per
>  the +json rules, then as specified in "xxx/
>  yyy+json".
>
>  For cases not defined in +json, then as
>  specified in "xxx/yyy+json".

(And similar text for other registrations).

So, let's imagine the following sequence of events:

1) +json registered with no special rules for handling fragment identifiers.

2) later on "xxx/yyy+json" is registered that defines some special rules 
for handling fragment identifiers.

3) +json registration is updated to add some generic rules for handling 
fragment identifiers. If fragment identifier rules for "xxx/yyy+json" 
are in conflict with the new generic +json rules, implementors might get 
confused which rules apply.

Is this likely? Is this something that needs to be explicitly pointed out?

---

From: Tony Hansen <[email-masked]>
Date: Thu, 16 Aug 2012 08:48:29 -0400

On 8/14/2012 6:00 AM, Alexey Melnikov wrote:
> 2) later on "xxx/yyy+json" is registered that defines some special 
> rules for handling fragment identifiers.
>
> 3) +json registration is updated to add some generic rules for 
> handling fragment identifiers. If fragment identifier rules for 
> "xxx/yyy+json" are in conflict with the new generic +json rules, 
> implementors might get confused which rules apply.
>

Isn't this covered by the ordering specified here:

     The syntax and semantics for fragment identifiers for a specific 
"xxx/yyy+json"
     SHOULD be processed as follows:

         For cases defined in +json, where the fragment identifier 
resolves per the +json
         rules, then as specified in +json.

         For cases defined in +json, where the fragment identifier does 
not resolve per
         the +json rules, then as specified in "xxx/yyy+json".

         For cases not defined in +json, then as specified in 
"xxx/yyy+json".

The same ordering is used in all of the examples, and no one has 
commented on that ordering.

     Tony Hansen

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 16 Aug 2012 13:57:32 +0100

> Isn't this covered by the ordering specified here:

The text has prescribed ordering, yes. But my point is that your rules 
allow an updated +foo registration to retrospectively update fragment 
rules on all previously registered xxx/yyy+foo. I don't think this is right.

---

From: Tony Hansen <[email-masked]>
Date: Thu, 16 Aug 2012 09:09:11 -0400

> rules on all previously registered xxx/yyy+foo. I don't think this is 

That is true for *all* of the suffixes -- any of the underlying/foo 
registrations and any of the xxx/yyy+foo registrations can be updated at 
any time and a conflict engendered because of the update. It works both 
ways, no matter what ordering is chosen.

If I were adding a fragment identifier definition to underlying/foo, I 
would certainly want to look at the fragment identifier definitions that 
have already been identified for the various xxx/yyy+foo registrations 
and take those into consideration. Similarly, if I were adding a 
fragment identifier definition to xxx/yyy+foo, I would certainly want to 
look at the fragment identifier definitions that have already been 
identified for the underlying/foo registration and take those into 
consideration.

We could certainly add wording along these lines to the I-D, but I'm not 
sure what else can be done.

Suggestions welcome.

     Tony Hansen

---

From: Ned Freed <[email-masked]>
Date: Thu, 16 Aug 2012 07:44:51 -0700 (PDT)

> rules on all previously registered xxx/yyy+foo. I don't think this is right.

OK... Sure, an update to the registrtion of +json could conceivably change
the processing requirements for types that use the +json suffix.

Maybe I'm missing something, but how is this significantly different from any
situation where we build one standard on top of another? For that matter, the
definition of how fragment identifiers work for JSON, or perhaps even the
specification of JSON itself could conceivably change in such a way that code
changes are needed for things that process JSON-based types, irrespective of
whether there's any indication of the use of JSON in the media type name. Ditto
for XML or pretty much anything else.

It's also possible, and even likely, that the defacto handling requirements for
commonly used formats can shift over time. text/html is a particularly
egregious example, but there are many others.

Nor it is limited to media types. I seem to recall a bit of a fuss over the
location of some code points in Unicode a few years back...

Anyway, if you want to suggest some text to say that due to this dependency the
handling of fragment identifiers in +suffix registrations should be adjusted
cautiously if at all, I think that would be a good addition.

But given the present fluidity of standards regarding fragment identifier
handling and the high liklihood of further change, to say nothing of what's
actually going on in the field, I'm doubtful as to how much good it will do.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 17 Aug 2012 13:27:57 +0100

On 16/08/2012 15:44, Ned Freed wrote:
> situation where we build one standard on top of another?
It isn't. But I think the current set of ordered rules is more prone to 
"oh shit, I didn't mean to change that" situation. (See below.)
> For that matter, the
Sure.
> cautiously if at all, I think that would be a good addition.
Sure.

My primary preference is to change the order to make sure that the rules 
for xxx/yyy+foo apply first and only for cases not covered the rules for 
+foo apply. This wouldn't prevent the situation where additional rules 
are introduced in +foo which are not covered by xxx/yyy+foo, but it will 
at least keep the fragment identifier rules explicitly defined in 
xxx/yyy+foo stable.

So:
OLD:
   The syntax and semantics for fragment
   identifiers for a specific "xxx/yyy+json"
   SHOULD be processed as follows:

NEW:
   The syntax and semantics for fragment
   identifiers for a specific "xxx/yyy+json"
   SHOULD be processed as follows:

     For cases defined in "xxx/yyy+json"
     the rules specified in "xxx/yyy+json" apply
     irrespectively of whether they are
     covered by +json or not.

     For cases not defined in "xxx/yyy+json",
     then as specified in +json.

Or something like that. (Then repeat for each +foo).

In addition, something along the following lines should be added 
(irrespectively of whether my suggestion above is used or not):

I don't know where this should be stated, registration templates don't 
seem to be the right place for this information:

NEW:
When updating a +suffix registration care should be taken to review all 
previously registered xxx/yyy+suffix media types regarding whether they 
might be affected by the updated +suffix registration.

---

From: Ned Freed <[email-masked]>
Date: Fri, 17 Aug 2012 07:11:16 -0700 (PDT)

> Or something like that. (Then repeat for each +foo).

The problem here is you're now trading one problem for another. As I understand
it, getting common semantics across fragement identifiers for different types
has been a signficant issue, and this ordering is intended to address that by
making it harder for specific types to override general rules. (Note that
it is still trivial to do so simply by writing a registration that explicitly
overrides the ordering.)

I see both sides so I have no real preference either way, but those who are
trying to get some degree of consistenty in fragement identifier handling
may have a different opinion.

> seem to be the right place for this information:

Yes, this particular part really belongs in the registration document, but it
is too late for that.

> might be affected by the updated +suffix registration.

Seems OK to me, but this is Tony's call, not mine.

				Ned

---

From: Tony Hansen <[email-masked]>
Date: Sat, 18 Aug 2012 21:28:54 -0400

On 8/17/2012 10:11 AM, Ned Freed wrote:
> Alexey Melnikov wrote:

Since I wrote the text the way I did, I obviously fell on the side of 
the common semantics across fragment identifiers having precedence.

I would like to hear input from others on this issue.

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Sat, 18 Aug 2012 21:35:53 -0400

On 8/17/2012 10:11 AM, Ned Freed wrote:
> ...

I can work this in somewhere. Based on the discussion on fragment 
identifier precedence, I might choose my suggested wording from an 
earlier email instead.

     Tony Hansen

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 30 Aug 2012 07:12:09 -0700

On Sat, Aug 18, 2012 at 6:35 PM, Tony Hansen <[email-masked]> wrote:
> I can work this in somewhere. Based on the discussion on fragment identifier
> precedence, I might choose my suggested wording from an earlier email
> instead.

Absent any further WG feedback in the last couple of weeks, please
proceed.  I'd like to get this off to the IESG ASAP.

Thanks,

-MSK