Skip to content

Commit

Permalink
Merge branch 'gh-pages' of https://github.com/w3c/dxwg into profiles-…
Browse files Browse the repository at this point in the history 
…changes-section
  • Loading branch information
@rob-metalinkage
rob-metalinkage committed Mar 13, 2019
2 parents a7f0e2e + 1849f91 commit 7a2213d
Show file tree
Hide file tree
Showing 2 changed files with 65 additions and 7 deletions.
9 changes: 9 additions & 0 deletions conneg-by-ap/config.js
View file
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,15 @@ var respecConfig = {
issueBase: "https://github.com/w3c/dxwg/issues/",
github: "https://github.com/w3c/dxwg/",
localBiblio: {
"ARK" : {
editors: ["J. Kunze",
"R. Rodgers"
],
href: "https://tools.ietf.org/id/draft-kunze-ark-15.txt",
title: "The ARK Identifier Scheme" ,
date: "2008-05-22",
status: "Internet-Draft"
},
"PROF-CONNEG": {
editors: [
"Lars G. Svensson",
Expand Down
63 changes: 56 additions & 7 deletions conneg-by-ap/index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -166,7 +166,8 @@ <h2>Related Work</h2>
current version of the IETF draft (-00) is expected to be completely re-written in parallel work with this document and should
not be seen as anything but work-in-progress.
</p>
<h3>Existing standards for transporting profile information in HTTP headers</h3>
<section id="relatedwork-existingHttpStandards">
<h3>Existing standards for transporting profile information in HTTP headers</h3>
<h4>Using Accept/Content Type together with the profile parameter</h4>
<p>The HTTP Accept and Content-Type header fields [[RFC 7231]]
allow a client to specify acceptable media types (<code>Accept</code>)
Expand All @@ -181,7 +182,7 @@ <h4>Using Accept/Content Type together with the profile parameter</h4>
text/turtle;q=0.7;profile="urn:example:profile-2"

HTTP/1.1 200 OK
Content-Type: text/turtle;profile=<urn:example:profile-2>
Content-Type: text/turtle;profile="urn:example:profile-2"
</pre>
<p>During TPAC 2018 in Lyon, the DXWG had a longer discussion with the JSON-LD WG
and it was concluded that the “profile” parameter in the <code>Accept</code> and <code>Content-Type</code>
Expand Down Expand Up @@ -224,11 +225,11 @@ <h4>Using the Prefer/Preference-Applied header fields (RFC 7240)</h4>
<pre class="example nohighlight" aria-busy="false" aria-live="polite" title="Using a Link header with a profile parameter">
GET /some/resource HTTP/1.1
Accept: text/turtle
Prefer: profile=&lt;urn:example:schema&gt;
Prefer: profile="urn:example:schema"

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile=&lt;urn:example:schema&gt;
Preference-Applied: profile="urn:example:schema"
</pre>
<p>This approach has two disadvantages.
The first is - as with the <code>Link</code> header,
Expand Down Expand Up @@ -259,10 +260,28 @@ <h4>Using the Prefer/Preference-Applied header fields (RFC 7240)</h4>
or other HTTP headers for this use
will be listed and discussed here.
</p>
</section>
<section id="relatedWork-ark">
<h3>Archival Resource Key (ark)</h3>
<p>ARK (Archival Resource Key) [[ARK]] is an identifier scheme
for the persistent identification of information objects.
ARK identifiers can contain an optional qualifier
"that extends the base ARK in order to create a kind of service entry point
into the object named by the NAA [sc. Name Assigning Authority]."
Through a qualifier, any NMA (Name Mapping Authority, service provider offering ARK resolution)
can supply access to variants of that object.
The set of qualifiers is open and any ARK NAA or NMA can invent its own.
The ARK specification lists versions, languages and formats as examples of qualifiers (§2.5)
and a profile name could be used as a qualifier
to refer to a representation of an information object conforming to that specific profile.
E. g. does <a href="https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/">https://api.istex.fr/ark:/67375/6GQ-MLC8GRWC-5/</a>
refer to different XML encodings of the metadata, one using MODS, the other one using other XML vocabularies.
</p>
</section>
<div class="issue" data-number="383"></div>
<div class="issue" data-number="516"></div>
<div class="issue" data-number="384"></div>
<div class="issue" data-number="514"></div>

</section>
<section id="abstractmodel">
<h2>Abstract Model</h2>
Expand Down Expand Up @@ -950,15 +969,45 @@ <h2>Implementations</h2>
</ul>
<div class="issue" data-number="467"></div>
</section>
<section id="acknowledgements" class="informative">
<h2>Acknowledgements</h2>
<p>Comments and suggestions from
Annette Greiner,
Erik Wilde,
Gregg Kellogg
and Kam Hay Fung
improved this specification
</p>
</section>
<section id="changes" class="informative">
<h2>Changes</h2>
<p>Changes since the <a href="https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/">18 December 2018 Working Draft</a> are:</p>
<ul>
<li>Added text about existing standards for transporting profile information in http headers
to <a href="#relatedwork">related work</a>.
(<a href="https://github.com/w3c/dxwg/issues/45">Issue 45</a>)</li>
<li>Removed advice on use of HTTP OPTIONS.
(<a href="https://github.com/w3c/dxwg/issues/510">Issue 510</a>)</li>
<li>Added text about ARK identifiers to <a href="#relatedwork">related work</a>.
(<a href="https://github.com/w3c/dxwg/issues/514">Issue 514</a>)</li>
<li>Clarified difference between the <code>profile</code> parameter in <code>Accept</code> header fields
and the <code>Accept-Profile</code> header field.
(<a href="https://github.com/w3c/dxwg/issues/662">Issue 662</a>)</li>
<li>Updated the <a href="#security_and_privacy">Security and Privacy</a> section.
(<a href="https://github.com/w3c/dxwg/issues/782">Issue 782</a>)</li>
</ul>
</section>
<section id="security_and_privacy" class="informative">
<h2>Security and Privacy</h2>
<p>
The use of HTTP to negotiate and transport implies that all privacy and security issues
that are relevant for that protocol are also relevant for profile negotiation. E. g.,
information such as user agent, accept-headers, IP address etc. can potentially be used as
identifying information, and particularly, the IP address adds information about geolocation
and institutional membership. Apart from that, there are no known security or privacy impacts
of this feature.
and institutional membership.
Further, offering a list of acceptable profiles at the beginning of a negotiation process
can reveal information about the user's interests
that could be used to add such information to a user profile.
</p>
<p>
For a more complete view of those issues, cf. the
Expand Down

0 comments on commit 7a2213d

Please sign in to comment.