I support moving draft-nottingham-atompub-feed-history-08.txt to Proposed Standard [eom] -- Robert Sayre

2007-01-23 Thread Robert Sayre





Please add draft-ietf-atompub-typeparam to the charter [eom] -- Rob Sayre

2007-01-04 Thread Robert Sayre


--

cheers,

Robert Sayre

I would have written a shorter letter, but I did not have the time.
http://franklinmint.fm/
http://feedautodiscovery.org/



Re: Autodiscovery IPR and Process Concerns

2006-11-30 Thread Robert Sayre


On 11/30/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


What rhetorical device is it to point out the rhetorical devices
used by other participants in a discussion?


Gosh, Aristotle. I'm sure I don't know. Y'all let me know when y'all
figure it out.

- Bobby



Re: PaceEntryMediatype

2006-11-30 Thread Robert Sayre


On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:


The key problem with application/atom+xml;type=entry is that at least
one major browser (Firefox 2.0) still treats it as a feed and shows the
subscribe link.


Of course it does. Any program interested in consuming information is
going to ignore unknown parameters.

--

Robert Sayre



Re: [rss-public] Autodiscovery IPR and Process Concerns

2006-11-30 Thread Robert Sayre


On 11/30/06, Lachlan Hunt [EMAIL PROTECTED] wrote:


The point to all this is that you shouldn't place too much weight on the
status of the specification as a whole.  You need to consider the
stability and maturity level of each section individually.  Thus, while
proceeding with Autodiscovery as an RFC may yield a fully complete and
endorsed specification more quickly than HTML5


Actually, the process you describe is pretty much identical to the
IETF process in letter. For example, it took many years for RFC3986 to
appear, describing URIs at the level of Full Standard.

In practice, the WHAT-WG is more accountable, because there is a
documented process for resolving disputes that actually empowers the
group's participants. You'll find no such thing in the IETF,
especially with an individual draft.  The WHAT-WG is also much more
rigorous in testing and research than the IETF, so I have to agree
that there is little benefit to pursuing the Internet-Draft. Claims
that the WHAT-WG is too slow are overblown at best -- getting
something to Proposed Standard is not that interesting.

The (active!) wiki at http://feedautodiscovery.org is rapidly
eclipsing any other source on autodiscovery, and it can include
information that would not be permitted in an IETF or WHAT-WG
document, so it will always be more valuable and current.

--

Robert Sayre



Re: [rss-public] Autodiscovery IPR and Process Concerns

2006-11-29 Thread Robert Sayre


On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:


There's absolutely nothing to disclose.


Are you sure about that?


I just prefer to limit my
material contributions to various standards activities to organizations
whose IP policies have been vetted and approved by my employer's IP
lawyers or to posts on my personal weblog.  Your wiki qualifies as neither.


Interesting. What is the difference between your personal weblog and a
wiki, in IP terms?

Keep in mind that a wise man once said Anyone who uses the term
'Intellectual Property' is confused or trying to confuse you.



I had originally suggested that the draft be resubmitted as a WG draft.
 The Area Director and the WG chairs suggested that since autodiscovery
was not covered under the original charter it would be better to pursue
it as an individual submission.  I decided to do so only on the
condition that the same open process used for the development of the
Atom and APP specs would be followed -- meaning that there would be no
closed door decisions and that clear consensus had to develop via open
discussions on the WG mailing list before any change to the document was
made.


This entire paragraph is plainly false. All of the decisions you refer
to were made without consulting the WG, the community, or what have
you.



  If y'all think


Ah, this is what's called innappropriately folksy. It's a common
rhetorical device used when the speaker wants to appear that they're
on the side of the common man or equivalent. The president of the
United States makes frequent use of this device.

Mission Accomplished!,

Robert Sayre



Re: PaceEntryMediatype

2006-11-29 Thread Robert Sayre


On 11/30/06, James M Snell [EMAIL PROTECTED] wrote:



John Panzer wrote:
 [snip]
  +1 to doing this outside of APP (but concerned about deprecating...)
 [snip]

An I-D / RFC can update another RFC


I think John should edit.

--

Robert Sayre



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread Robert Sayre


James M Snell wrote:


Lachlan Hunt wrote:
  

[snip]


Move Autodiscovery forward as an Informational RFC
  

But if it were published as an informational RFC, what purpose would it
serve?




To document best practice as it relates specifically to syndication
feeds.  


The draft makes several requirements. That's not documenting best practice.


For example, HTML5 says nothing about whether the relative order
of feed autodiscovery links within a document is significant.  The Atom
autodiscovery draft, however, defines that the order is significant.
  


Which software does that requirement concern?

- Rob



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread Robert Sayre


James M Snell wrote:

I didn't write the doc so please don't complain to me about what's in
there.  If there is something that needs to be changed write up a pace.
  


Uh, no. I don't think you should write it at all, and I resent having to 
waste my time following this completely redundant effort to make sure it 
doesn't do damage by making requirements that would break backwards 
compatibility with previous Firefox versions.


The WHAT-WG text is fine.

- Rob



PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

2006-11-28 Thread Robert Sayre


James M Snell wrote:

I do believe that participation in this discussion is optional, as is
choosing whether or not to support any particular IETF draft
(informational or otherwise) so there is absolutely no need (or desire)
for you to waste your time here.  


Nonsense. You know very well that projects I work on will get bug 
reports on standards compliance if you change something. So, yes, I do 
have to waste my time here. Since I maintain autodiscovery code people 
actually use, you'd think my opinion would count for something.


== Abstract ==

Don't move forward with the autodiscovery draft.

== Status ==

Proposed

== Rationale ==

At this point there seems to be no reason for the autodiscovery draft to 
exist, since the WHAT-WG has ably covered the subject in Web 
Applications 1.0.


http://whatwg.org/specs/web-apps/current-work/#alternate0

Reasons given for the continued existence of the IETF draft have been 
non-technical doubletalk.


== Proposal ==

Stop work on the autodiscovery draft.

== Impacts ==

Reduces mailing list traffic and standards noise.



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread Robert Sayre


Edward O'Connor wrote:

I am worried that there are three simultaneous efforts to spec out feed
autodiscovery: WA1, the RSS board's recent spec, and this draft. Ideally
this stuff would get specced just once. WHAT WG seems like a neutral
ground, syndication-format wise, so perhaps they're best positioned to
spec feed autodiscovery in a way that makes everybody happy.
  


Not only that, they are actually qualified to spec changes to HTML, 
which is what this is.


-Rob



Re: PaceRecommendFullURIsForAutodiscovery

2006-11-28 Thread Robert Sayre


James M Snell wrote:

http://www.intertwingly.net/wiki/pie/PaceRecommendFullURIsForAutodiscovery

Definite -1 on this one.  Buggy implementations just need to be fixed.
Writing specs to bugs is silly at best.
  


The link element is specified by HTML4/5.

-Rob



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread Robert Sayre


James M Snell wrote:

Heh.. I probably should not have been taking a drink when I read this
last sentence :-).  You do know that we're talking about the
*syndication community* right?
  


Actually, it's an HTML issue, so I don't see why the RSS Board or the 
Atom list or any incarnation of the syndication community would be an 
appropriate venue.


-Rob



Re: PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread Robert Sayre


Sylvain Hellegouarch wrote:

If autodiscovery is only a browser feature then indeed it has nothing to
do here. But is it only meant for browsers?
  


Browsers are surely the primary target, but bots and other HTML UAs make 
use of it. Both uses are covered by the people working on HTML, in the 
WHAT-WG and the W3C.


-Rob



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread Robert Sayre


Lachlan Hunt wrote:


http://www.rssboard.org/news/70/vote-rss-autodiscovery-specification#discuss 



Like the Atom Autodiscovery draft, this spec serves no purpose. 
Autodiscovery is being defined in the HTML5 spec where it belongs, with 
both the alternate 
http://www.whatwg.org/specs/web-apps/current-work/#alternate0 and feed 
http://www.whatwg.org/specs/web-apps/current-work/#feed0 relationships.


Fully agree.

-Rob



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread Robert Sayre


James M Snell wrote:

Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established.  What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.
  


Huh? I'm not sure what you mean--you send way more messages than I do. 
I'm merely pointing out facts.


I think the following entry from the WHAT-WG blog might be of use here.

http://blog.whatwg.org/proposing-features

Here are some key things that any proposal should include:

* What is the problem you are trying to solve
* What is the feature you are suggesting to help solve it?
* What is the processing model for that feature, including error 
handling? This should be very clear, including things such as event 
timing if the feature involves events, how to create graphs representing 
the data in the case of semantic proposals, etc

* Why do you think browsers would implement this feature
* Why do you think authors would use this feature?

- Rob



Re: PaceMakeAutodiscoveryInformational

2006-11-28 Thread Robert Sayre


James M Snell wrote:

Ok, so given that I think this is the fifth or sixth note in which
you've said exactly the same thing, I think your position has been well
established.  What would be excellent is if you'd give others the
opportunity to weigh in on it before trying so hard to filibuster it.
  


This looks like an inappropriate personal attack to me. Surely James has 
been warned about this in the past?


- Rob




Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

2006-11-28 Thread Robert Sayre


Rogers Cadenhead wrote:

My thinking was that we're accomplishing a task
similar to the creators of the Robots Exclusion meta
tag [1] -- put X values in element Y to achieve effect
Z.
  


Hmm, have to disagree. The behavior is already well-documented, so this 
isn't accomplishing much. This effort is similar to rewriting the robots 
exclusion meta tag document. Is there some aspect of the WHAT-WG 
document that bothers you? Why not provide feedback there?


http://whatwg.org/mailing-list

The feedback you received from WHAT-WG members on the RSS Board blog was 
extremely detailed and accurate.


- Rob



Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

2006-11-28 Thread Robert Sayre


On 11/28/06, Rogers Cadenhead [EMAIL PROTECTED] wrote:


I have no idea how to gauge the
likelihood they'll achieve it. Or whether they'll
respect current autodiscovery functionality in MSIE 7
and Firefox 2.0.


My experience is that the IETF is essentially unresponsive to backward
compatibility concerns, to the extent that they will debate the
meaning of the term MUST. It's like existential poetry.

In my experience, the WHAT-WG doesn't make any changes that break
compatibility unless users are already having problems caused by
implementation divergence. To make sure this is true, they research
and make decisions based on metrics, rather than ill-defined consensus
handwaving and individually-authored drafts with no support from
client implementors. I've even seen it claimed that servers are
clients too, in the IETF.



 Why not provide feedback there?

I will if that's where autodiscovery goes.


It is already there.



Seems like a good idea to tell Atom publishers how to
support autodiscovered feeds.


They already know how, in general. The WHAT-WG is the place to work
out edge cases in HTML semantics.

Sylvain Hellegouarch wrote:


there will be little harm done


Actually, the proposal seems so poorly researched and poorly
coordinated with WHAT-WG that I don't see how you can make that claim.
When Pilgrim wrote the draft, there weren't as many existing
implementations, so his approach made more sense at the time.

--

Robert Sayre



Re: WHAT-WG, feed and alternate (was: Re: PaceAutoDiscoveryDraftIsPointless)

2006-11-28 Thread Robert Sayre


On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:


 3. We define a new media type for Atom Entry Documents,
  e.g. application/atomentry+xml


No one relies on Atom Entry alternates now, so this is the best
option. We should tack it onto the APP draft, since that will solve
issues with the accept element there. And praise to mnot, who
suggested we do this in RFC4287 but was overruled by the WG (including
myself).

--

Robert Sayre



Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

2006-11-28 Thread Robert Sayre


On 11/28/06, Tim Bray [EMAIL PROTECTED] wrote:

On Nov 28, 2006, at 3:16 PM, Robert Sayre wrote:

 They already know how, in general. The WHAT-WG is the place to work
 out edge cases in HTML semantics.

Over the course of history, a remarkable number of different groups
have jumped up and down and said *We're* the ones defining HTML!!!
Listen to *us*!!!.


Yes, and *all* have them have done a poor job, except for the WHAT-WG.
I am not a frequent participant there, but I have noticed a large leap
in quality. For example, Firefox 2 is already shipping section 5.3.5
of HTML5, DOM Storage.

http://www.whatwg.org/specs/web-apps/current-work/#scs-client-side

I am supposed to be implementing getElementsByClassName today...
instead I am posting to this list. *sigh


It's foolish to draw conclusions about any HTML-
related spec based either on which group is originating it


Agree. But the WHAT-WG document and process are much better than the
alternatives.


or what anyone claims the browser engineers are going to do.


Well, I've made the last 5-10 changes to the autodiscovery-related
code in one popular browser, so I can go by what I've already done,
rather than predicting the future.

Here is the bug where I'm going to implement the 'feed' relation, as
specified by the WHAT-WG:
https://bugzilla.mozilla.org/show_bug.cgi?id=362156

--

Robert Sayre



Re: [whatwg] PaceAutoDiscoveryDraftIsPointless

2006-11-28 Thread Robert Sayre


On 11/28/06, James M Snell [EMAIL PROTECTED] wrote:


 2. Are multiple alternate links with the same type attribute
considered to be equivalent regardless of where those links appear
in the document.


What do you mean by equivalent ?


--

Robert Sayre



Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

2006-11-27 Thread Robert Sayre


James M Snell wrote:

The process for moving forward on this spec will be the same as with
Atom and APP.  


No, it won't. It's not a WG document.

Does the draft diverge from existing browser behavior? Do browsers 
implement aspects of the document differently? What problems have you 
seen that make standardization necessary?


Without some evidence that the document serves a purpose, I'm afraid I 
don't see the point.


- Rob

P.S. -- the author affiliation information in the draft appears to be 
inaccurate.




Re: [Fwd: I-D ACTION:draft-snell-atompub-autodiscovery-00.txt]

2006-11-27 Thread Robert Sayre


James M Snell wrote:

Consensus calls will be posted
periodically; 
  


That's not a process I can live with. Maybe this draft would be a better 
fit for the WHAT-WG or the W3C.



Does the draft diverge from existing browser behavior? Do browsers
implement aspects of the document differently? What problems have you
seen that make standardization necessary?




I dunno... you're the one that that writes browser code, you tell me.
  


I don't think it's a problem worth solving, absent any evidence to the 
contrary. Mozilla doesn't seem to get many bug reports on this matter.


You certainly seemed to think it was a good fit before. 


I changed my mind later on.




How so?  Given that my volunteering to serve as the editor of this
document has nothing to do with my day job it would be inappropriate and
dishonest for me to associate my employers name with the work.


We all participate in the IETF as individuals. Affiliations are a 
professional courtesy.


-Rob



Re: Forward Compatibility

2006-11-22 Thread Robert Sayre


James M Snell wrote:

IOW, using the XHTML2 div as the child is compliant in a strictly sense
but should be avoided because it will likely cause problems.
  


An XHTML2 div is not compliant. The normative reference is to XHTML 
Modularization, and the accompanying XHTML1 definitions and namespace. 
In practice, this requirement is somewhat malleable, since XHTML's DTD 
requires that all elements reside in the default namespace (a flaw in 
XHTML), and XHTML Modularization makes some other universally-ignored 
requirements.


XHTML2's namespace is different, though there is an open issue to change 
to the same namespace that XHTML1 uses. Even if the namespace were the 
same, Atom processors are not required expected to understand or comply 
with any XHTML[2] markup.


In other words, Atom processors will pick up (X)HTML features as they 
see fit. The spec is quite specific on this point (using the markup is a 
MAY). In practice, (X)HTML support and security varies widely.


-Rob



Re: [atom-syntax] Atom bidi

2006-11-03 Thread Robert Sayre


James M Snell wrote:

Robert,

It's been a few weeks since this came up.  I was wondering if you'd be
able to give some kind of estimate on when you might have a chance to
document what you had in mind for mozilla/firefox/thunderbird.  No
pressure, of course, I just don't want this issue to stall out for lack
of discussion.
  


I still have something coming. The IETF meeting means the secretariat 
won't process a draft right now.



-Rob



Re: [atom-syntax] Atom bidi

2006-10-17 Thread Robert Sayre


fwiw, I have no intention of reading the Snell bidi draft, or 
implementing what might be inside. As I've mentioned several times, I am 
already implementing a solution. I will document it and roll it onto the 
standards track as an update to RFC4287.


-Rob

James Holderness wrote:


If you're going to require a separate namespace for bidi support, 
maybe it's best to use XHTML 1.0 and just toss out the lro and rlo 
values. I know I was originally pushing for those to be included, but 
now that I've seen how inconsistent the bdo support is in browsers I 
think they're probably going to be a waste of time. Nobody is going to 
get them right.


Regards
James





Re: [atom-syntax] Atom bidi

2006-10-17 Thread Robert Sayre


James M Snell wrote:

How kind of you.  Would you mind sharing some of the details with us now
so that we can come to a common solution that works with more than just
Firefox and Thunderbird?  

It'll work fine with everythign



Re: [atom-syntax] Atom bidi

2006-10-17 Thread Robert Sayre


James M Snell wrote:

Would you mind sharing some of the details with us now
so that we can come to a common solution that works with more than just
Firefox and Thunderbird?  

That is absurd.

This message has used up my atom-syntax time for the moment, so I guess 
you'll have to wait, or use up other people's atom-syntax time.


-Rob




Re: [atom-syntax] Atom bidi

2006-10-17 Thread Robert Sayre


Robert Sayre wrote:


fwiw, I have no intention of reading the Snell bidi draft, or 
implementing what might be inside. As I've mentioned several times, I 
am already implementing a solution. I will document it and roll it 
onto the standards track as an update to RFC4287.
To be clear, I have no intention of ignoring input from this list, since 
that almost always results in improvements. I also have no intention of 
implementing anything that should have approval from the group, unless I 
have that approval. However, I don't think I'm obligated to let our more 
enthusiastic participants dictate the manner and pace of my personal 
contributions.


-Rob





Re: Clarify foreign markup: [was Atom Syndication Format To Draft Standard?]

2006-10-03 Thread Robert Sayre


Bill de hOra wrote:


A. Pagaltzis wrote:


I think given the above background you'll agree that the intent
of the document is pretty coherent. 


I couldn't tell whether new Atom extensions are foreign markup, or 
something else to be dealt with under wrt being a forward-compatible 
friendly consumer. It's kind of circular. In short, I guessed and you 
told me I was wrong.


Bill, please show us a bug? I don't think defining terms until we've got 
a good subset of an English dictionary

will make the format more interoperable.

-Rob



Re: Atom and bidi

2006-10-03 Thread Robert Sayre


James M Snell wrote:

Yep, I'll work up a pace.

I find this more than a little pushy.

I found the problem, I think I have an answer, I've already written the 
code, and I said I would deal with it earlier today:


http://www.imc.org/atom-syntax/mail-archive/msg18874.html

-Rob



Re: Atom and bidi

2006-10-03 Thread Robert Sayre


James M Snell wrote:

Robert Sayre wrote:
  

James M Snell wrote:


Yep, I'll work up a pace.
  

I find this more than a little pushy.




Cool!
  


???


Then write up a pace.  We can compare the two options and figure out the
best way to move forward.


I am not sure what you are talking about.

-Rob



Re: Atom and bidi

2006-10-03 Thread Robert Sayre


James M Snell wrote:

If that's the case, it would be great if you would provide a concrete
proposal that we can discuss or at least describe exactly what you're
looking for.  
  


You seem to think I'm obligated to participate in a volumetocracy[1] in 
order to get my work done. I'm not, so there is no 'we'.


-Rob


[1] http://www.franklinmint.fm/blog/archives/000873.html



Atom Syndication Format To Draft Standard?

2006-10-02 Thread Robert Sayre


I think we should move the format to Draft Standard by clearing up any 
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined 
in XHTML.


Thoughts?

Robert Sayre



Re: Atom Syndication Format To Draft Standard?

2006-10-02 Thread Robert Sayre


Bjoern Hoehrmann wrote:


I think that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', as defined in CSS 2.1?
  

Sure.


Elliotte Harold wrote:


Which elements would these be attached to? 


All of them.


Paul Hoffman wrote:

At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up 
any errata and adding two attributes: 'dir' and 'unicode-bidi', as 
defined in XHTML.


We can't both add features and move to Draft Standard at the same time.


Dang, where'd that rule come from? It would probably be easier to add 
them in a separate document, huh?


Robert Sayre



Re: Atom Syndication Format To Draft Standard?

2006-10-02 Thread Robert Sayre

Paul Hoffman [EMAIL PROTECTED] writes:

 
 Probably RFC 2026, but if not there, it is certainly in the folklore 
 of How Things Are Done.

That's unfortunate. A documented process is a requirement for open standards
development, in the opinion of many

http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf

 
 It would probably be easier to add them in a separate document, huh?
 
 Maybe, but that would then confuse the issue by having two docs 
 people would expect to have read in order to do the format. Given the 
 very marginal value of Draft Standard, we should probably just revise 
 and recycle at Proposed rather than split into two.

There is one mistake in the Relax NG (atom common attributes on author or
something) and at least one section that is somewhat unclear around the external
div in XHTML. 

The i18n attributes seem needed to display text without a guess based on
xml:lang.  Maybe we don't even need unicode-bidi. I don't think it would be
smart to take other features.

Robert Sayre





Re: Atom Syndication Format To Draft Standard?

2006-10-02 Thread Robert Sayre


Paul Hoffman wrote:

At 6:23 PM + 10/2/06, Robert Sayre wrote:
That's unfortunate. A documented process is a requirement for open 
standards

development, in the opinion of many


If it is a true requirement, then I guess the IETF is an abysmal 
failure. Oh, well.




Well, openness is only one metric.



needed to display is often an issue the IETF ignores, so we might 
avoid it if the desire is to get to Draft Standard.


But Julian's second message needs to be dealt with first, and I assure 
you that many of those documents are not going to be going to Draft 
Standard any time soon (if ever) because there is no energy to test 
every required feature in the documents.



Well, I figured it might make sense to advance something that pretty 
much works. I now see how foolish that idea was. Cycling at proposed 
will be fine.


Robert Sayre



Re: clarification: escaped

2006-07-25 Thread Robert Sayre


On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote:


The RFC says that the content should be 'escaped' for type 'text/html'
in 3.1.1.2, but dosn't define what that is.


IIRC, WG discussion touched on this point, and the WG decided the
definition wasn't important, given the example. Is there a problem
you're hoping to clear up?

--

Robert Sayre

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



Re: Re: clarification: escaped

2006-07-25 Thread Robert Sayre


On 7/25/06, Bill de hÓra [EMAIL PROTECTED] wrote:


It came up on django irc. I'd assumed for whatever reason that escaping
was limited to the usual XML suspects, but when asked about html content
I knew I didn't know for sure, especially wrt HTML character entities.
And I didn't know whether Atom code could get away with escaping  and .


I'm not certain I understand the issue, but if the question concerns
what happens when an Atom processor encounters a document with no
declared entities and contains a title like this:

atom:title type=htmllt;bnbsp;hmmlt;b/atom:title

that is an XML fatal error, no doubt, as the ampersand before nbsp
must be escaped. Concretely, Mozilla will give you a DOM with a
non-breaking space if you write this:

atom:title type=htmllt;bamp;nbsp;hmmlt;b/atom:title

--

Robert Sayre

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



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-07-19 Thread Robert Sayre


On 7/19/06, Julian Reschke [EMAIL PROTECTED] wrote:


What we're talking about here is not change control over the namespace
or the namespace name! It's about what happens if an HTTP client
dereferences that URL, which is irrelevant for the purpose of XML
namespaces.


It's irrelevant for the XML software, but not the implementer, which
is why you want it to redirect to something. That's the problem I have
with it.

--

Robert Sayre



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-07-18 Thread Robert Sayre


On 7/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote:

We don't have rules against such namespace choices.  We
could argue about whether or not we should have such rules,


Well, there is a BCP about this.


At this point, it's very rare to
pull a document or change something like this that would affect
implementations.  Often the remedy at this stage is...


I should hope that the IETF/IESG doesn't encounter this situation
often, but that doesn't seem like a strong argument. How commonly are
private namespaces used in IETF standards? The right argument to have
is whether the namespace is a problem. Even the draft's author
acknowledges that it is a valid concern, though he probably doesn't
have the same solution in mind.

--

Robert Sayre



Re: HTTP Authentication Options

2006-07-17 Thread Robert Sayre


On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote:


In most such systems, the passwords are stored in the password
database as a one-way hash of the password.


Systems that use forms will often do this as well...




IMPLEMENTATION ISSUES
I'm given to understand that there are ways in which the Digest spec
is unclear and that implementation and interoperability is fairly
spotty.


...which makes it impossible to use the existing auth database with
Digest. Digest's more extensive protection options are basically
unimplemented. Digest is extremely underspecified wrt to encoding of
non-ascii characters. Some implementations respect the charset
parameter specified in SASL Digest (RFC 2831). Others use the encoding
of the page. No one is quite sure what IE does.* Mozilla uses UTF-8
all the time.

* http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx

The only thing we can reasonably say is Basic+TLS, but that's sort of
silly, since many servers and some clients won't implement it. I'd
rather skip the collective game of pretend.

--

Robert Sayre

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



Re: HTTP Authentication Options

2006-07-17 Thread Robert Sayre


On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote:


If by existing auth database you mean the basic or form database,
this is generally correct--though one could in fact implement
an auth database that would work for both.



Right. But some of our server implementers couldn't implement it if
they wanted to.



 Digest's more extensive protection options are basically
 unimplemented.

By more extensive protection options do you mean the auth-int mode?


Yes, but I believe some clients even screw up auth mode, and only work
with 2069-style. Container-managed security in Java Servlet
implementations often doesn't work with Digest, at least with the
vendor-provided authentication classes.


I'm not familiar with what HTTP implementations do, but I'll note
that SIP implementations will do auth-int.



Mozilla doesn't do it. Apache (mod_auth_digest) doesn't do it. Opera
does. I don't know what MS libraries do these days.


Feel free to take this point up with the IESG. I doubt you'll find
them very sympathetic, however.


Well, I'd like the document to reflect reality, but I suspect that
will be no match for the IESG rules in combination with some WG
members that want Basic+TLS enshrined in the document because that is
what they are going to deploy.

--

Robert Sayre



Re: HTTP Authentication Options

2006-07-17 Thread Robert Sayre


On 7/17/06, Eric Rescorla [EMAIL PROTECTED] wrote:


Right. My point was merely that it's doable as a matter of
programming.



That's debatable, from an HTTP server's perspective, because the
server must check (and temporarily store) the whole request before it
can tell if the client knows the password. Not a good way to handle
video uploads.

Other authentication protocols, such as Amazon S3 auth, include the
Content-MD5 header in the digest calculation so the server only has to
check message body integrity after it has verified that the client
knows the password.

--

Robert Sayre

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



Re: Very brief minutes from the Atompub WG meeting

2006-07-16 Thread Robert Sayre



There is a difference between mandatory to implement and mandatory to 
deploy.


???

My client supports basic+tls, but none of the binaries include it

--

Robert Sayre



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-07-11 Thread Robert Sayre


On 7/11/06, Martin Duerst [EMAIL PROTECTED] wrote:

At 10:43 06/07/10, Robert Sayre wrote:

Hi Lisa,

Thanks for the clarification. You may have missed another question I
recently asked, so I'll repeat it here. I am concerned that purl.org
lists the document author as the owner of the namespace URI, and I
wonder how the IESG came to the conclusion that the namespace is not a
problem. I see Sam Hartman raised the issue. What was the resolution?
Could the draft advance to Draft- or Full-Standard in that namespace?

I looked at that namespace shortly.


Thanks, but I don't see how you would be able to answer any of the
questions I asked above.


It seems that it would be easy
to change the owners to make clear that this is owned by the IETF.
This can be done whenever it's needed.


Actually, mnot delegates that path. Can he take it away? He's warned
us about the very same thing wrt to Atom 0.3.


A purl namespace in and
by itself isn't any better or worse than a W3C namespace.



I don't see any factual basis for that statement. For instance, the
IETF has a liason relationship with W3C.

--

Robert Sayre



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-07-09 Thread Robert Sayre


On 7/4/06, Lisa Dusseault [EMAIL PROTECTED] wrote:

I wrote the synopsis, in which I was careful not to state that it was
a WG document.  I believe it was accurate for what it said although
it's very brief.  I discussed explicitly with the IESG during the
IESG tele-conference calls that there was some lengthy debate and
disagreement over certain mechanisms in the draft.



Hi Lisa,

Thanks for the clarification. You may have missed another question I
recently asked, so I'll repeat it here. I am concerned that purl.org
lists the document author as the owner of the namespace URI, and I
wonder how the IESG came to the conclusion that the namespace is not a
problem. I see Sam Hartman raised the issue. What was the resolution?
Could the draft advance to Draft- or Full-Standard in that namespace?

--

Robert Sayre

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



Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

2006-06-28 Thread Robert Sayre


On 6/28/06, James M Snell [EMAIL PROTECTED] wrote:


Our default behavior will be to return the div.  A
separate API will provide the content without the div.


So, standards-off-by-default then? Unbelievable.

--

Robert Sayre



Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

2006-06-28 Thread Robert Sayre


Irrelevant. The content in the entries below should be handled the same way:

entry xml:lang=en xml:base=http://example.com/foo/;
  ...
  content type=xhtml
  xhtml:div xml:lang=fr xml:base=http://example.com/
feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div
  /content
/entry

entry xml:lang=en xml:base=http://example.com/foo/;
  ...
  content type=xhtml xml:lang=fr xml:base=http://example.com/
feu/
  xhtml:div xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div
  /content
/entry


On 6/28/06, Antone Roundy [EMAIL PROTECTED] wrote:


On Jun 28, 2006, at 12:06 PM, A. Pagaltzis wrote:
 * James M Snell [EMAIL PROTECTED] [2006-06-28 20:00]:
 A. Pagaltzis wrote:
 * James M Snell [EMAIL PROTECTED] [2006-06-28 14:35]:
 Hiding the div completely from users of Abdera would mean
 potentially losing important data (e.g. the div may contain
 an xml:lang or xml:base) or forcing me to perform additional
 processing (pushing the in-scope xml:lang/xml:base down to
 child elements of the div.

 How is that any different from having to find ways to pass
 any in-scope xml:lang/xml:base down to API clients when the
 content is type=html or type=text? I hope you didn't punt
 on those?

 Our Content interface has methods for getting to that
 information.

 Then stripping the `div` is not an issue, is it?

Consider this:

entry xml:lang=en xml:base=http://example.com/foo/;
...
content type=xhtml
xhtml:div xml:lang=fr xml:base=http://example.com/
feu/xhtml:a href=axe.htmlaxe/xhtml:a/xhtml:div
/content
/entry

Whether there's a problem depends on whether one requests the
xml:base, xml:lang, or whatever for the atom:content element itself
or for the CONTENT OF the atom:content element, in which case the
library could return the values it got from the xhtml:div.  Except in
unusual cases like this, the result would be identical.

Certainly a distinction could be made between how an XML library
would handle this vs. how an Atom library would handle it.  An Atom
processing library might be expected to be able to do things like:

* give me the raw contents of the atom:content element
* give me the contents of the atom:content element converted to well-
formed XHTML (whether it started as text, escaped tag soup, or inline
xhtml)

In the former case, keeping the div feels like the right thing to do--
the consuming app would have to know to remove it.  In the latter
case, removing the div from xhtml content feels like the right thing
to do.  But unless the library gives me the xml:base, for example,
which applies to the content of the atom:content element (as
converted to well-formed xhtml or whatever), as opposed to the
xml:base which applied to the atom:content element itself, there's
potential for trouble.

...now that I think about it, if the library always returns the
xml:base which applies to the content of the element, that could
cause trouble too:

entry xml:lang=en xml:base=http://example.com/;
...
content type=xhtml
xhtml:div xml:lang=fr xml:base=feu/xhtml:a
href=axe.htmlaxe/xhtml:a/xhtml:div
/content
/entry

Here, if I get xml:base for the content of content, it will be
http://example.com/feu/;.  Then, if I get the raw content of the
element, strip the div, and apply xml:base myself, I'll erroneously
use http://example.com/feu/feu/; as the base URI unless I know to
ignore the xml:base attribute on the div.





--

Robert Sayre

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



Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

2006-06-28 Thread Robert Sayre


On 6/28/06, James M Snell [EMAIL PROTECTED] wrote:


Actually, switch this.  I realized after I sent this that I had it
backwards.  The default behavior will be to not return the div. A
separate API will provide the content with the div.



Next time, don't start out with egregious obfuscation, and then kick
and scream through tons of list traffic with beyond-bogus arguments.
Here's how it started:

http://mail-archives.apache.org/mod_mbox/incubator-abdera-dev/200606.mbox/[EMAIL 
PROTECTED]

It's a waste of other people's time. Once or twice is understandable,
reasonable people sometimes disagree on basic things. I think we're up
to 20 or 30 of these incidents with you, though.

At this point, it's not something to be replied to with a smart
remark. It belies contempt for your colleagues. We shouldn't have to
sit here and listen to specious tripe because it sounds semi-plausible
to a non-implementor.

It's abusive, and it's much worse than the nasty messages so many of
us have sent.

--

Robert Sayre



Re: [RFC 4287] unicity of atom:category element

2006-06-27 Thread Robert Sayre


On 6/27/06, James M Snell [EMAIL PROTECTED] wrote:


Slight addition to this,

The scheme not only disambiguates the term, it also identifies the means
of interpreting the term.  For instance, Tim Bray's feed uses a
scheme/term combo that can be concatenated to form a meaningful,
dereferencable URI.


There's no spec text to back this up. A convention might emerge, but
let's not BS it.

--

Robert Sayre

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



http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

2006-06-27 Thread Robert Sayre


When XHTML content is used,

The XHTML div element itself MUST NOT be considered part of the content.

http://atompub.org/rfc4287.html#rfc.section.4.1.3.3



This is hard to test with aggregators, but conforming libraries
definitely need to get this right.

http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

--

Robert Sayre



Re: http://www.intertwingly.net/wiki/pie/XhtmlContentDivConformanceTests

2006-06-27 Thread Robert Sayre


On 6/27/06, James M Snell [EMAIL PROTECTED] wrote:

Please define conformance in regards to this test.  That is, what is
the exact behavior that a library must perform when a code library has
an API like, getContent on the content element.

e.g., is a parser not conformant if it passes the DIV on to the
consuming application with the expectation that the application is
responsible for doing the right thing with it?


Don't be dense. Would the parser be conformant if it passed on the
feed, entry, and div elements with that expectation? I'll file a bug
on UFP and I bet you it'll get fixed without a question, because there
won't be a bad-faith interpretation to fight. That's two demerits this
week for you. Tsk tsk.

--

Robert Sayre

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



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-06-26 Thread Robert Sayre


On 6/26/06, The IESG [EMAIL PROTECTED] wrote:


Working Group Summary

This is not a WG draft.  Nevertheless, the AtomPub WG discussion on this draft
was fairly lengthy, and resulted in a number of changes to the draft.



Who wrote this summary? Even Paul went on the record saying there was
no consensus on several aspects of the document. This summary makes it
sound like it underwent a number of friendly suggestions, rather than
disapproval by at least half of the commenters, interupted only by
incorrect readings of RFC2026 and obfuscation by the document author.

--

Robert Sayre



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-06-26 Thread Robert Sayre


On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote:


Your reading might differ from others'.


I've read a lot of these, so I know this synopsis differs others.
Usually they stuff like WG is OK with this. It's perfectly natural
to question and appropriate things that seem out of the ordinary.

In the future, please save the oblique answers for someone who cares
to hear them.

--

Robert Sayre



Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard

2006-06-26 Thread Robert Sayre


On 6/26/06, Robert Sayre [EMAIL PROTECTED] wrote:

On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote:

 Your reading might differ from others'.

I've read a lot of these, so I know this synopsis differs others.
Usually they stuff like WG is OK with this. It's perfectly natural
to question and appropriate things that seem out of the ordinary.


er,  a little steamed here, that's not English.

It's perfectly natural to question whether things that seem out of the
ordinary are appropriate.

Anyway, you don't seem to have accurate answers on the process when it
doesn't match the outcome you're looking for.

--

Robert Sayre

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



Re: Feed Thread approved as a Proposed Standard

2006-06-24 Thread Robert Sayre


On 6/24/06, James M Snell [EMAIL PROTECTED] wrote:


It's not a vendor controlled namespace;  it's an individual controlled
namespace


Irrelevant.


that I'm more than happy to delegate to the IESG.

The IETF has complete change control of the spec at this point --
including changing the XML namespace used by the extension if doing so
would be appropriate.  I trust the IESG and the RFC editor to do
whatever is deemed to be appropriate.


The IESG approved it with no directions to the RFC editor. So your
conjecture comes at the wrong juncture. If you were qualified to
answer my message, that would be obvious. I'll note that you failed to
answer a single question I asked, which tells me they were good ones.



p.s. FUD is generally more effective when not based on generally false
and easily refuted assumptions



This is content-free flaming. But I'll note there was nothing false in
my message. And you didn't refute anything either. I'd say you're just
trying to intimidate people.

--

Robert Sayre



Re: Feed Thread approved as a Proposed Standard

2006-06-23 Thread Robert Sayre


On 6/23/06, Paul Hoffman [EMAIL PROTECTED] wrote:


It is not correct that they *need* to be, but there is no reason for
them not to be. In general:

- If a protocol is worked on in an open context, standards track is preferred



The most important parts of an open context are well-documented
decisions. That didn't happen here.

It is surely appropriate for IETF members to suggest an alternate
status for the document, no matter what the IESG eventually decides.
In this case, an appeal to the rules was made, but RFC 2026 does not
place limits on the sort of feedback the community may give. In
effect, an effort was made to end the discussion, rather than address
the issue.

I don't feel the community has control of this document, and that bothers me.

n.b. -- not inviting a rebuttal.

--

Robert Sayre



Re: Feed Thread approved as a Proposed Standard

2006-06-23 Thread Robert Sayre


On 6/23/06, Paul Hoffman [EMAIL PROTECTED] wrote:


I don't feel the community has control of this document, and that bothers me.

Once something is an RFC, the community has control in that an
effort can be made to obsolete a document with a new one,


I guess those scare quotes are appropriate, but the underlying point
is that I now have a Proprietary Standard designation for this
document. That's a bummer, because the stewardship of RFC4287 is also
in a similarly worrisome state. Open standards are not made by people
paid to write mailing list posts until everyone else gives up. I know
I don't have the bandwidth to cut through the brazen obfuscation
anymore.

--

Robert Sayre



Re: Sorry this is on-list; Robert does not seem to appreciate off-list mail

2006-05-31 Thread Robert Sayre


On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


I have no further commentary to offer.



Promise? I'm sick of getting rude mail from James after he's flown off
the handle. I doubt I'll receive any more.

--

Robert Sayre



Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]

2006-05-31 Thread Robert Sayre


On 5/31/06, Ernest Prabhakar [EMAIL PROTECTED] wrote:


While I'm not entirely thrilled with James, and I believe you provide
some useful perspective,
if you think it is appropriate and ethical to respond by posting
private email to the list, I must reluctantly conclude that this list
is better off without you.



James has taken private conversations on-list:

[  ] yes
[  ] no

So please, spare me the lecture. I don't want to get nasty emails from
James anymore. My problem is solved.

--

Robert Sayre



Re: Link rel test cases

2006-05-31 Thread Robert Sayre


On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


My interpretation of
these facts is that string comparison is explicitly expected.


Incorrect.

--

Robert Sayre



Re: OT Re: [OFF-LIST] Re: Fwd: Link rel test cases [OFF-LIST]

2006-05-31 Thread Robert Sayre


On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


If you hadn't dropped an asinine jab at him into a completely
unrelated thread you might not have created the problem that you
would then need to solve in the first place.


Actually, those were just the latest two. But you didn't know that,
did you? How about you go back to writing your Atom code?

If you have further comments, send them somewhere else. If you send
them to me, I'll be sure to put them with the other unread emails from
you.

--

Robert Sayre



Re: Link rel test cases

2006-05-31 Thread Robert Sayre


On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


Hi Robert,

* Robert Sayre [EMAIL PROTECTED] [2006-05-31 19:35]:
 On 5/31/06, A. Pagaltzis [EMAIL PROTECTED] wrote:
 
 My interpretation of these facts is that string comparison is
 explicitly expected.

 Incorrect.

I don't see how


If it was explicit, you wouldn't need to interpret. Thanks for playing.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-30 Thread Robert Sayre


On 5/30/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


 At the end of the day, the marketplace will work within the
 constraints of what 4287 allows; my feeling is that there are going
 to be a ton of extensions that will attach unforeseen metadata at
 arbitrary points with Atom documents, and implementations that fail
 to store these and make them retrievable will quickly be seen as
 broken.  -Tim

I find this to be a pretty compelling argument.


I don't find Tim's argument particularly compelling. It's crystal ball
stuff, and implementations are free to ignore *any* part of an Atom
document. In this case, it's another case of a WG member claiming
something is broken without a shred of spec text to back it up. If Tim
and others want that to be true, they have an RFC to revise.

--

Robert Sayre

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



Re: Feed Thread in Last Call

2006-05-30 Thread Robert Sayre


On 5/30/06, James M Snell [EMAIL PROTECTED] wrote:


Robert Sayre wrote:
[snip]
 document. In this case, it's another case of a WG member claiming
 something is broken without a shred of spec text to back it up. If Tim

The exact same can be said of the argument that the use of extension
attributes is broken.  There's not a shred of spec text to back it up.



I didn't say the use of extension attributes is broken. I said your
extension has no reason to use them, remember? You never gave a
technical reason for the change between last call and the previous
version.


Personally, I don't see them as broken, I just see them as extremely 
short-sighted.


That's how I see your extension.

Hey, maybe you could do RFC4287bis as an individual submission!

--

Robert Sayre



Re: Link rel test cases

2006-05-30 Thread Robert Sayre


On 5/30/06, James Holderness [EMAIL PROTECTED] wrote:


of Use IRI:Compare, Use String::Compare, or The spec doesn't say, so
you may use whatever you prefer.


The URI/IRI specs say use whatever you prefer. If you don't like
that, have James add it to his revision of 4287. :)



--

Robert Sayre

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



Fwd: Link rel test cases

2006-05-30 Thread Robert Sayre


I think James forgot to cc the list

-- Forwarded message --
From: James M Snell [EMAIL PROTECTED]
Date: May 30, 2006 9:38 PM
Subject: Re: Link rel test cases
To: Robert Sayre [EMAIL PROTECTED]




Robert Sayre wrote:

[snip]...have James add it to his revision of 4287. :)




Pardon, what the hell are you talking about?  Do you really, honestly
believe that being a complete ass is a productive use of anyone's time?

- James


--

Robert Sayre

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



Re: Link rel test cases

2006-05-26 Thread Robert Sayre


On 5/26/06, James Holderness [EMAIL PROTECTED] wrote:


Logically I would assume the simple string comparison in section 5.3.1 of
RFC3987, but I was hoping this would be documented somewhere more
explicitly. An atom:id is an IRI too, but it explicitly specifies
character-by-character, case-sensitive comparisons. By not doing the same
for link relations the spec kind of leaves things open to interpretation.


RFC3986, section 6 and RFC3987, section 5 document this procedure very
well. The comparison ladder reduces false negatives in exchange for
processing effort. If you think the ladder is worth climbing in this
case, go for it.

--

Robert Sayre

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



Re: Link rel test cases

2006-05-26 Thread Robert Sayre


On 5/26/06, David Powell [EMAIL PROTECTED] wrote:


We probably should have specified the simple string comparison
method; it is more satisfying to call an implementation that publishes
not obviously equivalent IRIs 'wrong', rather than just 'somewhat unwise'.


Huh, I personally feel that the comparison ladder is better. Sort of
like, if it comes down to that, we can't help you, even for atom:id.
The WG definitely felt simple string comparison was needed for
atom:id, so we spent *a lot* of time on that text.

I don't feel that effort would pay off here, at all. Especially since
a consumer that matched
HTTP://www.IANA.org:80/assignments/relation/alternate would be in
error. That's ridiculous standards weenie stuff, don't you think?

--

Robert Sayre

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



Re: Atompub WG meeting at the Montreal IETF

2006-05-24 Thread Robert Sayre


On 5/23/06, Paul Hoffman [EMAIL PROTECTED] wrote:


The timing of us having our first WG meeting may seem odd, given the
fact that we completed the Atom format document long ago, and are
making good progress on the publishing protocol.


We are? Pull the trigger, already.



I propose the following agenda, which should fit well into a one-hour slot:



Looks like that will be a very good use of time.

--

Robert Sayre



Re: Fyi, Apache project proposal

2006-05-24 Thread Robert Sayre


On 5/23/06, James M Snell [EMAIL PROTECTED] wrote:


We made a mistake calling our stuff a reference implementation


It's OK. We're used to this kind of thing coming from your direction.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-23 Thread Robert Sayre


On 5/23/06, Tim Bray [EMAIL PROTECTED] wrote:


I would vociferously resist any such claim.


OTOH, there are more than a few products on the market right now that
back up just such a claim. So there's an existence proof, and most of
the APIs I've seen *do* make use simple vs. structured, but you may be
right that the market will change that. In otherwords, there is little
point in continuing this discussion... just like you and I agreed 150+
messages ago...

--

Robert Sayre

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



Re: Informational vs. standards-track for Atom Threading Extensions

2006-05-19 Thread Robert Sayre


On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


I answered your question as fully as I could



Quite true, but I asked James.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-19 Thread Robert Sayre


On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


Am I missing something in the case against the choice of location for
the metadata?


Yes. That location is going to cause interoperability problems in my
implementation, because the draft leaves too much undefined, and in
implementations who won't parse them. I think I've made that extremely
clear. The previous draft addressed my concerns. My current plan is to
implement the threading element, but I'll recommend against accepting
bug reports on the other aspects of the document, since I think it's
an underspecified mess. Kind of silly considering the clear lessons
from earlier efforts, but the threading element is good enough.

--

Robert Sayre

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



Re: Feed Thread in Last Call

2006-05-19 Thread Robert Sayre


On 5/19/06, James M Snell [EMAIL PROTECTED] wrote:


Other than the issue with the Microsoft implementation, which has
already been thoroughly discussed, what other interop problems are you
anticipating?  A clear, non-editorialized, listing of the potential
issues and the rationale for each would be most helpful.


You've received several of those from me. I suggest you read your old
mail, paying close attention to messages that you replied to in under
15 minutes.

I have zero confidence that any technical change or compromise is
possible from you, and I find interacting with you to be a giant time
sink. My new policy will be to explain my problem *once*, and then I
will verify that my concerns (if any) have been addressed at some
later date when there is a revised document available. If my concerns
aren't addressed, I will make a concerted effort to avoid writing or
being responsible for maintaining any relevant functionality.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-18 Thread Robert Sayre
 there are countless such examples.  Some implementations don't
use/preserve the scheme attribute on the category element; some
implementations don't fully support the atom content model (e.g. base64
encoded content); some implementations don't support XML digital
signatures; etc.

Because there is no definition of conformance, even for the core Atom
format, it is perfectly reasonable to expect that existing
implementations may have to change a bit in order to support the
introduction of new extensions, depending on the level of support they
have for the full atom data model as defined by RFC4287.

 Atom implementations with generic support for links and extensions,
 will find that this draft moves the goalposts of what a reasonable
 implementation is expected to handle, and I firmly believe that it
 should be possible for implementations to provide generic support for
 extensions in order to assist their adoption.


RFC4287 sets the goal posts. Extension attributes and elements ARE
allowed on Link.  Whether or not an implementation chooses to support
such extensions is an implementation choice.

[snip]
 None of the folks I know of that have actually
 implemented support for the extension has had any problems with them.

 Does that include any stateful feed APIs, or APP servers that aren't
 based on native XML back-ends?


I am not certain what you mean by stateful feed APIs, but the answer
is yes to the question about non-native XML back-ends.

[snip]

- James





--

Robert Sayre

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



Re: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard

2006-05-18 Thread Robert Sayre


On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


This announcement is for a document that will obsolete RFC3548, which is
referenced by a couple APPS area RFCs:  XMPP (RFC3920) and Atom Syntax
(RFC4287).


Yep, this definitely breaks RFC4287 in the way Joe predicted. Time for
a revision.


 - draft-snell-atompub-author-extensions-00


Oh, this excellent document is affected too. Seems like we have a real
problem here.

--

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))

2006-05-17 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))

2006-05-17 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))

2006-05-17 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 for Atom Threading Extensions

2006-05-17 Thread Robert Sayre


On 5/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


On May 17, 2006, at 10:02 AM, Robert Sayre wrote:

 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?


My question has yet to be answered.



I could still recommend Experimental instead of Standards Track if I
learned of some possible harm to security/privacy or Internet health,
or some deep barrier to interoperability, but I have not yet learned
of a high enough risk+severity of such concerns to change my mind there.


I think this is an excellent standard. If another individual, such as
myself, were to submit an individually authored document, it would
have to meet the same standard, right?



I hope that makes the situation clearer!


Sure does!

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-16 Thread Robert Sayre


On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:


Very simple reasons: the attributes are easier to implement,


Speaking as an actual, rather than alleged, client implementer, I find
this assertion ridiculous and dishonest.


are allowed by RFC4287 and are being used in real deployments.


So, the argument is that it's already deployed, then? It looks like
you agree with me.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-16 Thread Robert Sayre


On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote:

At 4:33 AM +0200 5/16/06, Robert Sayre wrote:
I thought the working group was fairly clear about the dubious value
and placement of these attributes,

For the benefit of Lisa, who is the sponsoring AD for this document,
please list links to those messages.


James changed the document in response to those messages. That should
be enough. Maybe she could ask James about them. It's not my
obligation to spelunk for them, and it's certainly not your place to
start making demands like that.


So you don't think they're important or needed, and then
WG doesn't have consensus on them.

Quite true, but it is true because there has never been a call for
consensus on the document, and there won't be in the future.


Well, I'm not going to quibble with you about procedural details. But
I have to wonder why they're in the document at all.

Looks like the IETF wants to publish a proposed standard explicitly
designed to break a very popular implementation, with no technical
reason. I think that speaks volumes about the IETF, its management,
and the quality of its individual contributors.


You don't have to listen to the WG, but if one or two WG members are
going to deploy and then standardize whatever they've done, that's an
informational document.


That is not true. If it is a protocol or a format, standards track is
also appropriate.


Well, I don't want to standardize some of what James has deployed. It
won't work in Sean's implementation. I'm not sure I can interoperably
implement the parts in question. Your two biggest client implementers
aren't real happy about this. It might be appropriate if you really
stretch, but it's sure not smart.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-16 Thread Robert Sayre


On 5/17/06, James M Snell [EMAIL PROTECTED] wrote:


What's broken?


Do you think the AD and this WG are dumb? Why are you setting up such
an obvious strawman?

Congratulations, your extension didn't break Atom. The point is that
your extension is broken. You're including attributes in that document
that you know won't be visible to a large number of implementations.
You have no technical reason that makes that location compelling, and
several WG members have questioned whether this document adequately
covers the area in question. In fact, you appear unable to explain the
rationale behind any technical decision without resorting to circular
reasoning, logical fallacies, and claims that are outright false.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-16 Thread Robert Sayre


On 5/17/06, A. Pagaltzis [EMAIL PROTECTED] wrote:



I have to disagree that there is no technical reason.

There is no way to sanely associate additional information with a
link element.


Sure there is, and it's the way James did it. Is the information
valuable? Does the spec cover cardinality issues? Is the link element
useful here? Was the spec less effective in its previous incarnation?
The answer to all of these questions is no.

--

Robert Sayre

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



Re: Feed Thread in Last Call

2006-05-16 Thread Robert Sayre


On 5/17/06, Lisa Dusseault [EMAIL PROTECTED] wrote:


  - We're talking about visibility to implementations of the base
spec only, not implementations of the extension, naturally.  Any new
information can be visible to implementations of that extension.


There's a misunderstanding here. Many applications rely on a feed
parsing service provided by the OS or a language-level library. Some
of those platforms (MS is not the only one) don't provide access to
extension attributes on the link element. For example,

entry
...
foo:bar /
link foo:bar=baz ... /
/entry

here the extension attribute stands a chance of getting lost. The
reason this occurs is because it's much easier to design an API that
doesn't deal with these things in the general case. This situation
could change in the future, as Atom consumer APIs develop.

My implementation will parse and preserve the attribute, but I'm not
sure what I'm supposed to do with it at an application level,
especially if I encounter more than one such link element.

As a result, I see no reason to introduce gratuitous compatibility
problems when the cardinality of the link element doesn't seem to suit
the problem very well.


  - We're talking about adding machine-parsable data that would be
invisible to readers of the post content


I don't know. The specification says nothing about that. Presumably,
the implementers that have already deployed know what they are for.

--

Robert Sayre



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

2006-05-16 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.



Re: Feed Thread in Last Call

2006-05-15 Thread Robert Sayre


On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:


At this point, Feed Thread support has been deployed in Friendster,
Typepad, and MovableType.


I thought the working group was fairly clear about the dubious value
and placement of these attributes, and you yourself posted that no one
was implementing them, they were strictly informational, and free to
be ignored. So you don't think they're important or needed, and then
WG doesn't have consensus on them. Even Tim's comments were in the
abstract, and not related to feed thread at all.

You don't have to listen to the WG, but if one or two WG members are
going to deploy and then standardize whatever they've done, that's an
informational document.


From a technical perspective, the interactions between multiple links

with the extension attributes remain unspecified. As a client
implementor, I suppose I'll find out what exactly they're for whenever
I see the already-completed implementations deployed. In my opinion,
the document should do more to inform the community on the role of
these attributes.


now is the time to step up and make your case.


You've merely stated you believe that moving these attributes back
to the original location is the right decision. That is not a
technical rationale. I would expect to see a more compelling reason,
given the clear, technical rationales of those against your decision.

On an unrelated note, this document contains sections copied verbatim
from RFC 4287, and it would be polite and honest to acknowledge that.

--

Robert Sayre



Re: Feed Thread in Last Call

2006-05-15 Thread Robert Sayre


On 5/16/06, James M Snell [EMAIL PROTECTED] wrote:


A few of the individuals on the WG had a problem with the placement of
the attributes due to various limitations of a few existing Atom 1.0
implementations.


Right, and you're breaking them because...? You haven't coherently
explained your reason for moving them back. After all, you agreed with
the WG and updated the document, but now you've moved them back for
unexplained reasons and pointed at deployments.


None of the folks I know of that have actually
implemented support for the extension has had any problems with them.


I find your answers most unsatisfying and full of circular reasoning
that serves mostly to dance around the fact that you and a few others
have already deployed. That's been your argument for months now, and
the IETF process has a way to deal with that situation: Informational.

--

Robert Sayre



Weekly Posting Summary

2006-05-10 Thread Robert Sayre


   Messages   |  Bytes| Who
+--++--+
19.44% |7 | 41.09% |   100373 | [EMAIL PROTECTED]
11.11% |4 | 12.86% |31414 | [EMAIL PROTECTED]
11.11% |4 |  9.60% |23444 | [EMAIL PROTECTED]
13.89% |5 |  6.06% |14807 | [EMAIL PROTECTED]
11.11% |4 |  4.91% |12001 | [EMAIL PROTECTED]
 8.33% |3 |  4.44% |10857 | [EMAIL PROTECTED]
 2.78% |1 |  7.25% |17717 | [EMAIL PROTECTED]
 5.56% |2 |  4.21% |10293 | [EMAIL PROTECTED]
 5.56% |2 |  3.97% | 9707 | [EMAIL PROTECTED]
 2.78% |1 |  1.59% | 3895 | [EMAIL PROTECTED]
 2.78% |1 |  1.59% | 3876 | [EMAIL PROTECTED]
 2.78% |1 |  1.24% | 3041 | [EMAIL PROTECTED]
 2.78% |1 |  1.17% | 2869 | [EMAIL PROTECTED]
+--++--+
100.00% |   36 |100.00% |   244294 | Total


--

Robert Sayre

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



Re: Atom Rank Extensions

2006-05-05 Thread Robert Sayre


On 5/5/06, Andreas Sewe [EMAIL PROTECTED] wrote:


You mean r:rank, right? Well, the purpose of r:scheme (and its child
elements) is to describe the ordered set from which r:rank's values a
picked. Think of it as a datatype definition geared specifically at
describing those sets of numbers commonly encountered in grading schemes.


Why don't you call it that in the draft?


 This conflicts with the atom:author field. Why not @id, @domain, etc.

Well, I am not sure what you mean here, but as for @domain you have to
realize that a single scheme can be used to rank entries within more
than one Ranking Domain (e.g.., within several feeds).

Changing @name to @id might cause confusion, since attributes called
id commonly contain NCNames, not IRIs. I suggest to James using an
r:id child element of r:scheme, instead, to mimic atom:id, but somehow
he doesn't like the idea. But maybe you can come up with a better name
for @name (no pun intended).


Ranking Domain. I'm still not sure what that means.



 An Atom feed element MAY contain any number of r:scheme elements.
 A feed MUST NOT contain more than one r:scheme element with the
 same name.

 Well, you have all of these child elements that can change the effect
 of the element, so why would you want to ban this behavior?

I don't understand the above. :-( Can you please clarify your objection.
Thanks.


I don't see the interoperation problem the MUST NOT is preventing.


--

Robert Sayre

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



What Atom software are you working on?

2006-05-05 Thread Robert Sayre


I've been working to add Atom support to Firefox 2. Some other Firefox
devs are toying with exposing internal data like history and bookmarks
as Atom feeds.

What software are you writing?

--

Robert Sayre

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



Re: Feed thread update

2006-05-04 Thread Robert Sayre


On 5/4/06, Tim Bray [EMAIL PROTECTED] wrote:


This assertion that atom:link is not extensible is simply, flatly,
completely, wrong.


I agree that it's not an especially convincing or interesting
argument, given that 6.4 starts with

Atom allows foreign markup anywhere in an Atom document

We certainly don't want consumers to barf on foreign markup anywhere,
so it has to be allowed everywhere. Of course, you'd be foolish to put
extension attributes on things like atom:updated, and lots of other
places, because then you're going to force people to dive into the
feedparser/feedtools/gdata/etc implementation layer. Secondly, we
might not like it for strange pseudo-nationalistic reasons, but some
implementers find it convenient to transcode Atom to RSS2. when you're
doing that, it's more difficult to preserve markup in areas left
undefined by the specification. If you want to make a point, and carp
on how crappy those applications are, you'll look for an excuse to do
it. In reality, those extension points haven't proven that interesting
or necessary, and the current thread is a particularly forceful
example of that reality for those of who aren't participating. So, it
really is that most common of syndication archetypes: the tempest in a
teacup.

--

Robert Sayre



Re: Atom Rank Extensions

2006-05-03 Thread Robert Sayre


On 5/3/06, Paul Hoffman [EMAIL PROTECTED] wrote:


Works for me.



http://www.alvestrand.no/pipermail/problem-statement/2003-March/000951.html
--

Robert Sayre



Re: Atom Rank Extensions

2006-05-03 Thread Robert Sayre
 of that specification.

Appendix A.  Acknowledgements

   The authors gratefully acknowledge the feedback from the Atom
   Publishing working group during the development of this
   specification.


You should also acknowledge verbatim copies of text from RFC4287.



--

Robert Sayre

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



Re: Atom Rank Extensions

2006-05-02 Thread Robert Sayre


On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


Such as?


Not appropriate for on-list discussion, sorry.


  When I read terms like more standard wrt the feed thread
  extension, it makes me cringe.
 
 There are obvious reasons why that one is better than the rag-tag
 group of RSS extensions...

 Disagree. There is no proof of that.

There is proof that the existing patchwork of RSS extensions is
insufficient. That is enough to convince me that an extension
which addresses their holes is useful.

If addressing holes in existing standards was unnecessary, then
RSS is good enough and the Atom was a giant waste of time.



I don't I follow your reasoning. We have namespaces so vendors can
create whatever they might like, without involving the standards
organization. I fail to see the point in rubber-stamping such things.



You mean there should be a formal agreed-on statement of what an
I-D is supposed to achieve before the process starts? If that is
what you mean: yes, that is definitely a fine idea.


And WG chairs, etc, etc.

--

Robert Sayre



Re: Atom Rank Extensions

2006-05-02 Thread Robert Sayre


On 5/2/06, James M Snell [EMAIL PROTECTED] wrote:


Aristotle, I appreciate the intention, but please don't bother. It is
painfully clear that Robert has no intention of adding anything of any
real value to the discussion.



???

--

Robert Sayre



Re: Atom Rank Extensions

2006-05-02 Thread Robert Sayre


On 5/2/06, A. Pagaltzis [EMAIL PROTECTED] wrote:


* James M Snell [EMAIL PROTECTED] [2006-05-02 19:45]:
 A. Pagaltzis wrote:
  Such as?

 Aristotle, I appreciate the intention, but please don't bother.
 It is painfully clear that Robert has no intention of adding
 anything of any real value to the discussion.

I know. However, I despise politics and old boys clubs and prefer
the merit of my decisions to be self-evident, so I'm avoiding any
assumption of any axe to grind behind his behaviour, to see what
should be addressed and how. If there is any meritorious concern
in his objections, I'd like it addressed, regardless (despite?)
of who brought them up and how.



I've been saying the same thing for weeks. I suppose it's par for the
course to handwave about them being strictly advisory, supply
circular definitions for the feature in the first place, claim no one
will be implementing the feature, then claim that someone is, etc,
etc. You know, stuffing an idea because of who proposed it. You can go
read the atom-protocol archives if you want more evidence of that.

The general pattern seems to be to sanctimoniously scold me for making
the suggestion, and then to adopt it with cosmetic changes.

--

Robert Sayre

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



  1   2   3   4   5   6   >