hello jari.
thanks a lot for the review!
On 2018-10-27 01:36, Jari Arkko wrote:
Summary:
This is a well-written, understandable and useful piece of specification.
Thanks for writing it.
I had a couple of minor observations, but otherwise the draft is ready to be
published.
that's great to hear. i will make changes according to your review, and
publish a new version (-08) later this week.
The section on relation link type discusses who may be reading the linked
material:
This specification places no
constraints on the scope or the type of the linked resource. The
scope can be for a resource or for a service. The type is determined
by the media type of the linked resource, and can be targeted at
humans, at machines, or a combination of both.
That's fine, but at the same time my understanding is that there is no media
type today that would actually be machine readable and usable for your purpose?
Is this so? If I cannot write code today for a machine to do anything with the
linked resource, maybe that's something that you'd want to say. And you
probably don't want to blindly load and use the
load-this-executable-and-all-your-linking-problems-are-history media type,
either :-)
the main idea was that the policy probably would be more often
documented than described in a fully machine-understandable format.
but i do understand you concerns. i have done two things. right
underneath the sentence you quoted, i have added the following:
"If the linked resource does provide machine-readable information,
consumers should be careful before acting on this information. Such
information may, for example, instruct consumers to use a migration rule
so that sunset resources can be accessed at new URIs. However, this kind
of information amounts to a possibly large-scale identity migration of
resources, so it is crucial that the migration information is authentic
and accurate."
i have also added a paragraph about the same issue to the security
considerations section:
"In cases where a sunset policy is linked by using the sunset link
relation type, clients should be careful about taking any actions based
on this information. It should be verified that the information is
authentic and accurate. Furthermore, it should be tested that this
information is only applied to resources that are within the scope of
the policy, making sure that sunset policies cannot "hijack" resources
by for example providing migration information for them."
The security considerations section does not mention that there might be cases
where the lifetime information could be sensitive. Are there such cases? The
only example of that I can come with is that a fixed data retention rule would
obviously also reveal the time that the organisation in question has learned
about the data in question, which might be sensitive in some cases.
that's a very good point, i have added that as the very first paragraph
of the security considerations.
"Generally speaking, information about upcoming sunsets can leak
information that otherwise might not be available. For example, a
resource representing a registration can leak information about the
expiration date when it exposes sunset information. For this reason, any
use of sunset information where the sunset represents an expiration or
allows the calculation of another date (such as calculating a creation
date because it is known that resource expire after one year) should be
treated in the same way as if this information would be made available
directly in the resource's representation."
Nits/editorial comments:
The example section could perhaps demonstrate the use of the sunset relation in
addition to the header field.
good point, i added an example after the header field example.
'Before the Sunset header even appears for the first time (it may not
appear fro the very beginning), it is possible that the resource (or
possibly just the "home" resource of the service context) communicates
its sunset policy by using the sunset link relation. If communicated as
an HTTP header field, it might look as following:
Link: <http://example.net/sunset>;rel="sunset";type="text/html"
In this case, the linked resource provides sunset policy information
about the service context. It may be documentation aimed at developers,
for example informing them that the lifetime of a certain class of
resources is ten years after creation, and that Sunset headers will be
served as soon as the sunset date is less than some given period of
time. It may also inform developers whether the service will respond
with 410 or 404 after the sunset time, as discussed above.'
thanks again for the review. i'll post an updated version soon.
cheers,
dret.
--
erik wilde | mailto:erik.wilde@xxxxxxxx |
| http://dret.net/netdret |
| http://twitter.com/dret |
