연결된 데이터 알림

LDN은 소셜 웹 워킹 그룹에서 작성 중인 여러 관련 명세 중 하나입니다. 대체 접근 방식이나 보완 프로토콜에 관심 있는 구현자는 개요 문서 Social Web Protocols를 우선 참조하시기 바랍니다. 소셜 웹 프로토콜 명세의 특정 하위 섹션은 본 명세 전반에서 확장성 또는 다른 프로토콜과의 연동 지점을 밝히기 위해 인용하고 있습니다.

발신자는 사람이 직접 실행하거나 자동 프로세스로 트리거되어 서버에게 알림을 전달합니다. 알림 데이터는 수신자의 관심을 위한 정보이며, 예시로는 친구의 개인 메시지, 핑백 링크, 블로그 댓글, 협업 초대, 캘린더 알림, 과학적 관측정보 등이 있습니다.

발신자는 알림을 보낼 타겟 리소스를 선택하고, 대상의 Inbox 위치를 발견한 뒤, 그곳에 알림을 보냅니다. 모든 리소스는 Inbox를 광고할 수 있습니다. 수신자는 알림 데이터를(적절한 접근 제어에 따라) 소비자가 사용할 수 있도록 제공합니다.

소비자는 발신자와 동일한 방식으로 Inbox의 위치를 찾은 뒤, 알림을 추가 처리하거나 다른 데이터와 조합하여 쓰거나, 혹은 단순히 사람에게 읽기 좋은 방식으로 알림을 표시할 수 있습니다.

발신자와 소비자는 탐색 과정을 통해 리소스의 Inbox URL을 HTTP Link 헤더나 리소스 본문 내의 관계로부터 식별합니다.

발신자(Sender):

• 알림의 내용을 애플리케이션 요구에 맞게 작성합니다.
• 알림을 Inbox URL에 POST 요청으로 전송하며, 본문은 JSON-LD 또는 서버가 허용하는 다른 직렬화로 전달합니다.

수신자(Receiver):

• Inbox URL로 들어온 GET 요청에 대해서는, 지금까지 받은 알림(URL 목록 포함) 정보를 반환합니다.
• 개별 알림 URL에 대한 GET 요청에는 JSON-LD(또는 선택적으로 다른 직렬화)를 반환합니다.
• Inbox URL로 들어온 POST 요청을 받아 알림을 생성합니다.
• 선택적으로 Inbox로 발송되는 알림에 대한 제약 조건을 강제할 수 있습니다.

소비자(Consumer):

• Inbox URL의 내용을 GET 요청으로 조회하고, 애플리케이션 목적에 맞게 활용합니다.

LDN은 알림 전송·소비를 위해 Linked Data Platform [LDP]의 특화된 활용 예시입니다. 완전한 LDP 구현이 반드시 필요한 것은 아니며, 구현이 쉬운 부분집합만으로도 충분합니다. LDP에 대한 사전 지식 없이도 본 명세를 이해할 수 있지만, 알고 있다면 몇몇 개념이 익숙하게 느껴질 수 있습니다. 우리는 분산되고 상호운용 가능한 방식으로 알림을 쉽게 교환할 수 있도록 필요한 특징만 기술합니다. LDN Inbox는 LDP BasicContainer에 해당합니다.

LDN 구현체는 발신자, 수신자, 소비자가 될 수 있습니다. 각 역할별 적합성 기준은 본 명세의 해당 절에서 설명합니다.

Inbox는 알림이 보내지거나 소비되는 엔드포인트로서 블로그 게시글, 사용자 프로필, 데이터셋, 비디오 등 임의의 리소스에서 발견될 수 있습니다. 탐색의 시작점은 알림이 향하는 혹은 알림에 관련된 리소스, 즉 target입니다. 어떤 리소스(RDF 또는 비-RDF)가 자체 Inbox를 가질 수 있으므로, 어느 리소스에서 탐색을 시작할지는 발신자나 소비자의 재량입니다.

발신자와 소비자는 Inbox URL을 찾기 위해 다음을 수행합니다:

• 타겟 URL에 대해 HTTP HEAD 또는 GET 요청을 하고, rel 값이 http://www.w3.org/ns/ldp#inbox인 Link 헤더를 사용하는 방법
• 타겟 URL에 대해 HTTP GET 요청을 하여 RDF 표현 [RDF 1.1]을 가져오고, 그 인코딩된 RDF 그래프가 http://www.w3.org/ns/ldp#inbox 타입의 관계를 포함하는지 확인하는 방법. 그 관계의 주어는 타겟이고 객체는 Inbox입니다.

이들은 어느 순서로든 수행될 수 있지만, 첫 번째 방법으로 Inbox를 찾지 못하면 두 번째 방법을 반드시(MUST) 시도해야 합니다. 발신자와 소비자는 분명히 프래그먼트 식별자를 가지는 URI를 대상으로 하는 경우에는 Link 헤더 기반 탐색을 생략하는 것이 권장됩니다(SHOULD).

리소스는 반드시(MUST) 하나의 Inbox만을 광고해야 합니다. 하나의 Inbox는 예를 들어 내 블로그 게시물의 모든 답글과 내 사진의 모든 공유에 대해 동일한 Inbox를 쓰는 등 여러 리소스에서 공유해서 사용할 수 있습니다(MAY).

HEAD /article HTTP/1.1
Host: example.org
Accept: application/ld+json

HTTP/1.1 200 OK
Link: <http://example.org/inbox/>; rel="http://www.w3.org/ns/ldp#inbox"

GET /profile HTTP/1.1
Host: example.org
Accept: application/ld+json

HTTP/1.1 200 OK
Content-Type: application/ld+json

{
  "@context": "http://www.w3.org/ns/ldp",
  "@id": "http://example.org/profile",
  "inbox": "http://example.org/inbox/"
}

GET /event HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<p about="http://example.org/event" typeof="http://schema.org/Event" lang="en">
  <a rel="http://www.w3.org/ns/ldp#inbox" href="/inbox/">RSVP</a> to event
</p>

GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<link href="/inbox/" rel="http://www.w3.org/ns/ldp#inbox" />

GET /article HTTP/1.1
Host: example.org
Accept: text/html, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/html;charset=utf-8

<section id="results" about="#results"
  property="http://www.w3.org/ns/ldp#inbox" resource="/inbox/">
</section>

GET / HTTP/1.1
Host: csarven.ca
Accept: text/turtle, application/ld+json

HTTP/1.1 200 OK
Content-Type: text/turtle;charset=utf-8

<http://csarven.ca/#i>
  <http://www.w3.org/ns/ldp#inbox> <http://csarven.ca/inbox/> .

서버가 이 프로토콜을 모를 가능성을 고려하여 탐색을 수행하는 방법에 대한 권고는 Social Web Protocols를 참조하세요.

탐색을 마친 후, 알림을 전송하려는 발신자는 POST 요청을 통해 Inbox URL로 알림을 전달해야 합니다(MUST). 발신자는 성공적인 요청에 대해 201 Created(Location 헤더 포함) 또는 202 Accepted 응답을 기대할 수 있습니다.

발신자는 서버가 수락하는 RDF 콘텐츠 타입을 확인하기 위해 OPTIONS 요청을 사용할 수 있으며, 응답으로 반환된 Accept-Post 헤더의 값에 따라 요청 본문에 알림을 직렬화할 수 있습니다. 그렇지 않은 경우에는 POST 요청의 본문은 JSON-LD 형식의 알림 payload를 포함해야 합니다(MUST) 및 헤더 Content-Type: application/ld+json를 사용해야 합니다. Content-Type 헤더는 profile URI를 포함할 수 있습니다(MAY) [RFC6906].

발신자는 인증 또는 인가를 위해 추가 헤더나 콘텐츠(예: Authorization: Bearer XXX)를 포함할 수 있습니다(MAY).

발신자가 인증을 필요로 하지 않는 localhost에서 서비스를 실행 중인 경우, 악성 스크립트가 Inbox 엔드포인트에서 실행되어 발신자가 자신에게 임의의 POST 요청을 하게 만들 수 있습니다. 따라서 발신자는 localhost나 루프백 IP 주소로 POST 요청을 해서는 안 됩니다(SHOULD NOT).

POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

HTTP/1.1 201 Created
Location: http://example.org/inbox/5c6ca040

수신자는 Inbox URL에 대한 GET 및 POST 요청을 지원해야 합니다(MUST). LDP 관점에서 Inbox는 Container입니다.

OPTIONS /inbox/ HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS, POST
Accept-Post: application/ld+json, text/turtle

POST /inbox/ HTTP/1.1
Host: example.org
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

HTTP/1.1 201 Created
Location: http://example.org/inbox/92d72f00

GET /inbox/ HTTP/1.1
Host: example.org
Accept: application/ld+json
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6

HTTP/1.1 200 OK
Content-Type: application/ld+json
Content-Language: en

{
  "@context": "http://www.w3.org/ns/ldp",
  "@id": "http://example.org/inbox/",
  "contains": [
    "http://example.org/inbox/5c6ca040",
    "http://example.org/inbox/92d72f00"
  ]
}

소비자는 Inbox URL에 대한 GET 요청을 통해 Inbox에 있는 알림의 URI를 가져옵니다(이 URL을 찾으려면 탐색 참조).

알림의 URI는 Inbox URL의 http://www.w3.org/ns/ldp#contains 술어를 통해 검색 가능해야 합니다(MUST).

Inbox 또는 개별 알림을 가져올 때 소비자는 선호 콘텐츠 타입(예: JSON-LD)을 나타내기 위해 Accept 헤더를 명시적으로 설정하는 것이 권장됩니다(SHOULD). 개별 알림을 몇 개, 어떤 기준으로 가져올지는 소비자의 재량입니다(예: 콘텐츠 길이, 타임스탬프 등).

소비자는 인증 또는 인가 목적을 위해 추가 헤더나 콘텐츠를 포함할 수 있습니다(MAY).

소비자는 페이로드에서 추가적인 페치나 추론(예: 알림에서 참조된 리소스의 역참조를 통해 내용을 가져오는 것)을 수행할 수 있으며(MAY), Inbox가 발표한 제약을 알림 처리 전에 확인하고자 할 수 있습니다(MAY).

GET /inbox/14a792f0 HTTP/1.1
Host: example.org
Accept: application/ld+json, text/turtle, application/xhtml+xml, text/html
Accept-Language: en-GB,en;q=0.8, en-US;q=0.6

HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    { "@language": "en" }
  ],
  "@id": "http://example.org/inbox/14a792f0",
  "@type": "Announce",
  "actor": {
    "@id": "http://csarven.ca/#i",
    "name": "Sarven Capadisli"
  },
  "object": {
    "@context": "http://www.w3.org/ns/anno.jsonld",
    "@id": "http://example.net/note",
    "@type": "Annotation",
    "motivation": "http://www.w3.org/ns/oa#assessing",
    "rights": "http://creativecommons.org/licenses/by/4.0/"
  },
  "target": "http://example.org/article",
  "updated": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2016-06-28T19:56:20.114Z"
  }
}

이 절은 비규범적입니다.

{
  "@context": "http://schema.org/",
  "@id": "http://example.net/note#foo",
  "citation": { "@id": "http://example.org/article#results" }
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "@id": "",
  "@type": "Announce",
  "actor": "https://rhiaro.co.uk/#me",
  "object": "http://example.net/note",
  "target": "http://example.org/article",
  "updated": "2016-06-28T19:56:20.114Z"
}

{
  "@context": { "pingback": "http://purl.org/net/pingback/" },
  "@id": "",
  "@type": "pingback:Item",
  "pingback:source": { "@id": "http://example.net/note#foo" },
  "pingback:target": { "@id": "http://example.org/article#results" }
}

{
  "@context": "http://schema.org/",
  "@id": "",
  "@type": "RsvpAction",
  "event": { "@id": "http://example.org/event" },
  "agent": { "@id": "https://rhiaro.co.uk/#me" }
}

알림은 임의의 정보를 담고 있을 수 있으며, 각기 다른 URI를 가진 여러 리소스에 대한 참조를 포함할 수 있습니다. 반드시 특정 외부 리소스나 데이터의 출처를 참조하지 않아도 됩니다. 소비자가 알림을 요청할 때 수신자는 처음 전송된 모든 트리플을 반환해야 합니다.

{
  "@context": {
    "@language": "en",
    "sioc": "http://rdfs.org/sioc/ns#",
    "foaf": "http://xmlns.com/foaf/0.1/"
  },
  "@id": "",
  "@type": "sioc:Comment",
  "sioc:reply_of": { "@id": "http://example.org/article" },
  "sioc:created_at": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2015-12-23T16:44:21Z"
  },
  "sioc:content": "This is a great article!",
  "sioc:has_creator": {
    "@id": "http://example.org/profile",
    "@type": "sioc:UserAccount",
    "sioc:account_of": { "@id": "http://example.org/profile#alice" },
    "sioc:avatar": { "@id": "http://example.org/profile/avatar.png" },
    "foaf:name": "Alice"
  }
}

{
  "@context": [{"prov": "http://www.w3.org/ns/prov#"}],
  "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
  "@type": "prov:Activity",
  "http://www.w3.org/2000/01/rdf-schema#label": {
    "@language": "en",
    "@value": "Make it so"
  },
  "prov:endedAtTime": {
    "@type": "http://www.w3.org/2001/XMLSchema#dateTime",
    "@value": "2016-06-14T20:57:39.000Z"
  },
  "prov:generated": {
    "@id": "http://example.org/entity/804c4e7efaa828e146b4ada1c805617ffbc79dc7",
    "@type": "prov:Entity",
    "prov:specializationOf": { "@id": "http://example.org/entity/file" },
    "prov:wasGeneratedBy": {
      "@id": "http://example.org/activity/804c4e7efaa828e146b4ada1c805617ffbc79dc7"
    }
  },
  "prov:wasAssociatedWith": {
    "@id": "http://csarven.ca/#i",
    "@type": "prov:Agent",
    "http://xmlns.com/foaf/0.1/name": {
      "@language": "hy",
      "@value": "Սարվէն Չափատիշլի"
    }
  }
}

Inbox URL은 rel 값이 http://www.w3.org/ns/ldp#constrainedBy인 HTTP Link 헤더 또는 리소스 본문을 통해 자체 제약사항(예: SHACL, Web Annotation Protocol)을 알릴 수 있습니다. 발신자는 이 제약 명세를 따르는 것이 바람직하며, 그렇지 않을 경우 수신자는 알림을 거부하고 적절한 4xx 오류를 반환할 수 있습니다.

Inbox(타겟)를 광고하는 리소스의 발행자는 신뢰할 수 있는 서버에서 이를 해야 합니다. 발행자는 타사에서 헤더나 콘텐츠에 접근할 경우 알림이 리다이렉션 될 수 있음을 인지해야 합니다.

본 명세는 소비자가 pull을 통해 수신자로부터 알림을 읽는 방법을 설명하지만, 소비자가 새로 들어오는 알림이나 Inbox 내용 변경 사항을 푸시 받기를 원할 수 있습니다. 유사하게 수신자도 특정 발신자에 대한 알림을 요청하고자 할 수 있습니다. 이런 형태의 구독 메커니즘은 본 명세 범위에 포함되지 않으나, 발신자/수신자/소비자 간에 이런 계약을 맺는 것을 제한하지 않습니다. 구독 기능을 활성화하려는 구현체는 ActivityPub, WebSub, WebSocket 프로토콜, HTTP Web Push 등 기존 메커니즘을 사용할 수 있습니다.

Activity Streams 2.0 Core를 지원하려는 수신자 구현체는 Content-Type 및 어휘 동등성에 대한 안내가 있는 Social Web Protocols - Inbox Interop를 참고할 수 있습니다.

연합형 네트워크에서 국제적 사용자층을 구축하는 것은 중요합니다. 일부 LDN 상호작용은 HTML 조각, 요약 필드 등 자연어 텍스트 콘텐츠를 반환할 수 있습니다. 모든 항목에 대해 다국어 버전을 제공하는 것이 항상 가능하지 않을 수 있습니다. 구현체는 사용 가능한 언어를 식별하거나 반환할 언어를 협상할 방법(예: HTTP Accept-Language 헤더를 활용하여 요청별로 가장 적합한 언어 표현을 선택할 수 있도록)을 마련하는 것이 바람직합니다.

수신자가 발신자 또는 소비자 인증을 기대하는 경우, 다른 데이터나 오류 코드를 반환하기 전에 이들의 자격 증명 유효성을 먼저 검사해야 합니다. 예를 들어, 수신자는 인가되지 않은 요청자에 대해서는 Inbox 존재 여부 확인(404 Not Found 반환 등)을 먼저 하지 말아야 합니다.

토큰 기반 인증은 반드시 HTTPS 상에서만 이뤄져야 합니다.

이 질문들은 Self-Review Questionnaire: Security and Privacy의 가이드에 따라 본 명세의 보안 및 개인정보 관련 고려사항을 요약합니다.

이 명세는 개인정보(PII)를 다루나요?

알림 페이로드는 발신자 또는 수신자를 식별할 수 있는 데이터를 포함할 수 있습니다. 알림 데이터에 대한 접근은 수신자 제어 하에 있습니다. 민감한 정보를 보낼 때 발신자는 Inbox가 공개 읽기를 허용할 수 있음을 주의해야 합니다.

이 명세는 고가치 데이터(자격 증명 등)를 다루나요?

알림 페이로드 내 개인정보(위 내용 참조)와 동일한 영향이 있습니다.

이 명세는 브라우징 세션 간에 지속되는 오리진별 상태를 도입하나요?

아니오.

이 명세는 웹에 노출되는 영구적, 크로스 오리진 상태를 도입하나요?

아니오.

이 명세는 기존에 접근할 수 없던 다른 데이터를 오리진에 노출하나요?

아니오.

이 명세는 새로운 스크립트 실행/로딩 메커니즘을 허용하나요?

아니오.

이 명세는 오리진이 사용자의 위치에 접근하도록 허용하나요?

아니오.

이 명세는 오리진이 사용자의 기기의 센서에 접근하도록 허용하나요?

아니오.

이 명세는 오리진이 사용자의 로컬 컴퓨팅 환경에 접근하도록 허용하나요?

아니오.

이 명세는 오리진이 다른 기기에 접근하도록 허용하나요?

아니오.

이 명세는 오리진이 사용자 에이전트의 네이티브 UI를 통제할 수 있게 하나요?

아니오.

이 명세는 웹에 임시 식별자를 노출하나요?

아니오.

이 명세는 퍼스트파티/서드파티 상황에 따른 동작 차이를 구분하나요?

아니오.

이 명세는 시크릿 모드 등에서 어떻게 동작해야 하나요?

해당 웹사이트가 사용자가 시크릿 모드임을 알 수 없도록 동작합니다.

이 명세는 사용자의 로컬 디바이스에 데이터를 지속적으로 저장하나요?

아니오.

이 명세에 "보안 관련 고려사항"과 "개인정보 관련 고려사항"이 포함되어 있나요?

:)

이 명세는 기본 보안 특성을 완화하도록 허용하나요?

아니오.

• 예제의 문법 오류 수정
• Social Web Group Charter에 대한 'in reply to' 링크 추가
• 과거 버전 사양 링크 추가
• 참고문헌 갱신

• 감사의 글 업데이트

• 감사의 글 추가
• 알림 및 note 내 요청 URI의 암시적 응답 코드 명확화
• 참고문헌 갱신

• 고려사항 섹션에 자연어 콘텐츠 내용 추가
• PubSub 관련 참고 문헌 수정
• 구현 보고·테스트 슈트 URL 추가
• SVG에 범례 추가
• AS2 bib 조각 수정
• Payload 검증 문구 재서술
• '인증된 Inbox' 보안 가이드 추가

• 예제 추가 및 갱신
• HTTP HEAD/GET 탐색 관련 설명 개선
• 에디토리얼: 문법, 표현 개선
• Accept-Post 참고링크 수정 및 OPTIONS에 명시
• 국제화 리뷰 피드백 통합(예제 등)

• 오타 및 링크 수정
• 전송, 수신, 소비 순서로 섹션 재배치
• 예시 갱신
• RFC7231 관련 참고문헌 추가
• URI 탐색 관련 문구 명확화
• 고려사항 비규범적 절의 소제목 추가
• 개요 다이어그램 추가
• 고려사항에 Retry Discovery 비규범 소절 추가
• 친절하게 탐색해야 함을 언급
• 오남용 방지 내용을 관련 규범 절로 이동
• 발신자 검증을 수신 섹션으로 이동
• ActivitStreams 2.0 Support를 고려사항으로 이동
• Payload verification을 Consuming의 Note로 이동
• 규범 및 일부 비규범 내용 고려사항에서 앞 부분으로 이동
• 보안 및 개인정보 검토 섹션 추가
• 소개 업데이트

• 오타, 문장부호, 명명
• 종료 기준(Exit Criteria) 추가
• Accept 헤더 사용 및 미사용시 동작 명확화
• Link 헤더 필드 relation의 주체 관련 note 추가
• Link 헤더가 포함될 수 있도록 GET 추가, 타겟 URL의 subject URI 명확화
• 개요(abstract) 개정
• 타겟 소유권 관련 고려사항 추가
• '모든 리소스가 자신의 inbox를 가질 수 있다' 언급
• 알림 구독(Subscribe) 섹션 추가

• 예시 개선; 갱신, 문법 수정, @context에서 https 적용
• 오타, 문장부호, 명명
• Payload 관련 비규범 설명 추가