Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Sylvain Hellegouarch]

My major issue here is not really whether or not those attributes exist
but the fact that there is no real review of their implications. We mainly
hear of how useful they can be for some existing implementations but it'd
be a shame to realize in a couple of years that they were in fact bringing
more issues than solving problems.

Call me paranoid or picky but I think a few questions that have been
raised here were valid ones. Besides this is the all point of this list
isn't it? ;)

Of course I wouldn't want the community to split.

- Sylvain

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Robert Sayre]

On 5/17/06, John Panzer <[EMAIL PROTECTED]> wrote:


I don't see any issue with these attributes.


Do you see Windows Feed Platform apps using these attributes? Probably not, huh?
Do you consider that lack of interoperation a feature?



James M Snell wrote:

>I find it utterly amazing that there is so much contention over two
>optional attributes that serve a purely informational purpose.


Are we supposed to take this seriously? Since you can't coherently
defend a single design decision in the draft, it's safe to conclude
this document is not ready to be an RFC.


> If a
>feed publishers includes them, and a particular feed consumer currently
>doesn't see a use for them, that feed consumer can ignore them and
>continue processing the feed with ZERO loss of function.


Well, you clearly don't think they're important. But then you felt
compelled to change them back and got an instant stamp of approval
from our AD. What happened there?

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Robert Sayre]

On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:


Sections 4.1 describes what is appropriate for standards track;
section 4.2 describes what is appropriate for Informational and
Experimental RFCs.


That's true, but the you asserted the following:


This document describes an extension to an existing standards-track
document: it should either be on standards track or it should not be
an RFC.


Where is that written down?


Don't see it in RFC2026. In fact, I don't see any of the process we're
encountering documented there.

I'm disappointed you didn't answer the more interesting and relevant
questions in my previous message.

--

Robert Sayre

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[James M Snell]

Excellent, thank you.

John Panzer wrote:
> Experience report:  Our implementation of comments for AOL blogs 
> includes the count information in a proprietary extension
> (aj:commentCount), precisely because we need the information for UI
> purposes.  We've found it useful and we'd like to use a more standard
> extension to help enable interoperability.
> The one issue we've had with it was with a partner who used a checksum
> on the retrieved file to determine if something has 'changed' in the
> feed.  We explained how they can use the update timestamps for that
> purpose and everything was solved.
> 
> I don't see any issue with these attributes.
> 
> -John
> 

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[John Panzer]

Experience report:  Our implementation of comments for AOL blogs  
includes the count information in a proprietary extension 
(aj:commentCount), precisely because we need the information for UI 
purposes.  We've found it useful and we'd like to use a more standard 
extension to help enable interoperability. 

The one issue we've had with it was with a partner who used a checksum 
on the retrieved file to determine if something has 'changed' in the 
feed.  We explained how they can use the update timestamps for that 
purpose and everything was solved.


I don't see any issue with these attributes.

-John

James M Snell wrote:


I find it utterly amazing that there is so much contention over two
optional attributes that serve a purely informational purpose.  If a
feed publishers includes them, and a particular feed consumer currently
doesn't see a use for them, that feed consumer can ignore them and
continue processing the feed with ZERO loss of function.

   "I've started thinking about my schema not as the definition of what
this system needs right now but as the definition of what the data
should look like if it's present instead."
  - Tim Ewald, "Making everything optional" [1]

There are some folks for whom the attributes will be useful.  I know,
for instance, that SixApart has found a use for them in some stuff they
are doing with Friendster.  I have also used the attributes in a
browser-based feed aggregator I've been toying around with.  Others may
not find a use for the attributes at all.  That's ok.  If you don't have
a use for them right now, **ignore them**.  If someone implements
support for the attributes and finds that they cause some sort of
significant interop issue, that's ok, that's why the IETF process is
iterative. "Proposed Standards" are not set in stone.  They can be
changed if implementation experience demonstrates that change is necessary.

Regarding whether this should be Experimental or a Proposed Standard, I
will defer to the judgement of the IESG, however, RFC2026 has the
following to say about "Proposed Standards":

  A Proposed Standard specification is generally stable, has resolved
  known design choices, is believed to be well-understood, has received
  significant community review, and appears to enjoy enough community
  interest to be considered valuable.  However, further experience
  might result in a change or even retraction of the specification
  before it advances.
  ...
  Implementors should treat Proposed Standards as immature
  specifications.  It is desirable to implement them in order to gain
  experience and to validate, test, and clarify the specification.
  However, since the content of Proposed Standards may be changed if
  problems are found or better solutions are identified, deploying
  implementations of such standards into a disruption-sensitive
  environment is not recommended.

Seems appropriate to me.


Regarding how The Evil Attributes could be used?  Given two replies links,

 
 ...
 
 
 

You can display two buttons in a GUI.

 "Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)"
 "Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)"


- James

[1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx

A. Pagaltzis wrote:
 


* Robert Sayre <[EMAIL PROTECTED]> [2006-05-17 07:25]:
   


I would have said this should go Experimental,
 


+1

We can wait and see what problems crop up in practice with the
contested attributes, and whether extensibility according to Sec
6.4. ff (or lack thereof) turns out to be paramount or, to borrow
Tim’s turn of phrase, a molehill.

If it works out, just reissue it; if not, there’s room to go back
and fix it.

Sounds reasonable enough to me.

Regards,
   

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[James M Snell]

I find it utterly amazing that there is so much contention over two
optional attributes that serve a purely informational purpose.  If a
feed publishers includes them, and a particular feed consumer currently
doesn't see a use for them, that feed consumer can ignore them and
continue processing the feed with ZERO loss of function.

"I've started thinking about my schema not as the definition of what
 this system needs right now but as the definition of what the data
 should look like if it's present instead."
   - Tim Ewald, "Making everything optional" [1]

There are some folks for whom the attributes will be useful.  I know,
for instance, that SixApart has found a use for them in some stuff they
are doing with Friendster.  I have also used the attributes in a
browser-based feed aggregator I've been toying around with.  Others may
not find a use for the attributes at all.  That's ok.  If you don't have
a use for them right now, **ignore them**.  If someone implements
support for the attributes and finds that they cause some sort of
significant interop issue, that's ok, that's why the IETF process is
iterative. "Proposed Standards" are not set in stone.  They can be
changed if implementation experience demonstrates that change is necessary.

Regarding whether this should be Experimental or a Proposed Standard, I
will defer to the judgement of the IESG, however, RFC2026 has the
following to say about "Proposed Standards":

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.
   ...
   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

Seems appropriate to me.


Regarding how The Evil Attributes could be used?  Given two replies links,

  
  ...
  
  
  

You can display two buttons in a GUI.

  "Subscribe to 'Comments' (10 responses, last updated Dec 12th, 2006)"
  "Subscribe to 'Trackbacks' (5 responses, last updated Nov 11th, 2006)"


- James

[1]http://pluralsight.com/blogs/tewald/archive/2006/04/20/22187.aspx

A. Pagaltzis wrote:
> * Robert Sayre <[EMAIL PROTECTED]> [2006-05-17 07:25]:
>> I would have said this should go Experimental,
> 
> +1
> 
> We can wait and see what problems crop up in practice with the
> contested attributes, and whether extensibility according to Sec
> 6.4. ff (or lack thereof) turns out to be paramount or, to borrow
> Tim’s turn of phrase, a molehill.
> 
> If it works out, just reissue it; if not, there’s room to go back
> and fix it.
> 
> Sounds reasonable enough to me.
> 
> Regards,

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Paul Hoffman]

At 6:08 PM +0200 5/17/06, Robert Sayre wrote:

On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:

 >Where is that written down?

RFC 2026.


That's a long document that's been updated by other process RFCs. Care
to point me at the relevant section? I didn't see one.


Sections 4.1 describes what is appropriate for standards track; 
section 4.2 describes what is appropriate for Informational and 
Experimental RFCs.


--Paul Hoffman, Director
--Internet Mail Consortium

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Robert Sayre]

On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:

At 7:11 AM +0200 5/17/06, Robert Sayre wrote:
>On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:
>>
>>This document describes an extension to an existing standards-track
>>document: it should either be on standards track or it should not be
>>an RFC.
>
>Where is that written down?

RFC 2026.


That's a long document that's been updated by other process RFCs. Care
to point me at the relevant section? I didn't see one.


>  Didn't Julian just get some WebDAV
>extensions approved as Experimental?

Maybe, but that's irrelevant.


I don't know much about the IETF, but I do know the process consists
mostly of the unwritten rules, rather than the written ones. So, it
seems to me that it is very much relevant.

In fact, I can quote you on this, from the initial Atom meeting at Sun
Microsystems.
"If you're big on process, the IETF probably isn't for you", or
something to that effect. Why the change of heart?


The fact that some WGs don't follow the
IETF process doesn't mean we should do the same. If our AD (who is
also the AD for WebDAV)


That's true in the sense that our AD is in the Apps area. However, Ted
Hardie is the AD advisor for WebDAV, and those documents were approved
before Lisa was an AD, IIRC. But, I suspect you knew all of that.


wanted this document to not be on standards
track, she would not have put out the IETF last call for the document
to be on standards track.


OK, phrase it that way. Why does our AD want this document on the
standards track? It was clearly designed without much research, no
input from client implementers, and contains lots of extra cruft. We
also

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Paul Hoffman]

At 7:11 AM +0200 5/17/06, Robert Sayre wrote:

On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:


This document describes an extension to an existing standards-track
document: it should either be on standards track or it should not be
an RFC.


Where is that written down?


RFC 2026.


 Didn't Julian just get some WebDAV
extensions approved as Experimental?


Maybe, but that's irrelevant. The fact that some WGs don't follow the 
IETF process doesn't mean we should do the same. If our AD (who is 
also the AD for WebDAV) wanted this document to not be on standards 
track, she would not have put out the IETF last call for the document 
to be on standards track.



 You seem to be saying IETF
participants don't get to have anything other than a black/white
opinion on the readiness of this document.


Correct.


 I disagree, and I also
think it's kind of inappropriate for you to be managing discussion in
this way. After all, it's not a WG document, is it?


Nope, and that's why I said it as an IETF process weenie, not as WG co-chair.


 I would have said
this should go Experimental, but it's not clear that the author is
willing to change the document in any meaningful way, so there's no
experiment to conduct.


If you want to change RFC 2026, that's fine, but this is not the 
right forum to do so.


--Paul Hoffman, Director
--Internet Mail Consortium

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[A. Pagaltzis]

* Robert Sayre <[EMAIL PROTECTED]> [2006-05-17 07:25]:
> I would have said this should go Experimental,

+1

We can wait and see what problems crop up in practice with the
contested attributes, and whether extensibility according to Sec
6.4. ff (or lack thereof) turns out to be paramount or, to borrow
Tim’s turn of phrase, a molehill.

If it works out, just reissue it; if not, there’s room to go back
and fix it.

Sounds reasonable enough to me.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Julian Reschke]

I'm with Robert here.

To clarify what happened with the WebDAV specs he mentioned...:

- WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda, 
and currently is implemented only by two vendors. Thus, "experimental" 
seems to be absolutely the right category.


- WebDAV Redirect References (RFC4437) was on the working group's 
agenda, but in the end too few implementors seemed to be interested 
(again: two). Thus "experimental" wasn't what I would have hoped to
achieve, but at least this kind of publication preserves the effort that 
was invested, and it also documents running code in some implementations.


Best regards, Julian

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Bill de hÓra]

Paul Hoffman wrote:

These are not reasons to make something an Informational RFC. In the 
minds of developers, there is no difference between Informational and 
standards-track RFCs. The IETF's differentiation between types of RFCs 
has always been confusing, but that is not a reason for us to niggle on 
a particular document.


Understood - thanks for educating me.

If the document has "room for interop problems", and/or security issues, 
they should be stated so that the sponsoring AD, and the IESG as a 
whole, can decide whether or not the document is ready to be an RFC, 
regardless of the type of RFC it will become.


Ok. I'll try to be more specific rsn.

cheers
Bill

Re: Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Robert Sayre]

On 5/17/06, Paul Hoffman <[EMAIL PROTECTED]> wrote:


This document describes an extension to an existing standards-track
document: it should either be on standards track or it should not be
an RFC.


Where is that written down? Didn't Julian just get some WebDAV
extensions approved as Experimental? You seem to be saying IETF
participants don't get to have anything other than a black/white
opinion on the readiness of this document. I disagree, and I also
think it's kind of inappropriate for you to be managing discussion in
this way. After all, it's not a WG document, is it? I would have said
this should go Experimental, but it's not clear that the author is
willing to change the document in any meaningful way, so there's no
experiment to conduct.

Informational and Experimental RFCs

  The role of Informational RFCs is often debated in the IETF.  Many
  people like having them, particularly for specifications that were
  created outside the IETF but are referenced by IETF documents.  They
  are also useful for specifications that are the precursors for work
  being done by IETF Working Groups.  On the other hand, some people
  refer to Informational RFCs as "standards" even though the RFCs are
  not standards, usually to fool the gullible public about something
  that the person is selling or supporting.  When this happens, the
  debate about Informational RFCs is renewed.

  Experimental RFCs are for specifications that may be interesting, but
  for which it is unclear if there will be much interest in
  implementing them, or whether they will work once deployed.  That is,
  a specification might solve a problem, but if it is not clear that
  many people think that the problem is important, or think that they
  will bother fixing the problem with the specification, the
  specification might be labeled an Experimental RFC.  If, later, the
  specification becomes popular (or proves that it works well), it can
  be re-issued as a standards-track RFC.  Experimental RFCs are also
  used to get people to experiment with a technology that looks like it
  might be standards track material, but for which there are still
  unanswered questions.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Informational vs. standards-track (Was: Re: Last Call: 'Atom Threading Extensions' to Proposed Standard (draft-snell-atompub-feed-thread))

[Paul Hoffman]

At 1:20 AM +0100 5/17/06, Bill de hÓra wrote:
I'm -0 this becoming a Proposed Standard. I think this is really 
cool, has room for interop problems, probably has security issues, 
and thus is arguably premature/innovative and could be considered 
informational.


These are not reasons to make something an Informational RFC. In the 
minds of developers, there is no difference between Informational and 
standards-track RFCs. The IETF's differentiation between types of 
RFCs has always been confusing, but that is not a reason for us to 
niggle on a particular document.


This document describes an extension to an existing standards-track 
document: it should either be on standards track or it should not be 
an RFC.


If the document has "room for interop problems", and/or security 
issues, they should be stated so that the sponsoring AD, and the IESG 
as a whole, can decide whether or not the document is ready to be an 
RFC, regardless of the type of RFC it will become.


--Paul Hoffman, Director
--Internet Mail Consortium