Re: Last Call: <draft-nottingham-rfc5988bis-05.txt> (Web Linking) to Proposed Standard

[Julian Reschke <[e-mail]>]

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 <[e-mail]> 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