Network Working Group D. Miller
Internet-Draft Tavis Software Inc.
Intended status: Informational December 9, 2015
Expires: June 11, 2016

Conference Talk Media Type
draft-miller-conference-talk-01

Abstract

This draft document is a media type specification for describing a conference talk proposals, presenters and presentations. This format aims to standardize the format of information shared between software components used by conference organizers, speakers and attendees. It is intended to reduce the effort required for speakers to submit session proposals and for conference organizers to process those submissions.

Note to Readers

The issues list for this draft can be found at https://github.com/darrelmiller/conference-talk/issues.

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 June 11, 2016.

Copyright Notice

Copyright (c) 2015 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. Introduction

In the technology world, one way we share knowledge is via conferences. In order to have a conference we need speakers to do talks. Conferences commonly go through a process called call for proposals (CFP) where speakers who are interested submit talk proposals to the conference and then the conference organizers sift through these proposals and select the talks they believe will provide the best value to their attendees.

There are a very wide range of methods used by conferences for collecting these proposals: Google docs, Excel spreadsheets, plain text emails, wikis, custom web sites, commercial conference management systems. Each of these systems have slightly different ways of collecting information that is mostly the same.

Many conferences are run by volunteers with minimal budgets and many speakers do so at their own expense. Any possibility to improve the efficiency of the process of submitting proposals and processing them could provide significant value to a large number of conference participants.

1.1. Goals

Easier for speakers to submit

Easier for conference organizers to process

1.2. Usage Scenarios

There are a wide range of scenarios that could be enabled by this common format:

1.3. Notational Conventions

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. Conference Talk JSON Document

The canonical model for a conference-talk document is a JSON object as defined in the I-JSON specification [RFC7493]. The properties of the JSON object can be any valid vocabulary term from this specification. Unrecognized vocabulary should be ignored unless a consumer explicitly requests strict processing of the document.

A minimal submission might look like this:

    { "proposal" : {
     "title" : "An Introduction To Media Type Design",
     "brief-description" : "Blah Blah Blah",
     "presenter" : {
       "name" : "Darrel Miller",
       }
      }}

A more complete proposal might look like,

{
  "proposal": {
    "title": "An Introduction To Media Type Design",
    "brief-description": "Blah Blah Blah",
    "full-description": "Even longer blah Blah Blah",
    "keywords": ["javascript", "java", "http"],
    "length": {
      "preferred": 60,
      "min": 45,
      "max": 90
    },
    "presenters": [{
      "name": "Darrel Miller",
      "email": "[email protected]"
    },
    {
      "name" : "Bob Brown",
      "email" : "[email protected]"
      }]
  },

  "past-presentations": [{
    "presentation-date": "20150911",
    "conference": "UberConf"
  }]
}

This specification is intended primarily to describe a message format that only exists to transfer information between two independent systems. It is not intended as a persistence format or a content creation format. JSON is ideal for this purpose. However, it should be fairly straightforward to apply the structure and semantics defined in this document to other formats.

3. Structure

This media type is designed to hold information related to conference proposals, their presenters and the presentations of those sessions. However, it imposes minimal structural constraints on the document. This is done in order to support as many scenarios as possible. A document instance may be used to submit a new proposal to a conference. Or it may be used to return a list of presentations that were held at a conference. It can also be used to return a list of presenters who will be speaking at a conference. The overall structure is fairly flexible, but the semantics of the named structures within the document are well defined.

A conference-talk document may be valid, but still incompatible with a particular resource that only accepts conference-talk documents structured in a certain way.

3.1. Root

The root of the document MUST be a JSON object, whose properties names are structures defined in this vocabulary.

    {
      "presenter" : {...} },
      "proposals" : [...] },
      "presentations" : [...] },
    }

There is no fixed structure to the root object. It can contain any number of properties that are either objects or arrays.

3.2. 1:1 Relationships

Certain structures can contain other structures in a 1:1 relationship. E.g.

3.3. 1:M Relationships

Lists of structures can be contained as an attribute of other structures to indicate a relationship between the structures. For example:

3.4. Links

All structures defined in this vocabulary can contain a property called links. This property contains an array of link objects. Links are a way to break apart pieces of the document for the purposes of reuse and controlling granularity. Through the use of relative URIs and fragments we can use links with the document to reduce redundancy.

links : [
          { "rel" : "",
            "href" : ""},
          { "rel" : "",
            "href" : ""}
          ]

Note: There was no need to adopt the HAL convention of using _Links as the allowed vocabulary is explicitly defined for this media type. The array of links was chosen instead of an object to allow multiple link relations of the same type without having to define multiple arrays.

3.4.1. link

3.4.1.1. rel

Link relations values defined in the conference-talk conference talk document can be used as simple strings as long as they are prefixed with a period. However, any parsing tool must map them to a URI using the following URI template https://tavis.net/rels/conference-talk/{relname}.

3.4.1.2. href

The href property can resolve to a relative URI and use relative fragment identifiers to point to content within the current document. Fragment identifiers follow the scheme defined by the JSON-Pointer specification. This prevents the need to duplicate content within a document.

For example, the sample below has an array of proposals, and each one points to a presenter structure and conference structure. ~~~~~~~~~~

{ "proposals" : [{
 "title" : "An Introduction To Media Type Design",
 "brief-description" : "Blah Blah Blah",
"links" [
  { "rel" : ".presenter", "href" : "#presenter"},
  { "rel" : ".conference", "href" : "#conference"}
]
},
{
"title" : "Crafting Evolvable Representations",
"brief-description" : "Double blah",
"links" [
  { "rel" : ".presenter", "href" : "#presenter"},
  { "rel" : ".conference", "href" : "#conference"}
]
},
],   "presenter" : {
  "name" : "Darrel Miller",
  "bio"  : "blah blah blah"
},   "conference" : {
  "name" : "The Meta Conference",
  "description"  : "The conference about conferences"
 }
}

~~~~~~~~~~

4. Vocabulary

4.1. Arrays of Structures

4.1.1. proposals

An array of proposal structures.

4.1.2. presentations

An array of presentation structures.

4.1.3. presenters

An array of presenter structures.

4.1.4. conferences

An array of conference structures.

4.2. proposal

The proposal structure represents a description of a single conference session. The only required property of the proposal structure is the title property.

4.2.1. title

The title property is a single sentence description of the talk, normally used as a heading. This is a required property. Physical limits on the size of descriptive fields like this one are left to the choice of implementers. If a specific implementation chooses to limit titles to 80 characters and it subsequently receives a document with a title that exceeds that amount, the implementation must choose whether to refuse the content, or to truncate it.

4.2.2. brief-description

Conferences often ask for short descriptions of sessions to be used on web sites or in promotional material. Some conferences insist on brief descriptions to reduce the time it takes for the selection committee to process the proposals. This specification currently does not enforce the size of a brief description and therefore there may be cases where a brief-description submitted to one conference is not accepted to another because they have differing opinions on what brief means. Feedback will drive whether a hard limit is included in this specification.

4.2.3. full-description

Sometimes a brief description is sufficient to spark interest in a talk, but the reader wishes to get more details. The full-description of the session can be used to go into detail about the presentation. Implementations can choose whether this description is made public or not.

4.2.4. selection-notes

It is common for proposals to have additional information that is only directed at the selection committee. This information would not be made public.

4.2.5. tags

The tags attribute contains an array of strings used for the purpose of classifying talks into categories. Although different conferences may use different sets of tags, in a communication between speaker and conference organizer, only one set of tags is valid. For client applications that might store conference proposals for speakers, it may be necessary to store multiple sets of tags to accomadate submissions to different conferences. However, this specification is not aiming to describe a storage format.

tags : ["testing","performance"]

4.2.6. target-audience

Conference sessions are often rated based on their technical difficulty.This property is numeric value on the scale of 1 to 5, where 1 indicates no experience is required to benefit from the session, to 5 which indicates the audience require a strong knowledge in the subject matter to fully appreciate the talk.

target-audience : 1

Conference organizers are free to map this range of values to whatever equivalent ranking scheme they use.

4.2.7. length

Different conferences have different sessions lengths. Sometimes the same conference has sessions of different lengths. It is not uncommon for speakers to have some flexibility in how long a particular talk can take. In order to accomodate these different scenarios, the length property is defined using three values : preferred-length,max-length and min-length. All three values are specified in integer minutes. By specifying a range, conferences can determine if a talk can fit into the planned slots.

length : {
  "preferred" : 45,
  "max": 60,
  "min" : 30
}

4.2.8. languages

Some conferences are multi-lingual and sometimes speakers are able to perform talks in multiple languages. The language property contains an array of language codes as described in [RFC5646].

language : ["en","fr"]

4.2.9. talk-style

Style is an identifier that classifies the type of talk being submitted. This value is a string identifier from a set of valid values as defined by the conference being submitted to.

talk-style : "workshop"

4.3. presenter

A presenter structure represents the information about a person who will or who has presented a conference talk.

4.3.1. name

The name attribute is a string value that contains the name of the present for purposes of displaying the name.

4.3.2. email

The email property

email = <addr-spec see {{RFC2822}}, Section 3.4.1>

4.3.3. airport

The home airport of the presenter. This information is used to approximate travel costs for speakers and aid in the selection process. This is a string value.

4.3.4. dietary-requirement

An identifier selected from the list of available values as defined by the conference. This is a string value.

4.3.5. t-shirt-preference

An identifier selected from the list of available values as defined by the conference. This is a string value.

4.4. presentation

The presentation structure is a historical record of a talk described by a proposal structure that has been presented at a conference.

4.4.1. presentation-date

This property represents the date that a particular talk was given. The date should be in ISO 8601 format as required by I-JSON.

4.4.2. conference

The name of the conference where the presentation was given. This is a string value.

4.4.3. location

The physical location where conference is being held. This can simply country or city and country. This is a string value.

4.4.4. special-requirements

This is a free form text field used to communicate to the conference organizers any special hardware, setup, or environmental requirements needed for this talk to be presented. This is a string value.

4.4.5. attendee-quantity

This field is a number that provides an approximate quantity of people who attended the presentation.

4.5. conference

The conference structure is used to describe its purpose, its location, the timeline of events and the domains of valid values for properties like, tags, talk-style and languages. It also can contain limits such as maximum lengths for brief-description, and full-description.

4.5.1. talk-style-domain

TK

4.5.2. tags-domain

TK

4.5.3. languages-domain

TK

4.5.4. brief-description-max-size

TK

4.5.5. full-description-max-size

TK

4.5.6. t-shirt-domain

TK

4.5.7. dietary-requirement-domain

TK

5. Link Relations

5.1. video-recording

This is a URL that points to a video recording of the presentation.

5.1.1. slides

This is a URL that points to a the slide deck used in the presentation.

5.1.2. presenter

This is a URL that points to the details relating to the presenter of the presentation.

5.1.3. presentations

This is a URL that points to a list of presentations.

5.1.4. conference

This is a URL that points to information about a conference.

6. IANA Considerations

6.1. Registrations

7. Security Considerations

8. Appendix 1 : Mapping to HTML

9. Appendix 2 : Mapping to ALPS

10. Appendix 2 : Mapping to SIREN

11. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, DOI 10.17487/RFC2822, April 2001.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009.
[RFC7493] Bray, T., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015.

Appendix A. Acknowledgements

Author's Address

Darrel Miller Tavis Software Inc. EMail: [email protected] URI: http://www.bizcoder.com