Network Working Group J.M. Snell
Internet-Draft October 21, 2013
Intended status: Informational
Expires: April 24, 2014

Additional Link Relations and the urn:social Namespace
draft-snell-more-link-relations-02

Abstract

This specification defines a number of additional Link Relation Types that can used for a variety of purposes.

Status of This Memo

This Internet-Draft is submitted to IETF 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 24, 2014.

Copyright Notice

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


Table of Contents

1. Introduction

This specification defines and adds the following additional link relation types to the IANA Registry of Link Relations established by [RFC5988]: to, bto, cc, bcc, from, bfrom, source, generator, provider, location, alias and mentioned-by. Further, this specification proposes a new 'social' URN namespace.

Note that this document is a work-in-progress draft specification that does not yet represent a "standard". It is the intention of this specification to propose a few new ideas and openly solicit feedback on their definition and use. While this document might eventually evolve into an RFC the ideas described herein have not yet been broadly implemented and have definitions that may evolve through successive iterations of this draft.

2. The 'social' URN Namespace

This specification defines the 'social' URN namespace having the following structure:

ABNF Grammar:

  social-url = "urn:social:" social-nss
  NZDIGIT    = %x31-39
  distance   = ":" NZDIGIT
  confidence = ":" 2DIGIT
  social-nss = "self" /
               "everyone" /
               "direct"   /
               ( "extended" [ distance ] ) /
               ( "peer" [ distance ] ) /
               ( "subordinate" [ distance ] ) /
               ( "superior" [ distance ] ) /
               ( "common" [ confidence ] ) /
               ( "interested" [ confidence ] ) /
               ( "role" ":" TOKEN )
      

Within any given social networking system, there is an available population of entities. Each NSS term represent specific subsets of this population and are defined in terms of these subsets relative to a fixed context. For example, if the fixed content is a person, the "urn:social:direct" URN identifies the subset of the total population that is directly connected to the context person within the social graph, while the "urn:social:extended" URN identifies the subset that is directly or indirectly connected to the context person.

The "extended", "peer", "subordinate", and "superior" NSS values MAY include an additional single digit non-zero "distance" specifier, whose value identifies a "degree of separation" from the link context. For instance, the URN "urn:social:extended:1" would identify members of the context's extended network that are only 1 degree of separation from the context (which is equivalent to the "urn:social:direct" URN). The value "urn:social:extended:6" indicates six degrees of separation from the context. If the distance is omitted from the NSS, no limit to the distance is assumed.

The "common" and "interested" NSS values MAY include a two-digit "confidence factor" whose value specifies a confidence interval an implementation can apply when determining which members of the total population ought to be considered. The values range from 00-99, corresponding to confidence intervals between 0% to 99%. If the confidence factor is omitted from the NSS, a confidence interval of 100% is assumed.

The "role" NSS value MUST include one or more semicolon ";" TOKEN delimited segments whose values identify specific named "roles" within the population. For instance, the URN "urn:social:role:editor" identifies all members of the relevant population who are assigned to the "editor" rolel. The URN "urn:social:role:reader;writer" identifes all members of the relevant population who are assigned to both the "reader" and "writer" roles.

The 'social' URN namespace is defined to be intentionally ambiguous and highly dependent on context. The specific interpretation of each NSS, including any distance or confidence specifiers, depend entirely on how and where the NSS is being used.

2.1. urn:social:everyone

The "urn:social:everyone" URN identifies the subset of the total population that is visible to the context.

2.2. urn:social:direct

The "urn:social:direct" URN identifies the subset of the total population that is both visible to and directly connected to the context.

2.3. urn:social:extended

The "urn:social:extended" URN identifies the subset of the total population that is visible to and connected either directly or indirectly to the context.

2.4. urn:social:peer

The "urn:social:peer" URN identifies the subset of the total population that is both visible to the context and considered to be a "peer".

Peer relationships exist only within populations in which there exists a hierarchical division of members in the population. An example of such a network would be a company or similarly structured organization. Peers might be directly or indirectly connected to the target resource but are considered to share the same hierarchical position.

2.5. urn:social:subordinate

The "urn:social:subordinate" URN identifies the subset of the total population that is both visible to the context and considered to be "subordinate" to the context.

Subordinate relationships exist only within populations in which there exists a hierarchical division of members in the population. An example of such a network would be a company or similarly structured organization. Subordinates might be directly or indirectly connected to the target resource but are considered to share a lower hierarchical position.

2.6. urn:social:superior

The "urn:social:superior" URN identifies the subset of the total population that is both visible to the context and considered to be "superior" to the context.

Superior relationships exist only within populations in which there exists a hierarchical division of members in the population. An example of such a network would be a company or similarly structured organization. Superiors might be directly or indirectly connected to the target resource but are considered to have a higher hierarchical position.

2.7. urn:social:common

The "urn:social:common" URN identifies the subset of the total population that is both visible to the context and is determined to share common attributes with the context.

Determination of "common attributes" is dependent entirely on the application. For example, an application might choose to use shared interests in a given topic as the "common attribute" binding a particular grouping of members.

2.8. urn:social:interested

The "urn:social:interested" URN identifies the subset of the total population that is both visible to the context and has an express interest in the context. Examples of members of the "interested" subset are those who have elected to "follow" the activity of the context resource.

2.9. urn:social:self

The "urn:social:self" URN identifies the context resource itself as a member of the total population.

2.10. urn:social:role:{tokens}

The "urn:social:role:{token}" URN identifies the subset of the total population that is both visible to the contexst and has been assigned to each of the individual roles identified within by the URN.

The values of the role tokens are specific to the context in which they are being used.

3. IANA Considerations

The following Link Relations are added to the IANA Registry of Link Relations.

Name Description
to Refers to a resource that is considered to be part of the public primary audience of the link's context.
bto Refers to a resource that is considered to be part of the private primary audience of the link's context.
cc Refers to a resource that is considered to be part of the public secondary audience of the link's context.
bcc Refers to a resource that is considered to be part of the private secondary audience of the link's context.
from Refers to a resource that is publicly considered to be the originator of the link's context.
bfrom Refers to a resource that is privately considered to be the orignator of the link's context.
scope Refers to a resource that identifies the total population of entities to which the context is relevant.
source Refers to the original source of information contained by the context resource.
provider Refers to the resource that provided the context resource. Typically, this would be used to identify the entity publishing the resource.
generator Refers to the resource that generated the context resource. Typically, this would be used to identify the software application that created the context resource.
mentioned-by Refers to a resource that mentions the context resource in some fashion. This, for example, would be used when an article mentions another article, or a social status update mentions a particular user, etc.
location References a URI/IRI that represents a physical or logical location with which the context resource is associated.

3.1. Relationship of 'to', 'bto', 'cc', 'bcc', 'from', 'bfrom' and 'scope'

The "scope" link relation is closely aligned with the so-called "audience targeting" link relations "to", "bto", "cc", "bcc", "from", and "bfrom" in that "scope" links identify the total population from which the audience is drawn.

4. Security Considerations

There are no additional security concerns introduced by this document.

5. Informative References

[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.

Appendix A. Examples

Using targeting link relations and the urn:social namespace:

    POST /alerts HTTP/1.1
    Host: example.org
    Content-Type: text/plain
    Authorization: Basic {Base64 Credentials}
    Link: <urn:social:everyone>; rel="to"
    Link: <urn:social:extended:2>; rel="cc"
    Link: <urn:social:self>; rel="bfrom"
    Link: <http://example.net/my-social-net>; rel="scope"
  
    Test message
      

Using the targeting link relations with urn:social:role:

    POST /alerts HTTP/1.1
    Host: example.org
    Content-Type: text/plain
    Authorization: Basic {Base64 Credentials}
    Link: <urn:social:role:moderator>; rel="to"
    Link: <urn:social:role:editor>; rel="cc"

    Test message   
      

Using publication link relations:

    <html>
      <head>
        ...
        <link 
          rel="source" 
          href="http://example.net/post/1" />
        <link 
          rel="provider" 
          href="http://example.org" />
        <link 
          rel="generator" 
          href="http://example.com/software/app/1.1" />
        ...
      </head>
      <body>...</body>
    </html>
  

      

Using the location relation:

    Link: <geo:37.786971,-122.399677>; rel="location"
      

Using the mentioned-by relation:

    LINK /articles/1 HTTP/1.1
    Host: example.org
    Link: <articles/2>; rel="mentioned-by"
      

Author's Address

James M Snell EMail: jasnell@gmail.com