On 2017-05-03 03:51, Mark Nottingham wrote:
Hi Carsten,
Thanks for the review. Responses below.
On 3 May 2017, at 5:18 am, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:
Review of draft-nottingham-rfc5988bis-05.txt
Reviewer: Carsten Bormann
Review result: Ready with a few issues
(This is not a complete review, but in its present state might serve
to initiate discussion of items relevant to RFC 6690 and thus
draft-ietf-core-links-json.)
This specification updates RFC 5988. The objectives for this update
are not clearly stated, but it seems to be based on experience with
RFC 5988 as well as based on advances possible with the publication of
RFC 7230.
# Major technical
T1: The draft does not take position what should happen when
serializations allowed by RFC 5988 but not by the present spec occur,
e.g.: ;type=text/plain (would now need to be ;type="text/plain").
It assumes the general approach we take in HTTP; absent more specific requirements,
recipients need to be permissive. Perhaps it would be good to link to
<http://httpwg.org/specs/rfc7230.html#conformance> somewhere near the top...
"Need to"?
"Unless noted otherwise, a recipient MAY attempt to recover a usable
protocol element from an invalid construct. HTTP does not define
specific error handling mechanisms except when they have a direct impact
on security, since different applications of the protocol require
different error handling strategies. For example, a Web browser might
wish to transparently recover from a response where the Location header
field doesn't parse according to the ABNF, whereas a systems control
client might consider any form of error recovery to be dangerous." --
<https://greenbytes.de/tech/webdav/rfc7230.html#rfc.section.2.5.p.9>
So in RFC 7230 this is truly OPTIONAL.
...
Best regards, Julian