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

From: [email-masked] (Henry S. Thompson)
Date: Fri, 07 Sep 2012 09:53:16 +0100

Murray S. Kucherawy writes:

> 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.

Coming back late to this party, I hope the "this" above is only the 

>> 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.

bit, and _not_ the proposed NEW re-ordering of the precedence
overall. . .

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 07 Sep 2012 09:58:00 +0100

Tony Hansen writes:

> 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.

That's my position, and the TAG's.

That's why it's crucial that the generic == suffix == +foo spec. for
fragids must not make it an error if a fragid doesn't work in its
terms, so that in such cases the resolution can legitimately "fall
through" to the specific == suffixed == xxx/yyy+foo spec.

ht