Subject: Re: [media-types] Review request for application/emergencyCallData.eCall.MSD+per

From: Mark Baker <[email-masked]>
Date: Thu, 22 Sep 2016 09:54:45 -0400

Sec 4.2 of RFC 6838 describes the role of the period in subtypes;

"Characters before first dot always specify a facet name"

 -- https://tools.ietf.org/html/rfc6838#section-4.2

If you want to register in the standards tree, you'll need to do
something like change the period to something else, e.g. hyphens.
Alternately, you could just slap "vnd." on the front.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Sep 2016 10:11:43 -0700

>  Alternately, you could just slap "vnd." on the front.

Oops.  I should have known this, but didn't.  I'm sorry.  The problem 
in fixing this is that the current two drafts, which register the 
three new subtypes, are adding on to RFC 7852 
(https://tools.ietf.org/html/rfc7852), which registered the following 
MIME types:

	application/EmergencyCallData.ProviderInfo+xml
	application/EmergencyCallData.ServiceInfo+xml
	application/EmergencyCallData.DeviceInfo+xml
	application/EmergencyCallData.SubscriberInfo+xml
	application/EmergencyCallData.Comment+xml

These have been registered by IANA (e.g., 
https://www.iana.org/assignments/media-types/application/EmergencyCallData.ProviderInfo+xml), 
are referenced in several NENA documents, and I belive there are 
implementations.

We want the three new subtypes to follow the same pattern, which is 
that 'EmergencyCallData' is a parent and the various subtypes are 
children within that.

So, given this, how do we proceed?

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You can only protect your liberties in this world by protecting the
other man's freedom.  You can only be free if I am free.
    --Clarence Darrow

---

From: Randall Gellens <[email-masked]>
Date: Mon, 26 Sep 2016 15:44:13 -0700

At 10:11 AM -0700 9/22/16, Randall Gellens wrote:

>  Oops.  I should have known this, but didn't.  I'm sorry.  The 
> problem in fixing this is that the current two drafts, which 
> register the three new subtypes, are adding on to RFC 7852 
> (https://tools.ietf.org/html/rfc7852), which registered the 
> following MIME types:
>

I have a proposed solutions:

We treat "EmergencyCallData" as a parallel to a facet, since it 
serves an analogous purpose: it establishes a naming subspace that 
has a particular meaning.  Everything registered under 
Application/EmergencyCallData is for data sent with an emergency call 
and is eligible to be in the IANA Emergency Call Data Types registry. 
We can add text to one of the current two drafts to say so.  That 
draft might need to indicate that it updates Appendix A of RFC 6838 
to permit "EmergencyCallData." as a media subtype prefix, reserved 
for data sent during an emergency call.  We can say that this is not 
applicable in any other situation and is not a precedent.

-------------- Randomly selected tag: ---------------
As of 1992...the money that had been made since the dawn of
aviation by all of this country's airline companies was zero.
Absolutely zero.
    --Warren Buffett, billionaire investor, interview 1999

---

From: Mark Baker <[email-masked]>
Date: Tue, 27 Sep 2016 13:05:15 -0230

On Mon, Sep 26, 2016 at 8:14 PM, Randall Gellens
<[email-masked]> wrote:
>>  We want the three new subtypes to follow the same pattern, which is that
>> 'EmergencyCallData' is a parent and the various subtypes are children within
>> that.
>>
> We treat "EmergencyCallData" as a parallel to a facet, since it serves an
> analogous purpose: it establishes a naming subspace that has a particular
> meaning.

Yes, but it's meaning along an orthogonal axis.

It's surprising IANA would register those types without expert review.
I'll leave the larger process implications to somebody else to worry
about, but as a media type reviewer, I'm not too concerned as I've yet
to see a MIME/media-type library that consults or exposes the facet
(versus the suffix, which is commonly exposed).

But if these types are indeed in use in the wild, I would think we
have little option but to grandfather them in.

Mark.

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 Sep 2016 10:13:00 -0700 (PDT)

> It's surprising IANA would register those types without expert review.

These types were defined in an RFC (RFC 7852, to be specific). Such
registrations are reviewed by the IESG, which is free to request expert
review, but is not required to.

I suppose I should also look at RFCs-to-be to check for possible issues,
especially after the application/vnd.wav mess turned up, but honestly,
there are only so many hours in the day.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Tue, 27 Sep 2016 19:33:59 -0700

Hi Ned and Mark,

Thanks for the replies.

Does one of the drafts need to say that it updates Appendix A of RFC 
6838 to permit "EmergencyCallData." as a media subtype prefix, 
reserved for data sent during an emergency call?  Or add a statement 
without updating RFC 6838?  Or would IESG approval of the drafts be 
sufficient?

-------------- Randomly selected tag: ---------------
History teaches that grave threats to liberty often come in times of
urgency, when constitutional rights seem too extravagant to endure.
                                                 --Thurgood Marshall

---

From: Ned Freed <[email-masked]>
Date: Tue, 27 Sep 2016 23:49:15 -0700 (PDT)

> without updating RFC 6838?  Or would IESG approval of the drafts be

I'm a little unclear about what you're proposing here, so let me just outine
your options:

(1) You can keep using the existing names application/EmergencyCallData.*+xml
    as exceptions per Appendix A of RFC 6838. Future types won't be able to
    use this syntax, however.

(2) You can rename these types to something that doesn't have facet syntax and
    retain the old names as aliases. Future types will need to use the new
    syntax.

(3) You can write a document that specifies the EmergencyCallData registration
    tree per section 3.5 of RFC 6838? A standards action is needed to do this,
    and the document will need to cover all the points that RFC 6838 covers
    for the standards, vendor, personal/vantity, and unregistered trees.

				Ned

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 28 Sep 2016 13:39:59 +0000

Just so I’m clear on option 1 when you say “Future types” do you mean
future types that are “application.EmergencyCallData.*+xml” types, or
other types that use a period in the same way we’re using it for
EmergencyCallData?

Brian

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Sep 2016 07:44:30 -0700

Hi Ned,

To be clear, if we want to register the three new types as 
application/EmergencyCallData.*+xml we need option (3), which would 
establish the EmergencyCallData tree as an IETF tree?  We would need 
to indicate if it is possible to have vendor, private, and vanity 
facets under this, and indicate the rules for registered 
standards-related uses?  Or am I not understanding the option?

--Randy

-------------- Randomly selected tag: ---------------
Consultants are mystical people who ask a company for a number and then
give it back to them.

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Sep 2016 07:39:44 -0700 (PDT)

> other types that use a period in the same way we’re using it for

The problem is that x/y.z is reserved syntax that makes y a facet name. And
EmergencyCallData. is not (currently) a facet name. So we can either treat the
existing application.EmergencyCallData.*+xml as exceptions to this rule or
register EmergencyCallData as a facet name (option 3).

If we opt for the exception to the rule approach we can either leave
the registrations alone (option 1) or create new names for those types and
have the old names as aliases (option 2). If you do this future names
would need to be something like pplication.EmergencyCallData-*+xml.

Does this help?

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 28 Sep 2016 07:48:09 -0700 (PDT)

> establish the EmergencyCallData tree as an IETF tree? 

Yes, that's correct, although I can't speak to whether or not you'd 
want the tree restricted to the IETF.

> We would need

No, that's not what's needed. What you need to do is specify essentially what
the tree is for, who gets to use it, and so on. The same way that RFC 6838
specifies what the trees it defines are for and who gets to use them.

I know very little about these types generally, but given the name
I'm guessing that the rules associated with personal tree would not
be appropriate... Some variation of the rules associated with the standards
(unfaceted) tree would seem to make sense, but as I note above, you
need to decide who gets to use the tree, and the rule for the existing
standards tree (standards organizations recognized as such by the IESG)
may or may not be what you want.

				Ned

---

From: Randall Gellens <[email-masked]>
Date: Wed, 28 Sep 2016 08:15:52 -0700

At 7:48 AM -0700 9/28/16, Ned Freed wrote:

>  What you need to do is specify essentially what

Thanks very much for the clarification.  Probably the rule for the 
existing standards tree would make sense, perhaps with the addition 
of the IETF and an additional restriction that the standards body 
must be doing emergency services work.

Could this be added to one of the two current drafts that seek to 
register new application/EmergencyCallData.* types or would this need 
to be a new standalone draft?  Would the draft need to update RFC 
6838?

-------------- Randomly selected tag: ---------------
Miners Refuse to Work after Death
--Newspaper headline

---

From: Randall Gellens <[email-masked]>
Date: Fri, 30 Sep 2016 07:57:11 -0700

Hi Everyone,

Here is a proposed solution: add the following text to the "IANA 
Considerations" section of either of the two drafts that seek to 
register new application/EmergencyCallData.* subtypes:

----------
This document formalizes the "EmergencyCallData" media subtype tree. 
This tree is used only for media associated with emergency 
communications.  New subtypes in this tree can be registered by the 
IETF or by other standards organizations working with emergency 
communications, using the "Specification Required" rule, which 
implies expert review.  The designated expert is the ECRIT working 
group.
----------

-------------- Randomly selected tag: ---------------
Air Head Fired
--Newspaper headline

---

From: "HANSEN, TONY L" <[email-masked]>
Date: Fri, 30 Sep 2016 18:24:42 +0000

Hi Randy.

What you’re talking about is creating an additional “registration tree”, which is governed by RFC 6838 section 3.5:

       3.5.  Additional Registration Trees

          From time to time and as required by the community, new top-level
          registration trees may be created by IETF Standards Action.  It is
          explicitly assumed that these trees may be created for external
          registration and management by well-known permanent organizations;
          for example, scientific societies may register media types specific
          to the sciences they cover.  In general, the quality of review of
          specifications for one of these additional registration trees is
          expected to be equivalent to registrations in the standards tree by a
          recognized standards-related organization.  When the IETF performs
          such review, it needs to consider the greater expertise of the
          requesting organization with respect to the subject media type.

IMO, such a registration does NOT need to update RFC 6838. You could either make such a registration a separate RFC, or include it as part of an RFC creating those additional EmergencyCallData media types. My slight preference would be a separate RFC, but it certainly would not be required. Note that whatever RFC does it needs to be marked as standards track.

	Tony Hansen

On 9/28/16, 11:15 AM, "media-types on behalf of Randall Gellens" <[email-masked] on behalf of [email-masked]> wrote:

…