Subject: draft RFC to describe a URN for DTS audio

From: Phillip Maness <[email-masked]>
Date: Fri, 14 Feb 2014 22:34:45 +0000

Dear Sir or Madam,
Attached is a draft RFC describing the use of a namespace for DTS audio.
I have also submitted this as a draft RFC on https://datatracker.ietf.org/submit/
Please contact me at [email-masked]<mailto:[email-masked]> with any suggestions or editorial input to improve the draft RFC.
Best regards,
Phil Maness

Phillip Maness
Director, Corporate Strategy and Development
DTS, Inc
5220 Las Virgenes Rd
Calabasas, CA 91302
+1(818)436-1361 (office)
+1(818)519-1978 (mobile)
www.dts.com<http://www.dts.com/>

________________________________

Notice:
This message and any included attachments are intended only for the use of the addressee, and may contain information that is privileged or confidential. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy the original message and any copies or printouts hereof.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 17 Feb 2014 17:45:49 -0500 (EST)

What are the objects that these URNs name?  As far as I can tell, the
draft does not specify that.

It appears from the two examples that the objects are intended to be
parameters which are attributes of particular DTS audio encodings.  In
that case, it would seem that there will only be a small number (maybe
tens or hundreds) of these URNs that are valid.  If so, it may save
effort to have IETF allocate a sub-namespace,
"urn:ietf:params:dts:..." into which DTS can assign paramater URNs.
(See https://www.iana.org/assignments/params/params.xml and RFC 3553.)

Dale

---

From: Phillip Maness <[email-masked]>
Date: Wed, 19 Feb 2014 02:39:48 +0000

Hi Dale,
Historically, many 100's of millions of products containing DTS technologies over many 1000's of SKUs and hundreds of manufacturers have shipped worldwide. We have an extensive footprint in physical media, but we know that digital media and cloud services are quickly displacing this. We have publicly stated that this is our vision and where we are focusing our efforts.

Sorry, I have to be intentionally vague from this point on. We have a number of business activities in process so we have to consider customers, partners and competitors (and, of course, the financial community, as we are a publicly traded company). The nature of these disclosures in publications such as an RFC can be (intentionally or unintentionally) indicative, (or perceived as being indicative), of future business.

I will say that our prospects are considerably more extensive than audio parameters. Audio parameters were used as examples as they are fairly obvious to the current nature of our business. We have the potential for many thousands of references over multiple categories under the dts namespace.

While I can't put any more color to this in writing, I would be happy to schedule a phone conversation with myself and our VP of Streaming and Media Solutions to give you a better idea of how we plan to utilize this namespace. When would be a good time to schedule a call? Fridays are generally good for us.

Best Regards,
Phil Maness

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Monday, February 17, 2014 2:46 PM
To: Phillip Maness
Cc: [email-masked]
Subject: Re: draft RFC to describe a URN for DTS audio

What are the objects that these URNs name?  As far as I can tell, the draft does not specify that.

It appears from the two examples that the objects are intended to be parameters which are attributes of particular DTS audio encodings.  In that case, it would seem that there will only be a small number (maybe tens or hundreds) of these URNs that are valid.  If so, it may save effort to have IETF allocate a sub-namespace, "urn:ietf:params:dts:..." into which DTS can assign paramater URNs.
(See https://www.iana.org/assignments/params/params.xml and RFC 3553.)

Dale

Notice:

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 20 Feb 2014 13:40:40 -0500 (EST)

> From: Phillip Maness <[email-masked]>
> 
> Sorry, I have to be intentionally vague from this point on. We have
> a number of business activities in process so we have to consider
> customers, partners and competitors (and, of course, the financial
> community, as we are a publicly traded company). The nature of these
> disclosures in publications such as an RFC can be (intentionally or
> unintentionally) indicative, (or perceived as being indicative), of
> future business.

My first impulse was to say, "I doubt you're going to get much
traction with a proposal for a system of names if you're not going to
admit *what* they are naming."  But that is incorrect, as lots of
organizations have obtained URN NIDs for such generic use.

You may have some difficulty in that DTS is a business, and has no
purported public benefit purpose.  In my quick look at the NID
registrations that are essentially delegations to organizations, all
of the organizations are governments or industry consortia which have
public benefit purposes.  Granting a delegation to DTS would be
setting a precedent for delegation to a business (a straightforward
for-profit entity).  Certainly the question will be raised, "Will it
be possible to use one of these URNs in a context that does not cause
money to flow to DTS Inc."?

(I will note that there are several mechanisms by which DTS could
obtain an Object ID delegation, and there is no question that
businesses may do so.  Since all Object IDs correspond to URNs
(urn:oid:...), DTS can immediately obtain a URN delegation in that
manner.)

Comparing draft-pmaness-dts-urn-00 and the NID registrations for
"3gpp" (RFC 5279), "cablelabs" (RFC 6289), and "cgi" (RFC 5138), the
organizational delegation registrations seem to favor declarations
like "The registration tables and information will be published and
maintained by 3GPP on its web site."  I don't know if such a promise
of public information is critical to getting the NID approved, but it
would certainly help.

The whole of section 1 seems to be true but not actually relevant to
the namespace, as the proposed namespace doesn't seem to be
intrinsically tied to DTS audio formats (that just happens to be
everything that DTS Inc. is involved in right now).  I don't know what
would be a good replacement, but the truth seems to be "DTS has a lot
of irons in the fire, and we think that it would be useful if we could
assign URNs.  Though we have a lot of good ideas, we aren't entirely
certain what we would use them for yet."

In regard to the syntax, you need to specify that "category" may not
contain ":"; otherwise a URN can't be unambiguously parsed into
"category" and "string" components.

Dale

---

From: Phillip Maness <[email-masked]>
Date: Fri, 21 Feb 2014 02:12:48 +0000

Hi Dale,

Thanks for the additional insight, this is some very helpful dialog.

The primary use of this urn would by those providing services to devices that contain our technologies (products made by many different CE manufacturers), or devices connected to devices that contain our technology.

We don't derive revenue from service providers. Our revenues come from the device manufacturers who license our technologies. We also permit (in the case of audio codecs), devices to "pass-through" to downstream decoder at no cost. In this case, a device (such as a streaming service box or dongle) can advertise "inherited" features of a device downstream (e.g. an A/V receiver attached via. HDMI).

Our objective is to enable our customers, (or rather the consumers who purchase their products), the ability to derive greater benefit from the availability of our technology. This benefits us by making our technology more useful, but it also benefits our customers by expanding the use of features already available in their products, and benefits the consumer (their customer) by providing them a better entertainment experience.

So DTS' benefit is indirectly related to the use of the URN. I wouldn't go so far as to say that we will never directly benefit (financially) from the use of an assigned namespace, but I can't envision such a use case at this time.

I think this is consistent with how the industry consortia you cited use their namespace to benefit their members (for profit companies) to directly deriving benefit by selling services.

I'm sure my explanation above could be better worded, but is this usage better in line with the philosophy of ietf? Does this explanation help you? Would it be beneficial to add this usage explanation in section 5?

Thanks and best regards,
Phil Maness

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: Thursday, February 20, 2014 10:41 AM
To: Phillip Maness
Cc: [email-masked]; Mark R. Johnson
Subject: Re: draft RFC to describe a URN for DTS audio

> Sorry, I have to be intentionally vague from this point on. We have a
> number of business activities in process so we have to consider

My first impulse was to say, "I doubt you're going to get much traction with a proposal for a system of names if you're not going to admit *what* they are naming."  But that is incorrect, as lots of organizations have obtained URN NIDs for such generic use.

You may have some difficulty in that DTS is a business, and has no purported public benefit purpose.  In my quick look at the NID registrations that are essentially delegations to organizations, all of the organizations are governments or industry consortia which have public benefit purposes.  Granting a delegation to DTS would be setting a precedent for delegation to a business (a straightforward for-profit entity).  Certainly the question will be raised, "Will it be possible to use one of these URNs in a context that does not cause money to flow to DTS Inc."?

(I will note that there are several mechanisms by which DTS could obtain an Object ID delegation, and there is no question that businesses may do so.  Since all Object IDs correspond to URNs (urn:oid:...), DTS can immediately obtain a URN delegation in that
manner.)

Comparing draft-pmaness-dts-urn-00 and the NID registrations for "3gpp" (RFC 5279), "cablelabs" (RFC 6289), and "cgi" (RFC 5138), the organizational delegation registrations seem to favor declarations like "The registration tables and information will be published and maintained by 3GPP on its web site."  I don't know if such a promise of public information is critical to getting the NID approved, but it would certainly help.

The whole of section 1 seems to be true but not actually relevant to the namespace, as the proposed namespace doesn't seem to be intrinsically tied to DTS audio formats (that just happens to be everything that DTS Inc. is involved in right now).  I don't know what would be a good replacement, but the truth seems to be "DTS has a lot of irons in the fire, and we think that it would be useful if we could assign URNs.  Though we have a lot of good ideas, we aren't entirely certain what we would use them for yet."

In regard to the syntax, you need to specify that "category" may not contain ":"; otherwise a URN can't be unambiguously parsed into "category" and "string" components.

Dale

Notice:

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 21 Feb 2014 22:32:20 -0500 (EST)

Thanks for your recent thoughts.  Here are some more of my thoughts.
They are not organized into a particular proposal, but I think may
provide a guide to obtaining useful results.

I am having some difficulty orienting myself as to how to look at your
proposal.  One issue is that your proposal is (or at least appears to
be) completely commercial.  I don't think that is intrinsically bad,
but it is *different* from other namespace proposals.  And I think
that other people will see your proposal as *different* for the same
reason.

Backing up, I see that you would like a "formal" URN namespace, one
with a nice name, and not a "urn-<number>" name.  (RFC 3406)  That
makes sense to me.  But that does mean that the IESG will have to
approve the proposal as an RFC.  So there's a question of whether the
IESG will raise the questions that I am discussing.

I see a number of issues deriving from DTS's purely commercial status:

- There is an intention of commercial benefit, and less of a position
  of public benefit.

I don't see this as important, since many namespace assignments are
delegations to industry consortia.  The consortia are usually
non-profit, but their members are definitely businesses.

- Because the registrant is a business, it would be desirable if the
  delegation was done under a policy that was explicitly even-handed
  toward all businesses that might want a delegation.

- There are a *lot* of potential business registrants, leading to the
  possibility of "NID pollution", filling the registry with names to
  the point that new names that are meaningful would be difficult to
  assign.

- Businesses will likely desire an NID based on the business' name,
  making it harder to resolve conflicts regarding desired NIDs.

It seems to me that a good way to address these issues is to create a
single NID whose sub-NIDs are delegated to businesses.

At this point, let me use the term "enterprise" instead of "business".
"Enterprise" is used as a generic term for organizations in RFC 2578
and the IANA registry of "private enterprise numbers"
(https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers).

I can see at least three ways to handle all enterprises in a
systematic way:

- urn:enterprise:<enterprise-number>:<NSS>

This technique uses the existing private enterprise numbers to
identify the enterprise.

- urn:enterprise:<identifier>:<NSS>

This technique would create a new registry, from which enterprises
would allocate identifiers on a first-come basis.  The syntax of
<identifier> would probably be the same as <NID> in RFC 2141.

- urn:enterprise:<domain-name>:<NSS>

This technique uses the enterprise's domain name.  (There are a bunch
of details that are needed to make domain names permanent.  See
draft-ietf-salud-alert-info-urns-11 for how to do it.)

Using my consulting company (Ariadne Internet Services) as an example,
these techniques would produce:

- urn:enterprise:14490:nss

- urn:enterprise:ariadne:nss

- urn:enterprise:ariadne.com:nss, or
  urn:enterprise:ariadne.com(2012-01-01):nss

Perhaps this concept has been discussed in the URN working group and
they have already come to a decision.

Dale