Subject: [apps-discuss] font/*

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 07 Nov 2011 15:49:28 -0700

In talking with folks at the W3C meeting last week, I heard yet again of
interest in defining a Content Type for fonts. Would anyone active in
the IETF Applications Area want to work on such a spec? And do folks
here think a new top-level content type is needed for fonts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 14:57:54 -0800

> here think a new top-level content type is needed for fonts?

sure.  i don't know much about the details of font specification but am assuming 
the task here is one of packaging existing conventions rather than creating new 
ones.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Nov 2011 18:32:42 -0500

--On Monday, November 07, 2011 15:49 -0700 Peter Saint-Andre
<[email-masked]> wrote:

> In talking with folks at the W3C meeting last week, I heard
> yet again of interest in defining a Content Type for fonts.
> Would anyone active in the IETF Applications Area want to work
> on such a spec? And do folks here think a new top-level
> content type is needed for fonts?

Well, I think that a top-level would be in order -- these are
really different from the existing types.  Things may have
changed, but my recollection from when I had some exposure to
them in the early 90s is that there are a bunch of font
definition languages out there.  Unless all but one has
atrophied or one could pick one to go with the top-level type,
there is going to be a messy problem in which one either needs
to have 
  font/DefinitionLanguage fonttype=Foo
or another round of
  font/Foo+DefinitionLanguage
I'd hope we could avoid the latter, especially since some of
those languages and definitional methods don't scale over a very
broad range, s.t. one might actually need a tuple of Definition
Language, Typeface, Style, and applicable range of sizes.

Happy to try to help with this, but there better be some real
typographic experts involved.  We do not want to create a
top-level type only to find ourselves locked into one particular
kind of solution (even if it is open source rather than
vendor-specific).  I might still be able to carry on a useful
conversation with such an expert, but it has been a very long
time since I've had to do that, things have changed, and I've
forgotten a lot of what I once knew.

   john

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 08 Nov 2011 15:18:21 +0900

Hello Peter, others,

> here think a new top-level content type is needed for fonts?

Yes, I think it's a good thing to do.

But given the history of a top-level font/ type (see e.g. a report at 
http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html), one 
other important question you should ask is: Is there anybody strongly 
opposed to such a top level type.

If we can assure people at the W3C and elsewhere that we welcome a 
proposal for such a top level type, then it might even be that we don't 
need to be involved directly (although having somebody with apps 
experience involved could help).

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 08 Nov 2011 15:49:24 +0900

Hello John,

> forgotten a lot of what I once knew.

There is no need to overengineer this stuff. Like all other types, it's 
simply a top level type, and a subtype. A very rough approximation of 
what could end up in the subtype can be found here: 
http://en.wikipedia.org/wiki/Category:Font_formats.

If some kind of 'Definition Language' is used inside a font format, then 
that's just something under the hood. My understanding is that some 
popular formats such as OpenType essentially are mergers resulting from 
the "Definition Language" wars in the early 1990. Also, typeface, style, 
and applicable range of sizes shouldn't be necessary as part of the mime 
type because it's part of the content.

Some such parameters were proposed in 
http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be 
necessary, but not as much as 7 years ago, when you apparently shot down 
the proposal (see 
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if 
the font experts say they really need a parameter, we'll keep it, but we 
don't have to make thing more complicated than necessary in advance.

The only RFC that defined a new top-level type is RFC 2077 
(http://tools.ietf.org/html/rfc2077). It's rather short, and I expect 
the font/ RFC to be even shorter unless it also includes some 
registrations for actual subtypes (I'd probably do it in two separate 
documents, one for the top-level type and another for some low hanging 
subtypes, but I'll leave the decision to whoever does the actual work.)

Regards,   Martin.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 08 Nov 2011 08:27:38 +0000

It's not clear to me what purpose would be served that cannot be handled 
perfectly adequately by application/*

My understanding (or impression over the years) was that the top-level MIME type 
was a kind of high-level dispatch indicator to a device capable of rendering or 
otherwise presenting the broad kind of content, with application/* serving for 
types that needed further processing before they might meaningfully be 
considered for presentation

If I receive a font/* file, what might I do with it that is different from any 
other application/* type of file?

#g
--

---

From: Eric Burger <[email-masked]>
Date: Tue, 8 Nov 2011 09:15:33 -0500

Agreed.

On Nov 8, 2011, at 3:27 AM, Graham Klyne wrote:

> It's not clear to me what purpose would be served that cannot be handled perfectly adequately by application/*
> 
> My understanding (or impression over the years) was that the top-level MIME type was a kind of high-level dispatch indicator to a device capable of rendering or otherwise presenting the broad kind of content, with application/* serving for types that needed further processing before they might meaningfully be considered for presentation
> 
> If I receive a font/* file, what might I do with it that is different from any other application/* type of file?
> 
> #g
> --
> 
> 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Eric Burger <[email-masked]>
Date: Tue, 8 Nov 2011 09:20:08 -0500

Is the idea we would see something like

	font/Times

or one of 

	font/PostScript/Times
	font/TrueType/Times
	font/OpenType/Times
	font/METATYPE/Times

or one of

	font/Times/PostScript
	font/Times/TrueType
	font/Times/OpenType
	font/Times/METATYPE

One cannot just say it's font/* and assume it is an opaque container, as one could see battles over the latter examples.

On Nov 8, 2011, at 1:49 AM, Martin J. Dürst wrote:

> There is no need to overengineer this stuff. Like all other types, it's simply a top level type, and a subtype. A very rough approximation of what could end up in the subtype can be found here: http://en.wikipedia.org/wiki/Category:Font_formats.
> 
> If some kind of 'Definition Language' is used inside a font format, then that's just something under the hood. My understanding is that some popular formats such as OpenType essentially are mergers resulting from the "Definition Language" wars in the early 1990. Also, typeface, style, and applicable range of sizes shouldn't be necessary as part of the mime type because it's part of the content.
> 
> Some such parameters were proposed in http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be necessary, but not as much as 7 years ago, when you apparently shot down the proposal (see http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html). So if the font experts say they really need a parameter, we'll keep it, but we don't have to make thing more complicated than necessary in advance.
> 
> The only RFC that defined a new top-level type is RFC 2077 (http://tools.ietf.org/html/rfc2077). It's rather short, and I expect the font/ RFC to be even shorter unless it also includes some registrations for actual subtypes (I'd probably do it in two separate documents, one for the top-level type and another for some low hanging subtypes, but I'll leave the decision to whoever does the actual work.)
> 
> 
> Regards,   Martin.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 8 Nov 2011 11:15:01 -0600

Oh, I had thought it would be

  font/PostScript
  font/TrueType

i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we?

BTW, before naming this thing, please have a discussion with a typographer about the difference between a "font" and a "typeface." 

(My wife, who teaches typography, would beat me if I didn't make that distinction)

Cheers,

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 08 Nov 2011 10:38:39 -0700

> (My wife, who teaches typography, would beat me if I didn't make that distinction)

Well, we wouldn't want that! :)

Clearly I need to follow up with the folks I talked with at the W3C
meeting to learn more about their requirements.

/psa

---

From: "t.petch" <[email-masked]>
Date: Tue, 8 Nov 2011 18:39:01 +0100

----- Original Message -----
From: "Mark Nottingham" <[email-masked]>
To: "Eric Burger" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, November 08, 2011 6:15 PM

  font/PostScript
  font/TrueType

i.e., NOT identifying the specific typeface in use. After all, we don't have
text/html/home-page, do we?

BTW, before naming this thing, please have a discussion with a typographer about
the difference between a "font" and a "typeface."

<tp>
and typeface, versus typeface family (which, I suspect, is what many mean when
they say 'font')

Tom Petch

</tp>

(My wife, who teaches typography, would beat me if I didn't make that
distinction)

Cheers,

On 08/11/2011, at 8:20 AM, Eric Burger wrote:

> One cannot just say it's font/* and assume it is an opaque container, as one
could see battles over the latter examples.
>> There is no need to overengineer this stuff. Like all other types, it's
simply a top level type, and a subtype. A very rough approximation of what could
end up in the subtype can be found here:
http://en.wikipedia.org/wiki/Category:Font_formats.
>> If some kind of 'Definition Language' is used inside a font format, then
that's just something under the hood. My understanding is that some popular
formats such as OpenType essentially are mergers resulting from the "Definition
Language" wars in the early 1990. Also, typeface, style, and applicable range of
sizes shouldn't be necessary as part of the mime type because it's part of the
content.
http://tools.ietf.org/html/draft-singer-font-mime-00, and may still be
necessary, but not as much as 7 years ago, when you apparently shot down the
proposal (see http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html).
So if the font experts say they really need a parameter, we'll keep it, but we
don't have to make thing more complicated than necessary in advance.
>> The only RFC that defined a new top-level type is RFC 2077
(http://tools.ietf.org/html/rfc2077). It's rather short, and I expect the font/
RFC to be even shorter unless it also includes some registrations for actual
subtypes (I'd probably do it in two separate documents, one for the top-level
type and another for some low hanging subtypes, but I'll leave the decision to
whoever does the actual work.)

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

---

From: "Mykyta Yevstifeyev (М. Євстіфеєв)" <[email-masked]>
Date: Tue, 08 Nov 2011 21:15:59 +0200

+1. From RFC 2046:

>     The "application" media type is to be used for discrete data which do
>     not fit in any of the other categories, and particularly for data to
>     be processed by some type of application program.  This is
>     information which must be processed by an application before it is
>     viewable or usable by a user.

Font files are processed by applications, and they are processed before 
the text with some font is visible to user.  That's not the case for new 
content type.

Mykyta Yevstifeyev

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Nov 2011 11:22:08 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Graham Klyne
> Sent: Tuesday, November 08, 2011 12:28 AM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [apps-discuss] font/*
> 

I think by your definition, a font doesn't by itself get presented; it gets installed, and then used by other things as input to the presentation process.  A font needs to be loaded or stored or something before a text/* part can make use of it, for example.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Nov 2011 11:34:18 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Tuesday, November 08, 2011 9:15 AM
> To: Eric Burger
> Cc: [email-masked] Discuss

Ditto, with maybe name="TimesRoman" after it.

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Nov 2011 14:57:54 -0500

--On Tuesday, November 08, 2011 09:20 -0500 Eric Burger
<[email-masked]> wrote:

> One cannot just say it's font/* and assume it is an opaque
> container, as one could see battles over the latter examples.

Yes, that is part of what I was concerned about.

If the intent is merely to pass the descriptions/ definitions
around, then things like
   font/TrueType name="Times" 
might work, where "TrueType" is what I called a description
language in my earlier note.

But...

>...

--On Tuesday, November 08, 2011 18:39 +0100 "t.petch"
<[email-masked]> wrote:

>...
> BTW, before naming this thing, please have a discussion with a
> typographer about the difference between a "font" and a
> "typeface."
> 
> <tp>
> and typeface, versus typeface family (which, I suspect, is
> what many mean when they say 'font')
> 
> Tom Petch
> 
> </tp>

Indeed.  And that is why I made the comment about size ranges
(for description types that facilitate scaling) and about
styles. Does, e.g., 
   font/TrueType name="Times"
require that the entire typeface family be sent?  Think about
what happens if one wants to send the Bold style only.  Is 

   font/TrueType name="Times" style="Bold" 

sufficient?  Can TrueType handle some or all of that internally?
Is external labeling (as part of the Content Type) needed to
provide a referencing handle?  Can all of the other description
formats do the same thing.

Note that it is common to have mail messages in which a body
part (possibly text/html) references images that are additional
body parts of the same message.   Could one contemplate sending
a font and the content that uses it in the same message?  Does
that create any special issues?

I think this is probably worth doing, but I think there are a
lot of questions to be answered... and that the result is
unlikely to be a one-page RFC.

For example, I can see a really interesting IANA registry for
subtypes and keywords coming along -- probably not with a
one-page spec.

    john

---

From: Graham Klyne <[email-masked]>
Date: Tue, 08 Nov 2011 20:58:02 +0000

> I think by your definition, a font doesn't by itself get presented; it gets installed, and then used by other things as input to the presentation process.  A font needs to be loaded or stored or so…

Quite.  I think that puts it in the same category as, say, application/pkix-cert.

#g
--

---

From: Barry Leiba <[email-masked]>
Date: Tue, 8 Nov 2011 17:53:24 -0500

> perfectly adequately by application/*

This was my first thought as well.

But then I thought again, and I said, "Gee: that's always true.  If we
always think that, then wouldn't *everything* just be
'application/<something>'?  And then what would the point of top-level
types be in the first place?"

We have the precedent, as it's set up in the first place, to say,
"This is text," and "This is audio," and "This is an image," and "This
is video."  It seems to me that, "This is a font definition," is as
much a statement of a distinct media type as the others are.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Nov 2011 00:01:19 +0100

> much a statement of a distinct media type as the others are.

+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 Nov 2011 15:02:22 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Tuesday, November 08, 2011 2:53 PM
> To: Graham Klyne

I think that's part of what I was trying to get at earlier, but you did a far better job than I did.

+1.

-MSK

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 Nov 2011 10:12:35 +0900

> much a statement of a distinct media type as the others are.

Very well put!

Regards,   Martin.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 09 Nov 2011 09:16:27 +0800

> perfectly adequately by application/*

Thanks for raising this point.  On reflection, I seem to recall that adding 
top-level types is a Big Deal and not done.

Your question points to the alternative that constitutes a less disruptive 
challenge to the current proposal.

d/
-- 

   Dave Crocker

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 09 Nov 2011 10:17:16 +0900

> i.e., NOT identifying the specific typeface in use. After all, we don't have text/html/home-page, do we?

It's definitely that.

 From http://tools.ietf.org/html/draft-singer-font-mime-00
(which requires some serious rewriting around security issues, but 
otherwise is recommended reading for people who want to comment in this 
discussion):

    This document defines a top-level MIME type "font" under which
    differing representation formats of fonts may be registered (e.g. a
    bitmap or outline format).  It should be emphasized that, just as
    under the "image" top-level type one does not find registration for,
    for example, "The Night-watch" (by Rembrandt) but instead "JPEG" (an
    image representation system), so, under "font" one will not find
    "Courier" (the name of a popular font) but perhaps "BDF" (the name of
    a commonly used bitmap font format).

> (My wife, who teaches typography, would beat me if I didn't make that distinction)

http://fontfeed.com/archives/font-or-typeface/ explains that in very 
simple terms. As far as the analogy there with MP3<=>font, 
song<=>typeface goes, we definitely need Mime types for fonts, not for 
typefaces.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Nov 2011 08:06:32 -0500

Hi Martin,

The links you gave to earlier messages don't work, but I don't
recall "killing" a font proposal.  See inline below.

--On Tuesday, November 08, 2011 15:49 +0900 "\"Martin J.
Dürst\"" <[email-masked]> wrote:

> There is no need to overengineer this stuff. Like all other
> types, it's simply a top level type, and a subtype. A very
> rough approximation of what could end up in the subtype can be
> found here: http://en.wikipedia.org/wiki/Category:Font_formats.

I was, and remain, very hesitant about creating new top-level
types.  As others have noted, it is a big deal.  There are
several reasons for that but at least one important one is that
the model for what an application is expected to do when it
encounters an unknown top-level type is not, IMO, really well
sorted out.  One cannot do much of anything (in that sense, it
isn't much different from an application/ subtype), but it isn't
clear how one should present that fact to a user who doesn't
have much understanding or vocabulary about what is going on at
the content-type level.

"Model/" (as described in RFC 2077) was not a problem because
the request came from a particular community for a particular
type of use, one on which there was little or no likelihood of
interaction with other types, especially with multipart content.
I assume that the community that wanted that type is using it,
but confess to never having seen the type in the wild.  If
others haven't either, that reinforces the claim that the
"model/" type really is independent of the others.

If font/* is simply a "type and a subtype", then I'm inclined to
agree with those who say "use application/".  Certainly it is
feasible to say, e.g., "application/OpenType", specify it as
being bound to the OpenType font definition model, say some
things about encoding and parameters, and move on.  The fact
that it and an equally hypothetical "application/TrueType" both
encode/carry fonts creates no more of a requirement or
justification for a top-level type than the observation that
there application/ subtypes for Open Document and MSWord formats
implies that we should have a top-level type for WordProcessor/
or DocumentFormatter/.  And, as Graham and others have pointed
out, we use "application/" (a lot) for subtypes that require
processing or installation before something else can make use of
them.

I think a font/ top-level type would be worth looking at
carefully if there really were a use case for which some
application/ subtypes would not be appropriate.  One of those
might lie along the path of compound documents that I mentioned
in the context of "image/".   Perhaps there might be others, or
perhaps not.  "Distinct media type" doesn't do much for me
because what is, and is not, is largely in the mind of the
beholder.

> If some kind of 'Definition Language' is used inside a font
> format, then that's just something under the hood. My
> understanding is that some popular formats such as OpenType
> essentially are mergers resulting from the "Definition
> Language" wars in the early 1990.

I used "Definition Language" to refer to what you are referring
to as a "format" (which often means something else in this
context).  I don't have enough contemporary knowledge to know
what would be most accurate and consistent with current
terminology -- another topic for Mark's wife or some other
typographic expert.

> Also, typeface, style, and
> applicable range of sizes shouldn't be necessary as part of
> the mime type because it's part of the content.

I don't know what that means in practice.  Having struggled
several times with what needs to be a parameter on a media type
and subtype, it isn't obvious that parameters are unnecessary
even if the information can be deduced from content.   I am
particularly concerned about transmission of files that contain
parts of a typeface family, but not all of it, as well as about
a type and subtype that don't even identify the type family and
hence may require a lot of work before a system can decide
whether to install it.

I also don't know whether all "Definition Languages" in use
today contain the same descriptor information in reasonably
compatible formats.   If some do and others require, e.g., the
name of the font in supplemental information because only the
glyph descriptions are stored in the file, then there is a lot
of justification for parameters across the board if one is going
to have a well-designed top-level type with homogeneous
subtypes.  Of course, homogeneous subtypes are not a
requirement, but, if each subtype will have to establish its own
parameter model, it seems to me that the argument for just
sticking with "application/" becomes stronger.

> http://tools.ietf.org/html/draft-singer-font-mime-00, and may
> still be necessary, but not as much as 7 years ago, when you
> apparently shot down the proposal (see
> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.htm
> l). So if the font experts say they really need a parameter,
> we'll keep it, but we don't have to make thing more
> complicated than necessary in advance.

> (http://tools.ietf.org/html/rfc2077). It's rather short, and I
> expect the font/ RFC to be even shorter unless it also
> includes some registrations for actual subtypes (I'd probably
> do it in two separate documents, one for the top-level type
> and another for some low hanging subtypes, but I'll leave the
> decision to whoever does the actual work.)

While the "model/" spec is rather short, it contains the
elements I'm trying to advocate here: a clear description of why
a top-level type is needed, a discussion of use cases, and
definitions of enough subtypes to make the use cases clear, as
well as the required templates and mechanisms for defining
future subtypes.

Recommendation to those who want this:  Work on a few subtype
definitions.  Sort the details, such as what parameters are
needed, out with the typographic community.  Examine the use
cases.   The would would need to be done --and would be almost
the same-- for a subtype of application/ or a subtype of font/.
With those tentative subtype descriptions in hand, the rest of
us will be a lot more able to identify commonalities and to
participate in an evaluation of whether a top-level type is
really justified.

best,
   john

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Nov 2011 18:56:04 +0100

On 2011-11-08 09:27, Graham Klyne wrote:
> My understanding (or impression over the years) was that the top-level
> MIME type was a kind of high-level dispatch indicator to a device
> capable of rendering or otherwise presenting the broad kind of content,
> with application/* serving for types that needed further processing
> before they might meaningfully be considered for presentation
>
> If I receive a font/* file, what might I do with it that is different
> from any other application/* type of file?
> ...

In HTTP:

	Accept: font/*

(not sure whether it would be useful, but at least that's one thing you 
need a top level type for...)

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Nov 2011 10:56:58 -0700

>> don't have text/html/home-page, do we?

Verified through conversation on the [email-masked] list. We're talking 
about a small number of file formats for fonts (TrueType, OpenType, Web 
Open Font Format, etc.) -- talking about typefaces, font families, 
particular fonts, etc.

Now, whether we need a top-level content type of "font", resulting in 
subtypes like font/woff (instead of, say, application/font-woff [1]) is 
another story...

/psa

[1] http://www.ietf.org/mail-archive/web/ietf-types/current/msg01115.html

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Nov 2011 10:58:02 -0700

> Open Font Format, etc.) -- talking about typefaces, font families,
                            ^not^

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Nov 2011 10:01:34 -0800

On Nov 9, 2011, at 9:56 AM, Julian Reschke wrote:

> (not sure whether it would be useful, but at least that's one thing you need a top level type for...)

The genesis for the current thread, I thought, was the websec WG's work on font-sniffing. "What might I do different" would be "do security checks", I believe. Folks who are more active on websec can answer this better.

--Paul Hoffman

---

From: Lyndon Nerenberg <[email-masked]>
Date: Wed, 9 Nov 2011 10:05:36 -0800

> (not sure whether it would be useful, but at least that's one thing you need a top level type for...)

I was just about to argue the more general case.  IMAP is another place where there is utility in being able to recognize font blobs outright, without requiring knowledge of specific font representations.  E.g. a text-only IMAP client could ignore all font/* sections without having to annoy the end-user, who probably doesn't know what an application/opentype is.

Also, font/* with well defined parameters makes possible aggressive caching of fonts on bandwidth-constrained mobile clients.  XMPP immediately leaps to mind.

--lyndon

---

From: Julian Reschke <[email-masked]>
Date: Wed, 09 Nov 2011 19:11:14 +0100

> The genesis for the current thread, I thought, was the websec WG's work on font-sniffing. "What might I do different" would be "do security checks", I believe. Folks who are more active on websec c…

I think we got here because somebody claimed that font types don't have 
registered media types, because, some time ago, the IETF didn't want to 
register the top level type. Which, of course, is a totally separate issue.

Best regards, Julian

---

From: Eric Burger <[email-masked]>
Date: Wed, 9 Nov 2011 16:00:34 -0500

Sounds like a call for a BOF.

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Nov 2011 16:07:45 -0500

> Sounds like a call for a BOF.

Only if we can get some serious typographic folks there.
Otherwise, I'd personally prefer to see a few I-Ds.  Since there
is no change of getting a BOF together before next week, some
documents on which the community could base decisions would have
a chance of being a lot faster, too.

best,
   john

>> several reasons for that but at least one important one is
>> that the model for what an application is expected to do when
>> it encounters an unknown top-level type is not, IMO, really
>> well sorted out.  One cannot do much of anything (in that
>> sense, it isn't much different from an application/ subtype),
>> but it isn't clear how one should present that fact to a user
>> who doesn't have much understanding or vocabulary about what
>> is going on at the content-type level.
>...
>> the same-- for a subtype of application/ or a subtype of
>> font/. With those tentative subtype descriptions in hand, the
>> rest of us will be a lot more able to identify commonalities
>> and to participate in an evaluation of whether a top-level
>> type is really justified.
>> 
>> best,
>>   john
>> 
>>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 09 Nov 2011 14:11:10 -0700

> a chance of being a lot faster, too.

Documents are good. I'll reach out to folks at the W3C to see if someone 
who's involved in the Web Open Font Format work might be able to put 
some energy into these discussions.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 10:39:44 +0900

> subtypes like font/woff (instead of, say, application/font-woff [1]) is

It would be good if we could answer this question soon, and hopefully in 
the positive.

The (Web)font community has tried to get a font/ top level type 
repeatedly, with bad results. At least two attempts are documented.

In http://lists.w3.org/Archives/Public/www-font/2009JulSep/1069.html, 
Chris Lilley describes his attempt around 1998 or so, which met active 
resistance ("we will strenuously oppose this and take up lots of your 
time if you persist").

The second attempt is documented at
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html
which got a single, (from their point of view) rather scary reply.

Unless we can tell them that we will look at a new proposal favorably, 
(at least) because either a new font/ or reusing application/ look okay, 
and if they think font/ is better, they should go with it, then I don't 
think they'll have the courage to try again.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 10:40:19 +0900

Hello John, others,

On 2011/11/09 22:06, John C Klensin wrote:
> Hi Martin,
>
> The links you gave to earlier messages don't work,

Please try again at
http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html

If it still doesn't work (it worked for me), please make sure to put all 
the pieces back together that have been split over more than one line. 
It seems that in my mail, the final "l" of the ".html" extension got 
split off to the next line.

> but I don't

I have to apologize for using the word "killing", I regretted it shortly 
after sending the mail.

It was after I looked at
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html,
which links to your mail.

Reading your mail, and David Singer's summary, it's not surprising that 
they gave up. You ask for very strong arguments of why a new top-level 
type is needed, and application/ isn't good enough. You also ask them to 
examine whether there's not a more general concept behind the top-level 
type of font.

For people e.g. on this list who now your writing style, such a mail 
wouldn't have been too much of a show-stopper. But for outsiders, and 
given that this was the only feedback they got (which isn't your fault), 
it must have sounded quite scary.

> Dürst\""<[email-masked]>  wrote:
>
>> ...
> types.

In general, that's a good idea.

> As others have noted, it is a big deal.

I think that it's a big deal mostly because some people think it's a big 
deal. I haven't seen any serious arguments about why it actually is a 
big deal.

> There are
> sorted out.

RFC 2046 clearly envisions the creation of additional top-level types, 
and so if there are applications that aren't ready to deal with them, 
then that's their fault. But I don't think that in actual practice, this 
would be a problem (if you think it will, please show me a concrete case).

>  One cannot do much of anything (in that sense, it

Do you think the user will be more confused by a message saying
     Downloading file, type: font/woff, Open or Save?
or by a message saying
     Downloading file, type: application/woff, Open or Save?

At least in the former, they might see the word "font" and get a clue. 
So I think this issue is essentially irrelevant.

> interaction with other types, especially with multipart content.

I think this is wrong. There is lots of potential interaction between 3D 
models and text, audio, video, images, and other application data. The 
reason you aren't seeing any of this is because there are umpteen 
reasons (which I don't think we need to discuss here) for why 3D hasn't 
caught on (yet?) on the Web and the Internet.

> "model/" type really is independent of the others.

See above.

> processing or installation before something else can make use of

We can always throw everything into application/. But then, why do we 
have image/, audio/, and video/ (and text/; I'm putting text/ in 
parentheses because there are very specific handling rules that don't 
apply to any of the other types) in the first place?

For people involved with fonts (and many others, as we have seen on this 
list), fonts are not images, they are not video, and they are not audio, 
but they are also not just application data. These people (including 
many typographers and other font experts, with lots of Web and Internet 
experience) think that font/ is the right thing to do. They have tried 
several times (see my mail to Peter).

> because what is, and is not, is largely in the mind of the

So why don't we change policies so that new image types also have to be 
registered under application/?

> terminology -- another topic for Mark's wife or some other

There are experts who have the knowledge. They have tried to register 
font/ previously. Why don't we trust them?

> hence may require a lot of work before a system can decide

With Web fonts, or with fonts attached to other documents such as 
emails, partial fonts are indeed very important. But they will be 
installed temporarily. Also, for Web fonts, the main usage is via CSS, 
which makes sure there's enough meta-information.

> subtypes.

Would it be possible to let the font experts figure this out?

> well as the required templates and mechanisms for defining

I don't disagree here (except that RFC 2077 doesn't actually define 
subtypes, just gives some example of things that might be expected).

I agree that having a bit of text on why a new subtype was chosen can't 
hurt at all. But I think we have to be careful and not make this a 
sysiphean exercise by requiring something like a proof that a new 
top-level type was absolutely necessary because otherwise the world will 
go under.

> participate in an evaluation of whether a top-level type is

Sorry, John, but they have tried before. They don't have much trust 
anymore. If we again tell them what sounds to them as "bring it on, and 
we'll do our best to shoot it down and make your life miserable",  then 
they won't do the work. They won't do it for font/, and they also won't 
do it for application/. I don't think that's what we want.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 10:47:07 +0900

>> perfectly adequately by application/*

Then why do we have image/, audio/, and video/? application/ would be 
perfectly adequate for them, wouldn't it?

> Thanks for raising this point. On reflection, I seem to recall that
> adding top-level types is a Big Deal and not done.

Please don't use hearsay and rumors as arguments.

Of course adding a top-level type isn't something that's done every day, 
but the last one was added almost 15 years (model/, January 1997, RFC 
2077), and no next one (after font/) is lined up.

Also, RFC 2046 explicitly allows additions of top-level types (see the 
very end of 
http://lists.w3.org/Archives/Public/public-webfonts-wg/2010Nov/0012.html):

    It should be noted that the list of media type values given here may
    be augmented in time, via the mechanisms described above, and that
    the set of subtypes is expected to grow substantially.

> Your question points to the alternative that constitutes a less
> disruptive challenge to the current proposal.

In what sense is adding a font/ top-level type "disruptive"?

Regards,   Martin.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Nov 2011 02:58:18 +0100

>2077), and no next one (after font/) is lined up.

RFC 4735 introduced the "example" top level type in 2006. As far as I
can tell, there were a total of three comments on it, one on ietf-types
and two from the IESG, none of which were particularily negative.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 10 Nov 2011 09:59:06 +0800

> http://fontfeed.com/archives/font-or-typeface/ explains that in very simple
> terms. As far as the analogy there with MP3<=>font, song<=>typeface goes, we
> definitely need Mime types for fonts, not for typefaces.

Forgive me for feeling the need to be entirely pedantic here, but the article 
went just shy of being completely clear (for me) and I think it is indeed worth 
having us all not merely on the same page, but the same place on the page...

Is this correct:

    Typeface:  times roman

    Font:      times roman, 12pt

    Font:      times roman, 10pt

    Font:      times roman, 10pt, italic

    Font:      times roman, 10pt, bold

Yes?

That is, typeface is the basic design (or abstraction) while typeface + physical 
details (such as specific size) is a font?

Tnx.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 10 Nov 2011 10:30:58 +0800

> Sounds like a call for a BOF.

For a topic like this, I believe a BOF makes sense only for either or both of:

    1.  Interactive tutorial, to create a community of folk who share a common 
set of information and are going to proceed doing some work on the topic. 
Hence, this would prime the work pump.

    2.  Debate particulars, prior to formulating a spec.  One can argue that 
that sounds like a regular working group, but I've tailored the description to 
fit a before-wg phase.  In any event, this presumes that folks are already 
sharing a common base of knowledge and details and merely need to debates some 
details.

My sense of this extended thread is that the group ain't quite far enough along 
for #2.  I can't tell whether #1 is needed.

d/
-- 

   Dave Crocker

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Nov 2011 03:38:41 +0100

>here think a new top-level content type is needed for fonts?

As it is, the expectation is that HTTP responses should indicate the
format of frequently used resources should be indicated in the Content-
Type header, and Content-Type values should be registered MIME types.
We can expect the number of HTTP responses that carry some "font" will
increase in frequency, so there should be registered types for the un-
derlying formats. I don't think that is controversial, and I do not
think it matters much whether the few interesting types would go under
"font/" or under "application/". This thread seems to have generated
more feedback than I would expect if someone had just gone ahead and
brought a corresponding Internet-Draft to the IESG for approval. I am
happy to review any font type registrations on ietf-types, and would
of course support such registrations if they meet relevant criteria.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: John C Klensin <[email-masked]>
Date: Wed, 09 Nov 2011 21:56:22 -0500

--On Thursday, November 10, 2011 10:40 +0900 "\"Martin J.

> http://www.ietf.org/mail-archive/web/ietf/current/msg33267.html

That did it, thanks.

> I have to apologize for using the word "killing", I regretted
> it shortly after sending the mail.

No problem.  It does seem as if I'm consistent in wondering
whether a top-level type is actually necessary.   I am slightly
less concerned about the implications of a relatively small
number of subtypes than I was then.  But, as others have said
more emphatically than I have, a new top-level type should
require a lot of justification.

> which links to your mail.

That note suggests that mine was the only comment.   If so, I'd
assume the proposal basically ran out of steam because not
enough people cared.   In that sense, more progress has already
been made this time because there has been a discussion.

> Reading your mail, and David Singer's summary, it's not
> surprising that they gave up. You ask for very strong
> arguments of why a new top-level type is needed, and
> application/ isn't good enough. You also ask them to examine
> whether there's not a more general concept behind the
> top-level type of font.

I think others have made the same request wrt new top-level
types rather than application/.   Of course the existence of PFR
(which I assume is still in use) as an application/ subtype
doesn't strengthen the case that a separate top-level type is
needed.

And, yes, creating a new top level type for a half-dozen or
fewer subtypes does seem wasteful, but, again, I don't feel
quite as strongly about that as I did seven years ago (although
others may).

> For people e.g. on this list who now your writing style, such
> a mail wouldn't have been too much of a show-stopper. But for
> outsiders, and given that this was the only feedback they got
> (which isn't your fault), it must have sounded quite scary.

I think Dave Singer actually does know my writing style.  But,
more important (at least IMO), the lack of response should have
been scary for another reason: hard to propel something like
this through the IETF if very few people care.   The lack of
response might not have meant that, but...

>...
> I think that it's a big deal mostly because some people think
> it's a big deal. I haven't seen any serious arguments about
> why it actually is a big deal.

I tried to outline this earlier but, again, others may have
different reasons.   I think a top-level type requires either
relatively strong justification that it is a necessary special
case or specification of what happens with unrecognized
subtypes, parameters, etc.  That is a lot of definitional work,
followed by significant implementation work... just not
something to be done lightly because some class of file formats
seems special.

>> well sorted out.
> RFC 2046 clearly envisions the creation of additional
> top-level types, and so if there are applications that aren't
> ready to deal with them, then that's their fault. But I don't
> think that in actual practice, this would be a problem (if you
> think it will, please show me a concrete case).

I'll let Ned or Nathaniel speak to that, but my impression at
the time was that it allowed for additional types because not
doing so would represent a claim to really comprehensive
knowledge of the future.  It wasn't intended as license to go
out and create a bunch of them -- application/ was really
intended to be quite comprehensive wrt the things that need, as
someone else put it, to be processed and usually stored
somewhere, not rendered directly to the user.  We render text,
video, and images.  Fonts are used to build tables that are then
used with a list of characters and other information to create
something that is rendered.  The latter is either pretty close
to application/ or, as I suggested in 2004, represents a
different sort of creature that should be generalized.

>> isn't much different from an application/ subtype), but it
>> isn't clear how one should present that fact to a user who
>> doesn't have much understanding or vocabulary about what is
>> going on at the content-type level.
> 

If I were a user, I'd be pretty upset by either message.  They
both look like gibberish and I'd have no clue which action I
should take.

> At least in the former, they might see the word "font" and get
> a clue. So I think this issue is essentially irrelevant.

More so if one considered application/font-woff (as in
application/font-tdpfr).

> I think this is wrong. There is lots of potential interaction
> between 3D models and text, audio, video, images, and other
> application data. The reason you aren't seeing any of this is
> because there are umpteen reasons (which I don't think we need
> to discuss here) for why 3D hasn't caught on (yet?) on the Web
> and the Internet.

Ok.  But, if you see the distinction in terms of the
interactions, make that case for fonts.  I'm actually much more
open to this idea than you seem to have concluded (and was open
to it in 2004) - I just think the questions I've asked (as
questions, not rebuttal) are appropriate and should be addressed
in a serious way... with a default if there aren't satisfactory
answers of "use application/".

>...
>> If font/* is simply a "type and a subtype", then I'm inclined
>> to agree with those who say "use application/".  Certainly it
>> is feasible to say, e.g., "application/OpenType", specify it
>> as being bound to the OpenType font definition model, say some
>> that it and an equally hypothetical "application/TrueType"
>> both encode/carry fonts creates no more of a requirement or
>> there application/ subtypes for Open Document and MSWord
>> formats implies that we should have a top-level type for
>> WordProcessor/ or DocumentFormatter/.  And, as Graham and
>> others have pointed out, we use "application/" (a lot) for
>> subtypes that require processing or installation before
>> something else can make use of them.
> 
> We can always throw everything into application/. But then,
> why do we have image/, audio/, and video/ (and text/; I'm
> putting text/ in parentheses because there are very specific
> handling rules that don't apply to any of the other types) in
> the first place?

Because of what I'm describing as the rendering issue.  And the
compound body/message ("multipart") issue.

> For people involved with fonts (and many others, as we have
> seen on this list), fonts are not images, they are not video,
> and they are not audio, but they are also not just application
> data. These people (including many typographers and other font
> experts, with lots of Web and Internet experience) think that
> font/ is the right thing to do. They have tried several times
> (see my mail to Peter).

To repeat what I said earlier, I'd like to see some I-Ds that
drill down into the subtypes.  The observation that Bitstream
thought that application/ was adequate for PFR (and did write a
document) is some evidence that "these people" are not unanimous
that a top-level type is needed.  Now, if someone came forward
and said "we tried using application/font-tdpfr and the fact
that 'font' wasn't a top level type caused the following
specific problems so we have learned that putting it into
application/ was a bad idea", I, at least, would find that
extremely persuasive.  

That isn't the only way to persuade me (and presumably, others
who have suggested using application/ subtypes).  But I think
somewhat more is needed than an assertion that "people involved
with fonts" want and/or need this.

>> might lie along the path of compound documents that I
>> mentioned in the context of "image/".   Perhaps there might
>> be others, or perhaps not.  "Distinct media type" doesn't do
>> much for me because what is, and is not, is largely in the
>> mind of the beholder.
> 
> So why don't we change policies so that new image types also
> have to be registered under application/?

See above, plus the fact that image/ already exists as a basic
type and part of what you are arguing against is a principle
that we should not create a lot of top-level types... or any
more of them without considerable justification.

>...
> With Web fonts, or with fonts attached to other documents such
> as emails, partial fonts are indeed very important. But they
> will be installed temporarily. Also, for Web fonts, the main
> usage is via CSS, which makes sure there's enough
> meta-information.

But, unless you propose to restrict the use of this type to the
web, the broader questions need to be addressed.  And I haven't
seen anything proposed yet that would result in a different
handling or definitional model for temporary versus more
permanent installations.  Again, an I-D that explored or
specified these things would be a big help here.

I said before that I've got a relatively open mind about this.
The one thing about which I don't have an open mind is the idea
of saying "ok, let's create a top-level 'font/' type and assume
that the subtype definitions and all of the other issues will
sort themselves out".  I think a top-level type needs an
architecture, not just a string of characters.  YMMD.

>> of justification for parameters across the board if one is
>> going to have a well-designed top-level type with homogeneous
>> subtypes.
> 

Sure.  Get someone to produce an I-D or three.  Don't expect
people to believe that they will figure it out because they are
font experts.

>> elements I'm trying to advocate here: a clear description of
>> why a top-level type is needed, a discussion of use cases, and
> I don't disagree here (except that RFC 2077 doesn't actually
> define subtypes, just gives some example of things that might
> be expected).
> 
> I agree that having a bit of text on why a new subtype was
> chosen can't hurt at all. But I think we have to be careful
> and not make this a sysiphean exercise by requiring something
> like a proof that a new top-level type was absolutely
> necessary because otherwise the world will go under.

I don't think anyone has suggested that.  Certainly I haven't.

> Sorry, John, but they have tried before. They don't have much
> trust anymore.

As far as I can tell, only one subtype definition has been tried
and it resulted in RFC 3073.  If "tried before" means "thought
about it but decided to not post drafts and open discussions"
then I sympathize but I don't know how to get unstuck (in this
area or others with which you are familiar) from vague claims
about obstructions and problems.

>  If we again tell them what sounds to them as
> "bring it on, and we'll do our best to shoot it down and make
> your life miserable",  then they won't do the work. They won't
> do it for font/, and they also won't do it for application/. I
> don't think that's what we want.

I agree.  So your help, and Peter's, and that of others, are
going to be needed to be sure that the message comes across
well.  But I don't think that either a top-level type, or even
an application/ subtype, are going to get very far unless there
are definitions that can be examined by others and shown to work
and to be sufficiently comprehensive.

regards,
    john

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Nov 2011 20:06:12 -0800 (PST)

> deal. I haven't seen any serious arguments about why it actually is a

I have to agree with Martin here. In my experience whether or not a type is a
"big deal" has everything to do with whether or not it represents a new
structuring convention that needs to be handled (leaf versus non-leaf as far as
MIME is concerned) and nothing to do with whether or not a new top level is
involved.

So: Introduce some font/* types, and as long as I don't have to take it apart
to find other parts inside I'm fine. My media type tables (and all of the
tables in software I've encountered) deal in whole type names and let you
specify pretty much anything.

EAI's introduction of message/global, OTOH, *is* a big deal, even though it is
not a new top-level type. For such types I have to carefully consider in every
context where MIME processing is being done if I want to "go inside" or not,
and perhaps even provide options to control whether or an object of this type
is seen as a leaf or non-leaf. This is actually a bigger deal to me than
a new content-transfer-encoding.

New subtypes of text can also be a big deal, as can adding parameters to
existing text subtypes, because this stuff affects the basic rendering of
messages in user agents.

The only place I know where there might be a problem with a new top-level
font type is SDP. I confess to knowing next to nothing about SDP, but
it uses media types and has some really screwy constraints on on what it can
handle. I'm not seeing an application for font types in SDP, but if there
is someone more familiar with it sohuld be consulted on possible issues.

Anyway, my position on this is if there are behaviors that need to apply to
font parts in the aggregate then a new font top level type is in order to deal
with that. If, OTOH, there's no common behavior needed, a top-level font type
is still a nice-to-have.

> > encounters an unknown top-level type is not, IMO, really well

I'm sorry, but this is clearly misreading the intent, and I think at least some
of the letter, of RFC 2046. There was a time when we thought it was good idea
to talk about processing top-level types as entities in their own right, but
this was early in the MIME effort. We later came to the conclusion that in the
case of leaf parts, unknown types should be treated like
application/octet-stream and unknown top-levels should be treated like
application (but with the subtypes in their own namespace, of course).

Again, the problem for processing agents of all types is really with non-leaf
objects, where clean defaulting rules really aren't possible.

> then that's their fault.

Well, I wouldn't go quite that far - if there was a significant widely deployed
set of applications that would break then we need to take application set into
account. But no such issue exists in any application set I know of.

> But I don't think that in actual practice, this

Exactly.

Agreed.

> > but confess to never having seen the type in the wild.

I actually have encountered objects with the model type. Then again, I did
quite a lot of mathematical modelling work before I got into email, so this may
be a holdover from that.

And they didn't cause any problems either. I had no trouble associating
handlers with them and as always there was the "extract to file" approach.

> > If

> apply to any of the other types) in the first place?

Well, this gets into whether or not there's an aggregrate handling approach
that makes sense for the type. Font seems to qualify in this regard.

> several times (see my mail to Peter).

Seems reasonable to me.

> font/ previously. Why don't we trust them?

In practice the issue of what to register where has never been much of a
problem. Speaking now as media types reviewer, I have not infrequently  pushed
back on top-level type choices, usually successfully and always amicably.

> which makes sure there's enough meta-information.

Meta-information needs to either be part of the font or part of whatever
is using the font. Putting it in, say, content-type parameters strikes me
as a bad idea. Media features could be used if this is a real issue, but I
rather suspect it is not.

> Would it be possible to let the font experts figure this out?

I don't think you're going to find as much variability amongst these things as 
people seem to be worried about here. I'll also point out that similar issues
exists for images and video, where we went to a lot of trouble to define a
fairly elaborate media features language, which AFAICT pretty much nobody uses.

> subtypes, just gives some example of things that might be expected).

I'm ambivalent about whether or not a bunch of subtypes are defined in the
base document.

> top-level type was absolutely necessary because otherwise the world will

Exactly!

+1

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 13:20:04 +0900

On 2011/11/10 10:59, Dave CROCKER wrote:
>> simple
> Forgive me for feeling the need to be entirely pedantic here, but the
> article went just shy of being completely clear (for me) and I think it
> is indeed worth having us all not merely on the same page, but the same
> place on the page...
>
> Is this correct:
>
> Typeface: times roman
>
> Font: times roman, 12pt
>
> Font: times roman, 10pt
>
> That is, typeface is the basic design (or abstraction) while typeface +
> physical details (such as specific size) is a font?

Not exactly. On the one hand, the italic version of times roman actually 
is a design by itself, so it can very well be seen as a typeface.

On the other hand, specific size was important for lead type (which 
doesn't scale) and bitmap font formats. With today's outline and hinting 
technologies, most fonts are designed to work at many different sizes, 
so the specific size is rather irrelevant.

Anyway, what we are looking at is to have media types for font formats. 
Typeface affects this only marginally.

Regards,   Martin.

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 10 Nov 2011 12:36:48 +0800

On 11/10/2011 12:20 PM, "Martin J. Dürst" wrote:
> Not exactly. On the one hand, the italic version of times roman actually is a
> design by itself, so it can very well be seen as a typeface.
>
> On the other hand, specific size was important for lead type (which doesn't
> scale) and bitmap font formats. With today's outline and hinting technologies,
> most fonts are designed to work at many different sizes, so the specific size is
> rather irrelevant.
>
> Anyway, what we are looking at is to have media types for font formats. Typeface
> affects this only marginally.

Well, I think I tracked your response and I think it made sense to me, including 
the wrinkle added to the historical perspective by the 'outline' model(s).

The problem is that where it landed leaves me still unclear about the exact 
difference between face and font, and it seems that it would be useful for 
font/face non-geeks, like me, to be able to use the terms properly.

mumble.

d/
-- 

   Dave Crocker

---

From: Tony Hansen <[email-masked]>
Date: Thu, 10 Nov 2011 00:06:56 -0500

By the definitions of that article and other things I've read, what's 
being proposed to be included as sub-types of the new font/* are neither 
fonts nor typefaces. Instead they are font description language file 
formats.

     Tony Hansen
     [email-masked]

On 11/9/2011 8:59 PM, Dave CROCKER wrote:
> article went just shy of being completely clear (for me) and I think 
> it is indeed worth having us all not merely on the same page, but the 
> same place on the page...
>
> Is this correct:
>
>    Typeface:  times roman
>
>    Font:      times roman, 12pt
>
>    Font:      times roman, 10pt
>
> That is, typeface is the basic design (or abstraction) while typeface 
> + physical details (such as specific size) is a font?
>
> Tnx.
>
> d/
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 15:55:36 +0900

I think it may be too early to discuss procedural points, but we are 
speaking about one, potentially two, drafts, both of which quite short. 
In the old days, AD-sponsored individual submission(s) would have been 
best. Now, we might need to move it through the Apps WG.

Trying to do anything like a BOF or a WG seems complete overkill. There 
are many people involved in fonts (in particular Web fonts). But I can't 
imagine them shell out the money just to come to an IETF meeting for 
getting a few types registered.

This is not about a spec for a new protocol or format. The formats 
exist, some of them for more than 10 years, some of them more recent. 
It's just about giving them labels.

Regards,    Martin.

On 2011/11/10 11:30, Dave CROCKER wrote:
> 1. Interactive tutorial, to create a community of folk who share a
> common set of information and are going to proceed doing some work on
> the topic. Hence, this would prime the work pump.
>
> that sounds like a regular working group, but I've tailored the
> description to fit a before-wg phase. In any event, this presumes that
> folks are already sharing a common base of knowledge and details and
> merely need to debates some details.
>
> My sense of this extended thread is that the group ain't quite far
> enough along for #2. I can't tell whether #1 is needed.
>
> d/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Nov 2011 09:11:41 +0100

> It's just about giving them labels.

++++++1

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 10 Nov 2011 04:40:28 -0500

> speaking about one, potentially two, drafts, both of which quite short. In
> the old days, AD-sponsored individual submission(s) would have been best.
> Now, we might need to move it through the Apps WG.

Yes, I agree.  As appsawg chair, I think this is appropriate for
appsawg (but I haven't discussed this with my co-chairs).  That said,
the right way to start this is, indeed, to float individual-submission
drafts for this gang to review and comment on.  If that discussion
results in adoption of those drafts by appsawg, you're on your way.

Barry

---

From: "t.petch" <[email-masked]>
Date: Thu, 10 Nov 2011 10:06:07 +0100

Dave

My bibles say

Type(face) Family; Courier, Futura, Century Schoolbook,  ..
Typeface; one of the above with a defined
 - Style: Roman, Italic
 - Weight: Light, Semibold, Bold, ...
 - Width: Ultracondensed, Condensed, Expanded, ...
Type Font; one of the above with a defined Size
 - eg 12-point

I always think that the developers of the world's most widely used word
processing software do not understand this, when they try to persuade me to use
a different Type Family for my running heading and my running footing, which is
a glorious way of making a document really ugly, but in a way that is quite hard
to detect. Mixing Typefaces is fine, mixing families is not.

Tom Petch

p.s. I am sometimes (well, often) told I am too pedantic, but I think that a
virtue with standards:-)

----- Original Message -----
From: "Dave CROCKER" <[email-masked]>
To: "Martin J. Dürst" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, November 10, 2011 5:36 AM

> Anyway, what we are looking at is to have media types for font formats.
Typeface

mumble.

d/
--

   Dave Crocker

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 19:47:29 +0900

> Type Font; one of the above with a defined Size

As I said before in a mail to Dave, the last point worked well for lead 
type or bitmap fonts, but technology has moved beyond.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 10 Nov 2011 20:09:34 +0900

Hello Ned,

> is someone more familiar with it sohuld be consulted on possible issues.

Who would we contact to check about this?

> back on top-level type choices, usually successfully and always amicably.

Do you know of any examples? This could help Dave with the general list 
of criteria that he wants to develop.

Regards,    Martin.

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Nov 2011 12:24:05 +0100

On 10 November 2011 10:06, t.petch wrote:

> I am sometimes (well, often) told I am too
> pedantic, but I think that a virtue with
> standards:-)

+1

Here's my obviously stupid question:  Mostly I'm
happy with the fonts shipped with my current OS.

Therefore I'd like a font/* only for the purpose
of a "do not font me" HTTPbis feature, same idea
as "do not track me" (with 5 GB per month at a
reasonable download speed I don't want nonsense.)

Actually I'd like a real Courier instead of the
horrible "new courier", or a real Helvetica, as
I had it on OS/2 (supplied by Adobe).

Out of curiosity an "Everson" mono would be also
nice, but sadly I know that this would a copyvio.

And I'd be interested in these three fonts only
once.  For the roughly 200,000 Unicode points.

How is the font/* magic supposed to work, does
cover only code points for a specific document?

-Frank (likes Tahoma and Palatino Linotype)

---

From: Ned Freed <[email-masked]>
Date: Thu, 10 Nov 2011 08:23:15 -0800 (PST)

> Who would we contact to check about this?

SDP, aka application/sdp, defined in RFC 4566, was a product of MMUSIC. Back
when this came up previously I think Spencer Dawkins, Jon Peterson, and maybe
Colin Perkins were the ones we talked to? Sorry, this was almost 10
years back.

> of criteria that he wants to develop.

I can't get into specifics without talking about the content of
preliminary registration requests, which I try not to do. I can say that
the most common one has been someone asking for application when image or
video would be more appropriate.

The most common name change I request, however, is the addition of +xml.

				Ned

---

From: "t.petch" <[email-masked]>
Date: Thu, 10 Nov 2011 18:05:32 +0100

----- Original Message -----
From: "Frank Ellermann" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; "Martin J. Dürst" <[email-masked]>;
<[email-masked]>
Sent: Thursday, November 10, 2011 12:24 PM

<snip>
> cover only code points for a specific document?

I don't know what the proposal is.

What I see at present is that when I access certain web sites, I get a message
saying the my machine has not got the fonts installed to view the web site
properly and would I like the web site to instal some more for me.  NO WAY.  I
decide what and when I instal on my machine from where.  But I am curious, and
might try it when I have machine ready to be trashed, as to just how it would do
it.  I am assuming it would try to instal a .ttf file in  a suitable directory
(which I would expect to fail unless it is a temporary file).

I did ask the maintainers of the web site what was going on, and they had not a
clue.  My guess would be something Chinese or Korean (although the web site is
not).

Tom Petch

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 11 Nov 2011 16:27:50 +0900

> The most common name change I request, however, is the addition of +xml.

Okay. This is about change from one existing top-level type to another, 
and about tweaking the minor type name with a suffix. Out of the context 
of the discussion, I thought that you were speaking about new top-level 
types when you wrote "I have not infrequently pushed back on top-level 
type choices", but now I see that that's not a necessary interpretation.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 11 Nov 2011 17:13:13 +0900

> clue.  My guess would be something Chinese or Korean (although the web site is

To look at this case, it would help if you would tell us what your 
browser was, and what websites they were.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 11 Nov 2011 18:24:53 +0900

Hello John,

> quite as strongly about that as I did seven years ago (although

On the page I pointed to before, at 
http://en.wikipedia.org/wiki/Category:Font_formats, I count 24. Of 
course, we don't know how many of these may get registered, but there's 
a good chance it will be more than half a dozen.

> out and create a bunch of them

And we haven't, and we aren't proposing to.

> -- application/ was really
> video, and images.

And application/pdf, and application/msword, and lots of other stuff. 
These days, software may kindly ask whether the user agrees, so that 
they can disclaim responsibility for macro viruses, but that's about the 
only difference.

> Fonts are used to build tables that are then
> to application/

It isn't necesarily. Except for the special case font editors, fonts are 
used as auxiliary documents. They make the main document look more 
pretty, but without the actual text that uses the font, they are rather 
useless.

> or, as I suggested in 2004, represents a

You have brought up "should be generalized" in 2004, and you are 
apparently still believing in it. Can you please, please give a single 
concrete example of what you think should be thrown together with fonts 
so that we can claim that it has been generalized?

> answers of "use application/".

You made a request for generalization. What if people come back and say: 
"Sorry, fonts are fonts, we don't see any way to generalize them without 
getting overly metaphysical and therefore useless."? Or even more 
direct, say "what the hell are you talking about"? (frankly, I'd like to 
know, too)

> application/ was a bad idea", I, at least, would find that

I have absolutely no inside knowledge, but one plausible story would be 
that somebody at Netscape told Bitstream that they better had a 
registered type for their format, and Bitstream did what they thought 
they could get through most quickly. But that's a wild guess.

As Ned has explained in quite a bit of detail, for most software 
purposes, you could register a font format under video/, or an audio 
format under image/, and sofware wouldn't care because it uses composite 
strings. But the problem is that that looks wrong to humans.

> more of them without considerable justification.

So are you saying that we have image/ just because it already exists, 
but it wouldn't have a chance these days (or at least it would have to 
undergo much, much more scrutinity these days than when it was defined 
originally)?

> specified these things would be a big help here.

I don't think there is a need for a different handling or definitional 
model for temporary versus permanent installations. These are not 
questions for transmitting the font, but questions that differ by 
OS/rendering engine,...

And there are many aspects that are quite similar (if not the same) as 
for images. If somebody receives a mail with images included or 
attached, then these images shouldn't be permanently "installed" (i.e. 
saved) on the machine, they should go away when the mail is deleted 
(unless they have been saved separately). Most mailers do a reasonable 
job for this (but not necessarily a perfect one). But I haven't seen any 
details about this in the description of the image/ top level type. So 
why would we need it for font/?

> I said before that I've got a relatively open mind about this.

Great.

> architecture, not just a string of characters.  YMMD.

Oh, so what's the "architecture" for image/? From what you have written 
about fonts, I'd expect all image types to have parameters for width and 
height, maybe pixel aspect ration, and so on. Looking at 
http://tools.ietf.org/html/rfc2046#section-4.2, I can find none of that. 
Same for audio/, and video/.

Maybe there's actually a good reason for that. And maybe that's that 
these formats are self-describing, because they get bounced around in 
many contexts (in particular the file system) where they need to be 
self-describing, because there's no place to store additional parameters.

And maybe, and just maybe, the same thing actually could apply to fonts.

So I don't really understand why we need an "architecture" for font/. If 
it turns out there are some common parameters than (optionally) make 
sense, then why not have them. There are some in 
http://tools.ietf.org/html/draft-singer-font-mime-00, and we can review 
and tweak that.

> people to believe that they will figure it out because they are

I should have been more precise. I didn't mean people who are "font 
experts" just because they are good at using fonts, or because they 
design fonts. I meant font experts who understand the various formats, 
maybe even have helped design one or two, define standards for formats, 
implement these, write converters between formats, and so on.

> I don't think anyone has suggested that.  Certainly I haven't.

But much of what you write looks pretty close to it, at least from the 
outside.

> about obstructions and problems.

When I wrote "tried before", I specifically meant the font/ top level type.

> and to be sufficiently comprehensive.

"or even an application/ subtype"? Now I really don't understand things 
anymore. There are well-defined font formats that work on millions and 
millions of computers (and soon probably more than that number of 
smartphones), have published specifications and several independent 
implementations including open-source ones. What exactly do you want to 
"examine" before we allow them to be registered?

Regards,   Martin.

---

From: Ned Freed <[email-masked]>
Date: Fri, 11 Nov 2011 12:46:27 -0800 (PST)

> and about tweaking the minor type name with a suffix.

Understood. Both things happen. As I said, the most common top level change
is from application to image or video. Next up would probably moves from
text to application, but come to think of it I haven't have one of those
in a while.

> Out of the context

I was simply noting that the most common change isn't a top-level change, but
rather the addition of +xml. My apologies if that was confusing.

				Ned

---

From: Graham Klyne <[email-masked]>
Date: Sat, 12 Nov 2011 08:14:58 +0000

On 10/11/2011 01:47, "Martin J. Dürst" wrote:
> Then why do we have image/, audio/, and video/? application/ would be perfectly
> adequate for them, wouldn't it?

My supposition (and this is probably no more than post-hoc rationalization) was 
that the top level types were available for routing messages to an appropriate 
client, which might be a different device in a multimodal environment.  E.g. 
text/* to device that handles text, image/* to one that handles static images/*, 
similarly for audio/* and video/*.

Application/* then becomes appropriate for any content that doesn't depend on 
any particular presentation capabilities or modalities.

Interestingly, model/* has been mentioned in discussion as an example.  With 
increasing use of personal 3D printing (cf. http://reprap.org and spinout 
projects), I think it's a top-level type who's time is coming.  (I've even 
wondered about an update for RFC 1437...)

Of course, it all hinges on why we have top-level types at all.  From, a purely 
taxonomical perspective, I think a strictly 2-level hierarchy is always going to 
call for some arbitrary choices.

#g

---

From: "t.petch" <[email-masked]>
Date: Sat, 12 Nov 2011 12:27:50 +0100

----- Original Message -----
From: "Martin J. Dürst" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, November 10, 2011 11:47 AM

> type or bitmap fonts, but technology has moved beyond.

Martin

The concepts have not changed and remain useful, IMO, in any discussion
on presentation.  What has changed is the implementation detail so when
I download a new package to my PC, then it will apply to all Fonts, within
a Typeface, as opposed to having a separate module for each Font.
(Incidentally, my bibles all relate to laser printing ie to modern technology
and have nothing to do with lead:-).

But more significantly, as other posts have clarified for me, this thread
is nothing to do with fonts but with type definition languages, so perhaps
it should be 'type/*'.

Tom Petch

---

From: Tony Hansen <[email-masked]>
Date: Sat, 12 Nov 2011 19:57:01 -0500

On 11/12/2011 6:27 AM, t.petch wrote:
> From: "Martin J. Dürst"<[email-masked]>
> To: "t.petch"<[email-masked]>
> Cc:<[email-masked]>;<[email-masked]>

I've seen several hints of wanting to do web Accept-style queries along 
the line of

     Accept: font/arial, font/comicsans

What is it that is really desired?

While this sounds like it might be a nice capability, it really doesn't 
agree with what media types are all about. The Arial font can be 
described in many different font file formats.

Media types are more for describing things like:
     MMMM/datafork-truetype
     MMMM/intellifont
     MMMM/postscriptfont
     MMMM/truedocfont
     MMMM/truetype
     MMMM/webopenfont

(where MMMM is some prefix yet to be determined), within which you can 
have a description of many different fonts, including Arial and ComicSans.

=======

*IF* we were to define a top-level media type, I do *not* think it 
should be named "font", but instead should name it "fontformat" or 
something like that. I think naming it "font" just leads people to have 
false expectations.

=======

I notice that if "application" were used for font format file names, 
some of the font format names would need to include the word "font" as 
part of the name. For example, "application/postscript" can not be used 
for the font format defined in the postscript standard. Instead, it 
would have to be "application/postscriptfont". This *could* be taken an 
argument for using "fontformat" as a top level type, as in 
"fontformat/postscript". However, I don't find it a convincing argument 
by itself.

     Tony Hansen

---

From: Julian Reschke <[email-masked]>
Date: Sun, 13 Nov 2011 11:11:27 +0100

> something like that. I think naming it "font" just leads people to have

Doesn't this also argue for "imageformat" and "videoformat"?

Best regards, Julian

---

From: TianLinyi <[email-masked]>
Date: Sun, 13 Nov 2011 12:02:27 +0000

why not define something like this:
application/fontformat-arial

define a top level type may not be needed

_______________________________________
发件人: [email-masked] [[email-masked]] 代表 Tony Hansen [[email-masked]]
发送时间: 2011年11月13日 8:57
到: [email-masked]
主题: Re: [apps-discuss] font/*

=======

=======

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Sun, 13 Nov 2011 09:30:11 -0500

Certainly not. My argument is that "font" is a bad name because of its 
overloaded connotations -- I'm not arguing *for* any particular 
replacement for it. Any of "fontformat", "fontdl", and others would be 
better than just "font".

     Tony Hansen

---

From: Tony Hansen <[email-masked]>
Date: Sun, 13 Nov 2011 09:33:27 -0500

application/fontformat-truetype perhaps, but certainly not
application/fontformat-arial.The first is a media format, whereas the
latter mixes in a non-concrete look and feel.

Tony Hansen

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 13 Nov 2011 13:06:18 -0500

On Nov 12, 2011, at 3:14 AM, Graham Klyne wrote:

> Interestingly, model/* has been mentioned in discussion as an example.  With increasing use of personal 3D printing (cf. http://reprap.organd spinout projects), I think it's a top-level type who's time is coming.  (I've even wondered about an update for RFC 1437...)

IANA already has 14 subtypes of model registered, so it's time may already be here.  But as one of the authors I agree that RFC 1437 is getting a bit long in the tooth.  (There are now so many better examples than Dan Quayle!)  Perhaps I can get a revision together over the next, I don't know, 4 1/2 months....

> Of course, it all hinges on why we have top-level types at all.  From, a purely taxonomical perspective, I think a strictly 2-level hierarchy is always going to call for some arbitrary choices.

Absolutely.  I always viewed it as a pragmatic compromise between a flat namespace and an unbounded tree.  There were good reasons not to want either of those, while everyone seemed able to live with the two-level system, albeit while endlessly bickering over the details. -- Nathaniel

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Nov 2011 16:31:34 +0900

Hello Tom, others,

> is nothing to do with fonts but with type definition languages, so perhaps

Perhaps it should be type/* or fontformat/* or whatever. But most 
probably it should be font/. Because the people who are working on this 
repeatedly have asked for font/*, and never for type/*, and never for 
fontformat/* or some such.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 14 Nov 2011 16:36:00 +0900

> Accept: font/arial, font/comicsans

Where did you see that?

> While this sounds like it might be a nice capability,

It's a nice capability, but it's something for search engines, not for 
content negotiation.

> it really doesn't
> agree with what media types are all about.

Of course not.

> The Arial font can be

I don't think so. At least once there are a few registrations, things 
should be clear. As Julian pointed out, it hasn't be a problem for 
image/, video/, ...

Regards,    Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Nov 2011 16:09:18 +0800

On 11/12/11 4:46 AM, Ned Freed wrote:
>> >> > problem. Speaking now as media types reviewer, I have not
>> infrequently
>> >> > pushed

I notice that draft-freed-media-type-regs-01 talked about structured 
type name suffixes (e.g., "+xml") and calls for creation of a registry 
for such suffixes. Ned, do you have thoughts on how people can more 
easily define such suffixes, before draft-freed-media-type-regs (or 
something like it) is approved? The reason I ask is that I've had a few 
people ask me about this topic recently.

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Vinayak Hegde <[email-masked]>
Date: Mon, 14 Nov 2011 13:55:18 +0530

> define a top level type may not be needed

Media-types define the type (font/fontformat). Combining a value
(Arial) for creating a mime-type is asking for disaster.

Typically mime-types are used to identify application associations,
you will have to create an association for every single font on your
system. Now imagine adding a font using this scheme.

-- Vinayak

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 10:13:29 -0800 (PST)

> fontformat/* or some such.

If that's indeed what they asked for, then +1.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 14 Nov 2011 14:10:33 -0800 (PST)

> something like it) is approved?

Well, right now there is no process. RFC 4288 has some weasel-words about
"using +sufffixes with care", so as reviewer that's what I do - I've allowed
types with +json and +wbxml, I believe, but given the language I haven't felt
comfortable asking people to add anything other than +xml to types that
had no suffx.

I don't recall pushing back on any suffix usage, but I may have - I've reviewed
a lot of types!

> The reason I ask is that I've had a few

Well, the preferable thing would be to get the process Tony defined that I
included in 4288bis approved. Absent that, the rule is more or less that you
can use a suffix if you like and if it seems to make sense.

				Ned

---

From: "t.petch" <[email-masked]>
Date: Tue, 15 Nov 2011 10:18:22 +0100

----- Original Message -----
From: "Martin J. Dürst" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Frank Ellermann" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, November 11, 2011 9:13 AM
> browser was, and what websites they were.

Indeed, I intend to do so, but the most recent example, when accessing
https://catalogue.library.manchester.ac.uk/login?message=borrowerservices_notlog
gedin&referer=https%3A%2F%2Fcatalogue.library.manchester.ac.uk%2Faccount
only occurs once I have entered my userid and password, and you
may not be surprised to learn that I do not intend to disclose that
information by e-mail.

My memory is that I have seen it on other pages on that host and will
continue to look for one and post it as and when I find it.

My browser is Internet Explorer 6.0 but I suspect that it is the Fonts
directory in Windows that is lacking either a 'font' or more likely, some
code points in a font (I do get displays of Russian and CJK characters
which I did not on older software).  One thing I link to this is the
display I get on the Subject: line of some e-mails, on lists such as
MPLS-TP, from users with a Chinese affiliation, where the line
displays with many underscores, whereas at an Internet cafe,
looking at the archives, as one does, I get CJK characters instead,
probably a language variant of 'Re: '.
My MUA does not generate messages about wanting to download
'fonts'.

Tom Petch

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 05:40:18 +0800

On 11/15/11 6:10 AM, Ned Freed wrote:
>> >> >> > In practice the issue of what to register where has never been
>> much
>> >> >> of a

Thanks for the clarification. I agree that the right place to define
this more carefully is 4288bis. In the meantime, let's say that someone
wants to register "application/foo+bar" -- do we feel that they need to
describe the "+bar" suffix in a separate specification, or can they
simply go ahead and use the suffix in the I-D that registers the "foo"
application, perhaps along with some explanatory text?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Ned Freed <[email-masked]>
Date: Tue, 15 Nov 2011 16:00:37 -0800 (PST)

> > included in 4288bis approved. Absent that, the rule is more or less that
> > you can use a suffix if you like and if it seems to make sense.

> this more carefully is 4288bis.

Yes, and that text is already in 4288bis. Please have a look and see if you
think it is OK - there have been very few comments on it.

 In the meantime, let's say that someone
> application, perhaps along with some explanatory text?

I'd reccomment including some explanatory text saying where the format
associated with the suffix is defined, but I see no need for a separate
specification. In fact the 4288bis approach is specifically intended to make a
separate specification unnecessary.

				Ned

---

From: Larry Masinter <[email-masked]>
Date: Tue, 15 Nov 2011 18:14:47 -0800

I believe that the suffix +xml has an important function as an indicator that the body of the content is suitable for generic XML processing, for example, in the use of XPointer as a fragment identifier, and the ability to use a generic XML parser to scan the content. The expectation is that Media types that end in +xml are, in fact, restricted to only contain content that fits, and that RFC 3023 (and RFC 3023bis in preparation) defines that meaning and establishes that requirement.

The URI specification defers the interpretation of fragment identifiers (#xxx at the end of a URI) to the definition of the media type of the retrieved content.

The reason for holding back on other +xxx typename suffix is only to insure that there is a clear definition for what expectation there might be for common processing techniques and fragment identifiers....  that is, there is an operational requirement and definition, not just a vague "feel good".

So, for example,  type/subtype+json content labeled with a +json media type should be restricted, for example, to content that can be updated with json-patch PATCH operations, and generic json processing.

I think a separate specification for what the generic processing requirements and compatibility should be strongly recommended. It's not just a "feel good sounds right" matter.

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ned Freed
Sent: Wednesday, November 16, 2011 8:01 AM
To: Peter Saint-Andre
Cc: Ned Freed; [email-masked]
Subject: Re: [apps-discuss] type name suffixes

> > > The reason I ask is that I've had a few people ask me about this 
> > > topic recently.

> > Well, the preferable thing would be to get the process Tony defined 
> > that I included in 4288bis approved. Absent that, the rule is more 
> > or less that you can use a suffix if you like and if it seems to make sense.

> this more carefully is 4288bis.

Yes, and that text is already in 4288bis. Please have a look and see if you think it is OK - there have been very few comments on it.

> wants to register "application/foo+bar" -- do we feel that they need 
> to describe the "+bar" suffix in a separate specification, or can they 

I'd reccomment including some explanatory text saying where the format associated with the suffix is defined, but I see no need for a separate specification. In fact the 4288bis approach is specifically intended to make a separate specification unnecessary.

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 10:25:34 +0800

On 11/16/11 10:14 AM, Larry Masinter wrote:

> I believe that the suffix +xml has an important function as an
> indicator that the body of the content is suitable for generic XML
> processing, for example, in the use of XPointer as a fragment
> identifier, and the ability to use a generic XML parser to scan the
> content. The expectation is that Media types that end in +xml are, in
> fact, restricted to only contain content that fits, and that RFC 3023
> (and RFC 3023bis in preparation) defines that meaning and establishes
> that requirement.
> 
> The URI specification defers the interpretation of fragment
> identifiers (#xxx at the end of a URI) to the definition of the media
> type of the retrieved content.
> 
> The reason for holding back on other +xxx typename suffix is only to
> insure that there is a clear definition for what expectation there
> might be for common processing techniques and fragment
> identifiers....  that is, there is an operational requirement and
> definition, not just a vague "feel good".
> 
> So, for example,  type/subtype+json content labeled with a +json
> media type should be restricted, for example, to content that can be
> updated with json-patch PATCH operations, and generic json
> processing.
> 
> I think a separate specification for what the generic processing
> requirements and compatibility should be strongly recommended. It's
> not just a "feel good sounds right" matter.

Larry, that is helpful.

To be clear, the two suffixes I've seen interest in are:

+json = <http://tools.ietf.org/html/rfc4627>

+exi = <http://www.w3.org/TR/2011/REC-exi-20110310/>

We do need to take these on a case-by-case basis and we need to define
them clearly, but I doubt that we will see a flood of them.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 16 Nov 2011 03:45:35 +0100

>+exi = <http://www.w3.org/TR/2011/REC-exi-20110310/>

(I was under the impression the W3C had decided against "+exi" suffixes,
and instead use the "exi" content coding as the specification there re-
commends. I'd rather not duplicate all "+xml" entries with "+exi" types)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 10:59:10 +0800

> commends. I'd rather not duplicate all "+xml" entries with "+exi" types)

So, let's say I have "foo" data that can be represented in either plain
old XML or as EXI. If I send that "foo" data as plain old XML, the
"application/foo+xml" media type is right. If I send that "foo" data as
EXI, the "application/foo+exi" media type seems wrong, and so does the
"application/exi" media type (just as "application/xml" would not be
right for the first encoding). Sure, I don't particularly want to
duplicate all "+xml" entries with "+exi" entries, but I don't think that
every protocol or community that sends around XML data will also send
around EXI-encoded data.

But I freely admit that I might be missing context or historical
information about the W3C's decisions in this area.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 16 Nov 2011 04:06:42 +0100

>every protocol or community that sends around XML data will also send

The idea is that "EXI" is more like "gzip", so with HTTP you would do

  Content-Type: application/foo+xml
  Content-Encoding: exi

As you would for gzip-compressed content.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 16 Nov 2011 11:14:48 +0800

> As you would for gzip-compressed content.

Right. We did something similar for SVG, where there is a gzipped
encoding but not a separate media type for svgz.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Zach Shelby <[email-masked]>
Date: Wed, 16 Nov 2011 11:21:25 +0800

> As you would for gzip-compressed content.

Ouch, don't do that. 

The main interest right now for EXI is in constrained networks, and in particular over CoAP. We don't have support for indicating content-encoding in CoAP. Besides, the current media type for EXI is application/exi. Thus it would make perfect sense to have +exi entries. Furthermore, EXI is totally different than gzip, which is a generic encoding that can be applied to anything. EXI can be applied only to XML objects, and in particular EXI is often used in a schema mode where it is only applicable to a single schema. Thus the form application/schema+exi makes even more sense, as that EXI format is actually specific to that particular schema and the media type tells you everything that is needed to decode the representation. 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Nov 2011 22:13:32 -0600

On 15/11/2011, at 9:21 PM, Zach Shelby wrote:

> Ouch, don't do that. 
> 
> The main interest right now for EXI is in constrained networks, and in particular over CoAP. We don't have support for indicating content-encoding in CoAP.

Maybe it should be added?

> Besides, the current media type for EXI is application/exi. Thus it would make perfect sense to have +exi entries. Furthermore, EXI is totally different than gzip, which is a generic encoding that can be applied to anything. EXI can be applied only to XML objects, and in particular EXI is often used in a schema mode where it is only applicable to a single schema. Thus the form application/schema+exi makes even more sense, as that EXI format is actually specific to that particular schema and the media type tells you everything that is needed to decode the representation. 

These arguments were part of the discussion during EXI, and W3C decided to use a content-coding.

Cheers,

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Nov 2011 12:42:44 +0800

> Maybe it should be added?

YAGNI.
(Or, in terms of Monday's plenary, "fluff".)

> These arguments were part of the discussion during EXI, and W3C decided to use a content-coding.

Maybe we need to interpret CoAP's Content-Type option to stand for a pair of a media-type and a content-coding.

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Nov 2011 22:45:03 -0600

> (Or, in terms of Monday's plenary, "fluff".)

Uh huh.

> Maybe we need to interpret CoAP's Content-Type option to stand for a pair of a media-type and a content-coding.

Wow.

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 16 Nov 2011 12:47:49 +0800

> These arguments were part of the discussion during EXI, and W3C decided to use a content-coding.

The W3C standard defines application/exi here 

http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration

Zach

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Nov 2011 22:50:24 -0600

> http://www.w3.org/TR/2009/CR-exi-20091208/#mediaTypeRegistration

Yes, and they register the content coding right above that. 

Just because they registered a generic media type, it doesn't follow that automatically creating +exi media types for everything is a good idea.

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