Re: ISSUE-81: representation-vs-resource - Chairs Solicit Proposals

On Jan 17, 2010, at 12:12 PM, Roy T. Fielding wrote:

> On Jan 17, 2010, at 5:20 AM, Julian Reschke wrote:
>> Sam Ruby wrote:
>>> ...
>>>> The clear and reasonable deadline I am asking for is that, when you
>>>> have assigned a deadline for the last blocker issue, then assign
>>>> the same deadline for this one.  What's the harm in that?
>>> I would be very concerned if everybody took that position.
>> That would be a problem. For now although it seems to be hypothetical problem.
>>> I am also concerned that if nobody else sees this as enough of an issue to work on a change proposal.
>> I think it is an issue, and so does the TAG (as far as I understand their feedback, see <>).
>> This change proposal is (or would be) really different from others in that it requires touching many many parts of the spec, and once this is done, it may have to be repeated again once sloppy terminology gets back in.
> And, perhaps more importantly, it is an editorial issue.  Fixing it
> late in the process does not impact implementations.   The editor
> already has the information needed to fix the issue; he just doesn't
> want to.  If he changes his mind, there is ample list discussion that
> can be followed for instruction.
> It is a difficult proposal to write because the current use of
> terminology like resource, file, document, and even pragma is
> not only incorrect, but also inconsistent.  Fixing it will require
> going through the entire thousand-page document, line by line,
> and I would like to postpone having to do that until after
> I have finished a similar task in httpbis.

I don't think a deadline of six months is reasonable (on top of the month and a half that has already expired). Likewise, I don't think a deadline of "after all the other issues are done" is reasonable, as it is effectively unbounded. If it's too much work to rewrite everything, then I am open to something like Julian's proposal: clearly define all relevant terms, then show the changes to the terminology section and a small number of representative sections (one or two) to demonstrate proper usage of the terms. We are not looking to create unreasonable amounts of work. We simply don't want this issue sitting open as a blocker without someone actively working on it.

If there's really no way to address this without many months of work, for what is ultimately an editorial issue, then I'd have to question whether it needs to be a showstopper at all.


Received on Sunday, 17 January 2010 23:20:40 UTC