Subject: Re: [draft-nottingham-http-link-header-06] rev

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 15:15:35 +1000

On 25/07/2009, at 12:01 AM, Anne van Kesteren wrote:

> If we can consider the media attribute to be an link-extension, why  
> can we not do the same for rev?

As per recent discussion, done; see
   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Aug 2009 09:21:33 +0200

Mark Nottingham wrote:
> ...

I still think this is the wrong approach.

"rev" has been defined in RFC2068. We can explain why relying on it is a 
bad idea, and suggest alternatives.

But excluding it from the base definition essentially allows re-defining 
it as extension meaning something else, and that would be bad if a 
recipient implements RFC2068.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Aug 2009 17:48:12 +1000

I know where you're coming from.

However, rev's semantics are *extremely* muddy and effectively format- 
specific; I think we're already at the point where it is re-defined  
every time it's used. And, defining it syntactically in Link without  
defining its semantics doesn't seem like the right thing to do.

Thus, it seems to me that the options are to either take it out of the  
syntax completely, or leave it in the syntax for the sole purpose of  
deprecating it (since we can't really define crisp semantics for it).

On 21/08/2009, at 5:21 PM, Julian Reschke wrote:

>>> If we can consider the media attribute to be an link-extension,  
>>> why can we not do the same for rev?
> "rev" has been defined in RFC2068. We can explain why relying on it  
> is a bad idea, and suggest alternatives.
>
> But excluding it from the base definition essentially allows re- 
> defining it as extension meaning something else, and that would be  
> bad if a recipient implements RFC2068.
>
> BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Fri, 21 Aug 2009 09:52:18 +0200

On Fri, Aug 21, 2009 at 9:48 AM, Mark Nottingham <[email-masked]> wrote:

> However, rev's semantics are *extremely* muddy and effectively
> format-specific; I think we're already at the point where it is re-defined

Perhaps a reference to RFC2068 would suffice along with a brief explanation
as to why it's removed (poorly defined, rarely used and/or often abused)?
Not that I necessarily have a problem with your earlier wording, nor do I
foresee interop problems arising.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Aug 2009 10:14:11 +0200

Mark Nottingham wrote:
> format-specific; I think we're already at the point where it is 

Really? Pointer?

> re-defined every time it's used. And, defining it syntactically in Link 
> without defining its semantics doesn't seem like the right thing to do.

Minimally we should ensure that it's not used as a name for future 
extension parameters if that use would conflict with the text in RFC 2068.

> deprecating it (since we can't really define crisp semantics for it).

If these are the choices, I'd definitively prefer the latter.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Aug 2009 11:51:25 +1000

>> format-specific; I think we're already at the point where it is

There was a long discussion about this; as I remember it, different  
versions of HTML have different wordings of what rev is, leading  
people to wildly varying understandings of what it means. I can dig up  
references if you like, but it was discussed quite extensively.

>> re-defined every time it's used. And, defining it syntactically in  
>> Link without defining its semantics doesn't seem like the right  
>> thing to do.
>

>> Thus, it seems to me that the options are to either take it out of  
>> the syntax completely, or leave it in the syntax for the sole  
>> purpose of deprecating it (since we can't really define crisp  
>> semantics for it).
>
> If these are the choices, I'd definitively prefer the latter

Anne? Ian? IIRC both of your requested the removal of "rev"; how do  
you feel about leaving it in the grammar but strengthening the text to  
clarify that implementations are not required to interpret / use it?

Cheers,

---

From: Ian Hickson <[email-masked]>
Date: Mon, 24 Aug 2009 02:20:24 +0000 (UTC)

On Mon, 24 Aug 2009, Mark Nottingham wrote:
> 
> Anne? Ian? IIRC both of your requested the removal of "rev"; how do you 
> feel about leaving it in the grammar but strengthening the text to 

My ideal situation would be for rev=""'s semantics and (more importantly) 
user agent conformance criteria to be fully defined in detail, but for the 
authoring conformance criteria to make _use_ of rev="" non-conforming.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 24 Aug 2009 13:08:01 +1000

On 24/08/2009, at 12:20 PM, Ian Hickson wrote:

>> you

I.e., define the semantics of rev in case it's received, but prohibit  
sending it?

---

From: Ian Hickson <[email-masked]>
Date: Mon, 24 Aug 2009 05:43:26 +0000 (UTC)

On Mon, 24 Aug 2009, Mark Nottingham wrote:
> > > you feel about leaving it in the grammar but strengthening the text 
> > > to clarify that implementations are not required to interpret / use 
> > > it?
> > 
> > My ideal situation would be for rev=""'s semantics and (more 
> > importantly) user agent conformance criteria to be fully defined in 
> > detail, but for the authoring conformance criteria to make _use_ of 
> > rev="" non-conforming.
> 

Right, exactly.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 24 Aug 2009 14:42:08 +0200

>> I.e., define the semantics of rev in case it's received, but prohibit

This works for me too, though I hope it does not mean browsers suddenly have to start supporting something browsers never really properly implemented in the first place. (I think "rev" fails the rough consensus and running code mantra, but I might be missing something here.)

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Ian Hickson <[email-masked]>
Date: Mon, 24 Aug 2009 18:56:46 +0000 (UTC)

On Mon, 24 Aug 2009, Anne van Kesteren wrote:
> This works for me too, though I hope it does not mean browsers suddenly 
> have to start supporting something browsers never really properly 
> implemented in the first place. (I think "rev" fails the rough consensus 
> and running code mantra, but I might be missing something here.)

Yeah it may be that the semantics are "it does nothing", in which case I'd 
be fine with just not mentioning it at all. I haven't done any testing.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 24 Aug 2009 13:19:15 -0700

On Aug 24, 2009, at 5:42 AM, Anne van Kesteren wrote:

> This works for me too, though I hope it does not mean browsers  
> suddenly have to start supporting something browsers never really  
> properly implemented in the first place. (I think "rev" fails the  
> rough consensus and running code mantra, but I might be missing  
> something here.)

rev="Made" was, at one point, supported by browsers (esp. Lynx).
I don't know if Lou carried that forward into Netscape et al.

I don't have a problem with its deprecation.

....Roy