Glass to Glass Internet Ecosystem URI and S-NAPTR Use
draft-daigle-deen-ggie-uri-snaptr-00

Abstract

This document defines the URI scheme "median" for "media networks" as defined in the Glass to Glass Internet Ecosystem work, as well as the necessary components to resolve median URIs using the S-NAPTR system.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 23, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Terminology
• 2. Introduction
• 3. The role and purpose of the median URI
• 4. median URI scheme definition
• 5. Use of S-NAPTR for GGIE
• 5.1. S-NAPTR components
• 5.2. S-NAPTR example
• 5.3. After S-NAPTR...
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Introduction

This document specifies the "median" URI scheme for the Glass to Glass Internet Ecosystem (GGIE -- see [I-D.deen-daigle-ggie]) media objects, as well as its use of S-NAPTR ([RFC3958]) to find Media Address Resolution Service (MARS -- to be described in a future Internet-Draft) servers for a given median URI.

N.B.: there are significant design decisions still under discussion for the overall GGIE technology approach. Depending on the outcome of those discussions -- e.g., on whether or how to determine the equivalence between two media objects -- the approach proposed in this document may be changed significantly. Consider the use of S-NAPTR and domain names as placeholder proposals.

3. The role and purpose of the median URI

The median URI scheme is used to find one or more Media Encoding Network (MEN) instances for a given media object, within the domain of a particular video distributor. (For a discussion of MEN, see the DASH MPEG MEN definition in [I-D.deen-naik-ggie-men-mpeg-dash]). Media objects are identified by industry-standard identifiers. This document specifies the use of EIDR ("Entertainment Identifier Registry") identifiers ([ISO26234]) for identifying video content in median URIs.

The components of the median URI are used to find the appropriate Media Address Resolution Service (MARS) server for the domain which is authoritative for that EIDR.

It is important to note that the median URI does not identify ALL instances of MEN for a given EIDR. Other domains may well have media encoding networks available for the video resource associated with the EIDR.

4. median URI scheme definition

This section fulfills the requirements for registration of the "median" URI scheme, per [RFC7595].

For now, it is assumed that the median URI scheme is not hierarchical and is opaque. As of this writing, it is assumed there is no need for relative URIs or queries and fragments as defined in the URI specification.

??? TBD: Re-read RFC7595 and make sure this document fulfills all requirements

The median URI scheme has two main components: the identifier of the media that is sought, and the domain that will serve it.

The intention is that existing media identifier schemes can be incorporated for use in the median URI scheme, rather than creating any new ones. Therefore, the part of the media URI that handles the media identifier includes an indicator of the identifier type as well as the identifier itself. In this document, we define the use "EIDR" identifiers.

There may be many different domains that serve a given media object, in one or more formats. The median URI includes the particular domain that should be consulted for the media network that has been identified.

The basic syntax of the "median" URI scheme is as follows:

   median-uri = "median:" + media-ID-type + ":" +  media-ID + ":" + media-domain
   media-ID-type = "EIDR" | <others to be defined later; 
	any valid URI character or percent encoded reserved character>
   media-ID = EIDR-ID | <to be defined later; 
	any valid URI characters or percent encoded reserved characters>
   EIDR-ID = "10.5240%2F" + Specific-EIDR
   Specific-EIDR = 1*EIDR-chars
   EIDR-chars = ALPHA / DIGIT / "-" / "." / "_"
   media-domain = <domain name for which to look for the MARS service>

For example, the following median URI would be used to find the MEN associated with the movie "Despicable Me" in the example.com domain:

	median:EIDR:10.5240%2F6933-25C9-299D-671A-24FB-V:example.com

5. Use of S-NAPTR for GGIE

This section outlines the use of the S-NAPTR approach for finding MARS servers for a given median URI. Consequently, it defines the MARS "application service" for S-NAPTR.

Note that this is one method of discovering relevant MARS servers. Other methods may be defined (e.g., approaches that work directly from within web browsers).

5.1. S-NAPTR components

The S-NAPTR components are as follows:

Application Unique String:

The Application Unique String used in S-NAPTR is the "media-domain" component from the median URI.

Application Service:

The Application Service is "MARS", for "Media Address Resolution Service".

Application Protocol:

Currently, the only S-NAPTR Application Protocol defined for use with the MARS Application Service is "http".

5.2. S-NAPTR example

For example, the MARS service for the URI "median:EIDR:10.5240%2F6933-25C9-299D-671A-24FB-V:example.com" could be found in the following NAPTR records: ??? need to update with appropriate protocol(s)

example.com.
   ;;       order pref flags
   IN NAPTR 100   10   "a"    "MARS:http"      (   ; service
                             ""                    ; regexp
                             mars.example.com.     ; replacement
                                               )
   IN NAPTR 100   20   "s"   "MARS:x-ldap"         ( ; service
                             ""                    ; regexp
                            _ldap._tcp.myldap.example.com. ; replacement
                                               )
   IN NAPTR 200   40   ""    "MARS:http"        ( ; service
                             ""                   ; regexp
                             someisp.example.     ; replacement
                                               )

The example above provides 3 possible next steps for MARS service.

1. The lowest ORDER and PREF service for the "http" application protocol for MARS service, and is available at "mars.example.com", so the next step is to look up the address record for that domain.
2. Alternatively, if the client wants to use the "x-ldap" application protocol for MARS, the next step is to look up SRV records at "_ldap._tcp.myldap.example.com".
3. Finally, an alternate (perhaps, backup) MARS service is available at "someisp.example". Since the FLAGS field is empty, the next step would be to look up NAPTR records for "someisp.example", to find available MARS services and protocols.

5.3. After S-NAPTR...

After using the S-NAPTR approach, the client should have a pointer to a usable MARS server, which can be queried for the relevant information about MEN for the EIDR in the median URI. That process will be covered in the MARS definition document.

6. Acknowledgements

Forthcoming.

7. IANA Considerations

There will be IANA considerations for the registration of the "median" URI scheme.

There will be IANA considerations for the registration of S-NAPTR application services and protocols -- MARS and ???.

8. Security Considerations

None (yet).

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses