Fwd: Atom format interpretation question

[Tim Bray]

Begin forwarded message:


From: John Cowan <[EMAIL PROTECTED]>
Date: January 4, 2007 8:08:06 AM PST (CA)
To: [EMAIL PROTECTED]
Subject: Atom format interpretation question

Am I right in thinking that content which is in fact in XML but
is labeled with a media type that is neither generic XML nor
ends in "+xml" cannot be included inline in an Atom entry?
The NewsML community (which uses the registered media-type
text/vnd.IPTC.NewsML) is concerned about this.

--  
John Cowan  [EMAIL PROTECTED]  http://ccil.org/~cowan

Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of  
Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are  
unknown)

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Tim Bray]

On Dec 15, 2006, at 5:00 PM, Lisa Dusseault wrote:

I guess I'm assuming that one would want clients to be able to  
extend Atom unilaterally.


That doesn't seem to have been a design goal for the WG.  To the  
extent that the issue never came up in the discussion.


The choices that I highlighted as problematic make it harder for  
clients to reliably add extensions to Atom documents.


You're being tactful with "harder".  I'd say "impossible".

Here's my take on the WG thinking:  The set of software  
implementations which could reasonably act as APP servers is  
incredibly large and heterogeneous.  A lot of them already exist.   
The requirement that they reliably round-trip arbitrary XML from  
clients is actually pretty onerous, since many (all?) of them will  
have internal data-storage models which will look very little like  
the Atom XML representation.


We think that APP as specified allows very good interoperability for  
basic Web-centric publish/edit operations with low overhead, and low  
demands for complexity in the client and sever implementations.
Adding the requirement for client-side extensibility would reduce the  
number of server implementations that would be able to advertise  
conformance with APP, even though they are perfectly capable of the  
highly-useful function possible under APP as of the current draft.


(It remains easy for servers to add extensions to Atom feeds and  
entries using prescribed mechanisms like adding new elements in  
custom namespaces.  )


Right.  Phrased another way, the APP is highly extensible; but the  
current version requires co-operation from both client and server.   
This seems reasonable to me.


It may be that I'm just having trouble accepting that the WG fully  
understands this and has still come to consensus that this is a  
great way to proceed.  Is that the case?


Sort of.  Frankly, there seems to have been very little hunger for  
unilateral client-side extension, and a very strong aversion from the  
server-side people to accepting the round-trip-any-XML requirement.


  -Tim

Re: AD Evaluation of draft-ietf-atompub-protocol-11

[Tim Bray]

Lisa Dusseault wrote:

>>> Can a client modify an entry to contain a link relation element in the
>>> following cases:
>>>
>>>  - To point to a resource on a different server entirely?
>>
>> There is no reason to believe that any of these resource are on
>> the same machine to begin with. I could POST to media to machine A
>> and have the MLE could be created on machine B and the editable media
>> resource itself created on machine C.
>
> This requirement has to be stated explicitly, at least as a SHOULD.

Hmm.  One particular operation in the APP is defined as creating two 
resources; we specify how this is requested and the mechanism by which 
the server communicates the URIs that identify the newly-created 
resources.  It would feel really weird to me to specify anything about 
what servers the resources might be on.  That's not how URIs work or how 
the Web works.  You can't tell by looking at a URI what server the 
resource is on, anyhow.  The URI might not be an HTTP URI. Two URIs that 
look very much the same might reference data on different continents. 
That's the whole point of how URIs work.


Having said that, Lisa has already pointed out shortcomings in the 
number and placement of examples concerning this particular case.  I 
think it'd be a good idea to have the example showing the Media resource 
showing up at http://media.example.com and the MLE showing up at 
http://app.example.com.


But I'd be very much against side-tripping the protocol definition into 
any discussion of "servers".


>>> Can a server ever ignore part of an edit and successfully process 
the rest?

>>>
>>
>> Yes. Think of a client that throws in a slew of random link elements 
with

>> relations my server implementation doesn't understand. Same with foreign
>> markup. The server is in charge.
>
> I completely disagree with this.  It is way too unpredictable for 
clients to deal with.


Well, except there are several examples of APP clients that seem to do 
just fine.


Example: After extensive discussion, the WG achieved consensus that APP 
servers are *not* required to retain foreign markup.


Example: It is perfectly possible to imagine a server that morphs or 
prunes incoming entries for reasons of political censorship, security 
policies, markup standards, spelling-correction, automatic translation, 
or lots of other things we can't possibly imagine.


Example: my Ape protocol exerciser posts entries with a separate 
 and  fields.  At least one of the servers I've tested 
against accepts posts but discards my summary and generates its own, 
algorithmically.


The range of things a server can usefully choose to do currently exceeds 
our ability to specify or constrain.  Fortunately, in HTTP, we have a 
protocol the semantics of whose state-changing verbs PUT and POST are 
remarkably well-matched for these interactions whereby a client says 
"please take this and publish it and tell me what you did" and the 
server says "OK, here's what I made of it."


The current WG consensus, way better than "rough", is that this level of 
interoperation is useful.  That consensus seems to be supported by 
implementation experience.


Lisa, perhaps the problem is that I'm reacting to a fairly general 
statement of concern.  Do you have some specific suggestions as to how 
server behavior could be limited or formally described?


 -Tim

Re: Atom Entry docs

[Tim Bray]

Bob Wyman wrote:
There is, I think, a compromise position here which will avoid breaking 
those existing implementations which follow the existing RFC's.


In case you haven't noticed, the WG is hopelessly split 
between the new-media-type option and the media-type-parameter option. 
If a few people were to put up their hands and say "yeah what Bob said" 
your co-chairs would probably do a hasty consensus grab.


 -Tim



1) Define ;type=feed and ;type=entry as optional parameters. (i.e. get 
them defined, registered, and "ready to use.")

2) Leave RFC4287 unchanged. i.e. do NOT re-define "application/atom-xml"
3) New specifications MAY require that ;type=entry be used. (Note: Just 
because ;type=entry is used DOES NOT imply that ;type=feed must also be 
used)


Thus, APP would accept application/atom+xml when looking for a feed but 
might insist that entries be explicitly identified with a disambiguating 
type parameter. Thus, no code which currently uses 
"application/atom+xml" to designate a feed would be broken. 
Additionally, any code which is "properly" built and thus ignores 
unknown types will not be hurt when it sees 
"application/atom+xml;type=entry" since it will ignore the type 
parameter and dig around inside the data to figure out if it is feed or 
entry. The only code which will be hurt is some potential code that does 
not follow the existing RFCs for Atom or mime types. It is, I think, OK 
to occasionally break code that doesn't follow the specs.


Whatever the technical arguments may be, I believe it is important from 
a "political" point of view that we do not change the definition of 
things defined in Atom. I am all for extending Atom, but not for 
changing Atom. We must not change the exiting specification unless there 
is some really serious harm being done. If we do, we risk losing the 
trust of at least some members of the community that we've built these 
last few years... Folk will remember that one of the "advantages" that 
is claimed for RSS is that it has been declared to be eternally free 
from modification. While I personally believe that that is silly, the 
proponents of RSS do have a point when they speak of the value of stable 
specs. If we allow the Atom spec to be *changed* so soon after it was 
accepted and we don't have a really, really good reason for doing it, we 
will simply have proven the often made claim that standards groups 
simply can't be trusted with important specifications. We will be 
encouraging more of the kind of "standards making" that resulted in the 
mess that is RSS...


bob wyman

PS: Since Kyle points out that GData, a Google product, is potentially 
impacted by the results of this discussion, I should state that I 
currently work for Google -- although I am not currently assigned to any 
product or project that has a direct interest in the definition of Atom, 
APP, etc... My participation in this discussion, at this time, is driven 
purely by personal interest.

Atom Entry docs

[Tim Bray]

I seems obvious to me that Atom Feed and Entry docs are potentially 
quite different things which can be used for entirely different 
purposes.  The contention that an Entry doc is somehow really the same 
as a one-entry Feed doc is entirely unconvincing.


The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG 
finding on Authoritative Metadata 
(http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear 
that it's advantageous to use HTTP headers to distinguish between 
different kinds of representations.


So I guess I'm in favor of us writing something down to address this 
problem.


RFC4287 is now pretty widely implemented, so there is a distinct cost to 
screwing around with the well-known application/atom+xml.  On the other 
hand, my perception is that virtually all software that knows about 4287 
knows about feeds, rather than entries.  Thus, it seems to me that 
introducing a parameter so that existing software might see 
application/atom+xml;type=feed *might* break some software.  But 
introducing a new media-type application/atom-entry+xml which only goes 
with standalone feed documents is very unlikely to break anything.


So I'm for James' option B)
 application/atom-entry+xml

(James, did you really mean "atom.entry" with the ugly dot?)

 -Tim

Re: Atom Entry Documents

[Tim Bray]

Mark Baker wrote:


Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.


Erm, isn't it up to the chairs to declare concensus?


I agree that there exists sentiment in favor of there 
being a way to distinguish between Feed and Entry documents.  I think 
the notion of consensus is only meaningful in the context of actual spec 
language, so it seems to me that it would be helpful to have some 
proposed language to look at.  So I see no downside in James doing an 
I-D.


 -Tim

Re: Atom namespace really not ending with / or # ?

[Tim Bray]

Anne van Kesteren wrote:
Jan Algermissen 
<[EMAIL PROTECTED]> wrote:
is it really true that the Atom namespace is 
http://www.w3.org/2005/Atom ?


It wasn't really relevant, I'd say. (That it says "Atom" and not "atom" 
was a mistake.)


I'd agree.  Sigh.  But not a big one, I think -Tim

Re: PaceEntryMediatype

[Tim Bray]

On Nov 29, 2006, at 8:16 AM, James M Snell wrote:


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

#pragma section-numbers off

== Abstract ==

For the current Atom Publishing Protocol draft...


Irrespective of the merits of the new media type, the APP spec seems  
like the wrong place to define it.  Since nobody wants to obsolete  
4287, why not a short clean standalone I-D?  -Tim

Re: PaceAutoDiscoveryDraftIsPointless (was: PaceMakeAutodiscoveryInformational)

[Tim Bray]

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*!!!".  It's foolish to draw conclusions about any HTML- 
related spec based either on which group is originating it or what  
anyone claims the browser engineers are going to do.


 -Tim

Re: Author element best practice

[Tim Bray]

On Nov 22, 2006, at 3:11 AM, Sylvain Hellegouarch wrote:


Say I POST an atom:entry to a collection URI, this entry does not have
an atom:author


If I were implementing the server, in this scenario I'd reject the  
post with an error message.  It's hard for me to see a scenario where  
the author info isn't already known and not providing it is still  
OK.  (In fact, it's hard for me to imagine a scenario in which the  
author info isn't already known, period.)  -Tim



(which could be considered as not valid but that's not
the question here), now say that my app server does not have any
information as to what value to set when adding the atom:author  
element
to the member, do you think it'd be better to put an empty  
atom:name or

to put a dummy value such as 'anonymous' or 'n/a'?

I'm asking because I try to make sure that whatever the input is the
member I create are respectful of section 4.1.2 of RFC 4287 and I  
can't
decide which way to go when some information are missing from the  
context.


Any best practices from you guys?

Thanks,
- Sylvain

URGENT: Remove atom:updated ordering requirement?

[Tim Bray]

Please see the dialogue below.


(Eric's point seems plausible to me; personally I'd be inclined to a  
+1.)



Can we have some feedback from the WG ASAP?  We want to take  
protocol-11 to the IETF.



  -Tim

On Sep 26, 2006, at 4:59 PM, Eric Scheid wrote:



On 27/9/06 8:15 AM, "Tim Bray" <[EMAIL PROTECTED]> wrote:


PaceAppEdited: Lots of discussion.  There seems universal support for
the utility of an app:edited element, and an assertion that entry
members SHOULD contain one.  On the other hand, every discussion of
sort order has spiraled instantly into a rat-hole.

Conclusion.  PaceAppEdited is accepted, in part. The second part of
the proposal, defining the app:edited element, is ACCEPTED.  The
first part, imposing a requirement on the sort order of collections,
clearly does not have consensus support.


There also seems to be universal support for the notion that  
collection
feeds could be sorted by something other than what's currently in  
the spec.

The spec currently not only says collections are to be sorted by
atom:updated, but because of the MUST it also says it MUST NOT be  
sorted by

anything *else*, which is a problem.

Section 10.0 ¶ 2 says this:

The entries in the returned Atom Feed MUST be ordered by their
   "atom:updated" property, with the most recently updated entries
coming first in the document order. Clients SHOULD be constructed
in consideration of the fact that changes which do not alter the
atom:updated value of an entry will not affect the position of
the entry in a Collection.

We need to either strike that entire paragraph, or at the very  
least make

that MUST into a SHOULD.

I say +1 to s/MUST/SHOULD/

e.

Re: WG Last Call for draft-ietf-atompub-protocol

[Tim Bray]

On Sep 26, 2006, at 12:34 PM, Sam Ruby wrote:

Here's a list of Paces that weren't disposed of with the last  
consensus call:


First of all, did Sam get them all?  Please speak up soonest about  
anything that was missed and might have a realistic chance.




PaceAppEdited: Lots of discussion.  There seems universal support for  
the utility of an app:edited element, and an assertion that entry  
members SHOULD contain one.  On the other hand, every discussion of  
sort order has spiraled instantly into a rat-hole.


Conclusion.  PaceAppEdited is accepted, in part. The second part of  
the proposal, defining the app:edited element, is ACCEPTED.  The  
first part, imposing a requirement on the sort order of collections,  
clearly does not have consensus support.


 
=


PaceAppEdited2: Not enough support, some opposition, big and  
complicated.  REJECTED.


 
=


PaceAppModified3: Lots of discussion, no real consensus, eventually  
replaced by PaceAppEdited.  REJECTED.


 
=


PaceAppVersion: Got no +1s, some opposition: REJECTED.

 
=


PaceCollectionLinkType: zero discussion: REJECTED.

 
=


PaceFixModel: 2 supporters, not enough: REJECTED.
But note that this is inconsistent with some of the language in  
section 9, so editorial work is required.


 
=


PaceLocationPointsToEntry: zero discussion: REJECTED.

 
=


PaceOrderCollectionsByAppModified2: zero discussion: REJECTED.

 
=


PaceRemoveConnegSuggestionOnServiceDoc: almost no discussion: REJECTED.

 
=


PaceRemoveOutOfLineCategoriesFromCategoryDocument: 2 supporters,  
little discussion, not enough.  REJECTED.


 
=


PaceRevertTitle: Lots of -1's: REJECTED.

 
=


PaceSecurityConsiderationsRevised: We need something in the Security  
Considerations section of the document, and there was at least some  
support for the ideas in this section in the past. The other proposal  
for words for this section was withdrawn. Therefore, this Pace is  
ACCEPTED with the understanding that the issue of what our security  
considerations are is not closed and may be modified after the IETF  
last call.


 
=


PaceServiceLinkType: Not enough discussion/support: REJECTED.

 
=


UseElementsForAppCollectionTitles3: Seems to have been incorporated  
in the draft.

Re: I-D ACTION:draft-ietf-atompub-protocol-10.txt

[Tim Bray]

On Sep 12, 2006, at 1:23 PM, Joe Gregorio wrote:



FYI


And of course there's an HTML version at http://bitworking.org/ 
projects/atom/


  -Tim

Re: versioning extension?

[Tim Bray]

On Sep 11, 2006, at 4:39 PM, Jan Algermissen wrote:

If I am not completely wrong, versioning is definitely an issue if  
you want to employ Atom in beyond-blogging contexts. Most people  
that deal with collections of items are definitely interested in  
keeping track of the former versions of the items.


Versioning is an issue in almost *every* application.


What is so bad about it?


In my experience, the semantics of "versioning" are so tightly bound  
to particular applications that it's really hard to find common  
threads.  You saw that happen here when we were arguing about  
atom:updated, Asbjørn had a particular vision of versions that seemed  
obvious to him and unreasonable to others.  When a textbook publisher  
and a medical-instrument embedded-software maker and a wiki  
implementor use the word "version", I guarantee you they mean  
entirely different and wildly incompatible things.


Good luck; you'll need it. -Tim

Re: versioning extension?

[Tim Bray]

On Sep 11, 2006, at 3:40 PM, Jan Algermissen wrote:

is anybody working on (or planning to work on) a versioning  
extension for Atom? I am about to use Atom in two (considerably  
different) projects that require versioning and would be happy to  
join forces and contribute real (enterprise-)world use cases.  
(Note: not 'enterprisey' use cases :-)


Eeek!  Flee for your lives!  *runs for the  
nearest exit*  -Tim

Re: Private extensions and relation to atom elements

[Tim Bray]

On Sep 11, 2006, at 7:45 AM, James Aylett wrote:


Feed Validator gets upset with extension attributes - is it wrong?


Be specific, please?  -Tim

Re: Private extensions and relation to atom elements

[Tim Bray]

On Sep 11, 2006, at 4:27 AM, James Aylett wrote:



We've run across a situation where we want to annotate an atom:icon
with a title. Currently we're doing the following, as something that
Feed Validator is happy with, but doesn't feel right:

--
  uri:to/icon
  My icon
title


let's assume myns: is declared.  Then why not

icon-uri

 -Tim

Re: atom:updated - not now() values?

[Tim Bray]

Eric Scheid wrote:

When updating an entry, is it acceptable to insert a value other than Now()
into atom:updated?


Clearly, since updated is defined as the time the publisher thinks it 
was significantly updated.  Of course, the server could over-write the 
updated value if it chose. -Tim




For example: Corporate Communications prep a release and they stamp it with
a release date of Monday 4 PM ... but I don't see this release update until
I get into the office at 2 PM Tuesday, and thus I quickly enter it into the
CMS and set the atom:updated value to Monday 4 PM.

e.

Re: Link rel test cases

[Tim Bray]

On May 30, 2006, at 5:25 PM, James Holderness wrote:

I agree completely, but as a content consumer I still need to know  
whether to use IRI::Compare or String::Compare when I do encounter  
some ridiculous feed that uses example (a). I'm hoping for a simple  
answer along the lines of "Use IRI:Compare", "Use String::Compare",  
or "The spec doesn't say, so you may use whatever you prefer".


Both are perfectly legal.  IRI::Compare will avoid some false  
negatives at the cost of burning some CPU cycles.  Postel's law would  
suggest using IRI::Compare initially, but if a profiler revealed it  
to be a performance bottleneck, I'd nuke it in favor of strcmp()  
without a second's hesitation.  I actually wouldn't be surprised if  
that happened; case-insensitivity and Unicode sit poorly together and  
are a notorious source of performance sinkholes. -Tim

Re: Feed Thread in Last Call

[Tim Bray]

On May 20, 2006, at 8:49 AM, David Powell wrote: (at great length)

I'm going to re-organize David's argument a little and deal with one  
of his last points first.



Foreign attributes are bad, and are inherently less interoperable
than Extension Elements.


I would say that furious debates about elements-vs-attributes have  
been going on since the dawn of XML in 1998, but that would be  
untrue; they've been going on since the dawn of XML's precursor SGML  
in 1986.  They have never led anywhere.  After you've noticed that if  
you need nested element structure you're stuck with elements, and if  
you don't want to have two things with the same names attributes can  
help, there really aren't any deterministic decision procedures.


I note with pleasure that *all* known XML APIs allow you to retrieve  
elements and attributes with about the same degree of difficulty.


So, my conclusion: I disagree with Powell.  Let people put extensions  
wherever they feel like putting them (they will anyhow), remembering  
that human-readability is a virtue.  If models try to micro-manage  
the element/attribute thing, those models are broken, don't use  
them.  If software arbitrarily discards markup because the markup  
doesn't match its idiosyncratic ideas about elements and attributes,  
that software is non-comformant and non-interoperable.



Software that deals with XML such as an XHTML document, doesn't have
much choice but to model the document using generic XML concepts and
tools - Infosets, DOM, SAX, strings containing XML tags, etc.

For Atom though, it is useful to model feeds and entries in terms of
some other data model: OO, RDBMS, WebDAV (I've been doing it as RDF,
but that is a dirty word around these parts).


Well yes, but each and every one of those non-XML models fails to  
capture the information content of perfectly-legal XML in one way or  
another.  The Atom data format *could* have been designed in such a  
way as to be conformant with one or more of those models, but it  
wasn't.  Extensions to Atom can be designed in such a way as to fit  
into some particular data model, or not.


So I think it's really questionable to try to normatively reverse  
engineer the WG consensus to try to pretend that Atom documents can  
usefully be processed as anything but XML.



Section 6 of RFC4287 is flawed. It is an ugly mix


I agree.  In fact, what Simple Extension *really* says is "this  
property can trivially be modeled in RDF" and Structured Extension  
really says is "doesn't directly map to RDF", but I failed to  
convince the WG either to remove this hand-waving or to be clear  
about what we really meant.  Having said that, these notions  
fortunately have exactly zero normative effect on implementors.



of my (overly)
strict PaceExtensionConstruct proposal[1], and an (overly) liberal
philosophy that the existence of foreign markup anywhere won't break
implementations, so shouldn't be disallowed.


I have no comment on your proposal, but the philosophy you describe  
does in fact represent the consensus of the WG and the IETF  
community; your opinion that it is overly liberal is interesting but  
not particularly relevant to implementors.



atompub's charter states:


Atom consists of:
* A conceptual model of a resource
* A concrete syntax for this model


Extension elements are defined to have both a model and a syntax, but
Atom's allowance for foreign attributes to appear anywhere is a case
of syntax that has no corresponding model. Atom doesn't really explain
what foreign attributes are intended for.


Extension elements also, as noted above, have *no normative effect*.   
It is arguable that the design of Atom departed from the charter in  
that the model was never explicitly specified.  To me, this seems  
like sound design; the success of the Web has been based on careful  
specification of the content and sequence of the interchanged  
messages without any attempt to standardize on a model.  This is A  
Good Thing, and demonstrably works.


And Atom also doesn't really explain what foreign elements are  
intended for either.



It seems like they could be
an extension point, but given that many implementations will have an
application model that isn't based on the XML Infoset (as described
above),


There's a word for implementations (especially intermediaries, as you  
notice) that aren't based on the Infoset: broken.  Because RFC4287 is  
explicitly defined only in terms of the infoset.  Go ahead and try to  
impose any models that are appropriate for your application needs; I  
do this all the time.  But don't change the Infoset.



it seems very unwise to create an extension proposal which
depends on the precise syntax of an element being preserved.


The "precise syntax" claim is utterly bogus.  RFC4287 properly  
standardizes at the Infoset level, thus it makes zero difference  
whether I say Café or Café.  I  
personally think that an extension proposal should


(a)

Re: Fyi, Apache project proposal

[Tim Bray]

On May 23, 2006, at 8:35 AM, James M Snell wrote:


The goal is to have a reference implementation that is also usable.
However, I do have to be careful here, the IETF doesn't really do
reference implemenations so the naming of this project is a bit wrong.
We really shouldn't be calling it a "reference implementation"  
although

that is the kind of thing we're wanting this to be.


Yes, I think it's a good idea for Apache to include tools for  
processing Atom data and implementing the Atom protocol.  The only  
reason I can imagine for doing this is so that people could use it  
and thus avoid re-inventing the Atomic wheel.  Apache does not have,  
and would not claim to have, the standing to do a "reference" in the  
sense of having any normative force.  So yes, I think the term  
"reference" is probably misleading enough to constitute a problem.   
Why not just call it something breathtakingly original like Apache  
Atom Library or some such? -Tim

Re: Feed Thread in Last Call

[Tim Bray]

On May 18, 2006, at 6:15 AM, David Powell wrote:


What I see as a problem is that reasonable implementations will not
preserve Atom documents bit-for-bit, so they will need to explicitly
support this draft if they don't want to corrupt data by dropping the
thr:count attributes. By the letter of RFC4287 there is no problem
with the draft, but practically there is something like a layering
concern if an extension requires existing conformant implementations
to be changed.


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 notice that you said "implemented support" - that is fine for
user-agents etc, but I don't believe that Atom infrastructure should
be required to "implement support" for each new bit of content that
publishers put into their feeds.


On the contrary; I think that implementors who fail to deal with the  
fact that people will be adding their own non-Atom stuff at every  
conceivable place in an Atom feed are being very stupid, because this  
will happen whatever we say. -Tim

Re: Feed Thread in Last Call

[Tim Bray]

On May 17, 2006, at 12:46 PM, Byrne Reese wrote:


Speaking up:

http://www.majordojo.com/atom/ 
standardizing_the_atom_thread_extension.ph

p

No surprise I guess, but I am a huge +1. Lock this spec down and ship
it.


Me too.  Does something useful, does no harm, if it's broken in some  
way it'll be harmlessly routed around.  I suspect that  
implementations that are stupid about the contents of   
will be fixed pretty soon. -Tim

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 7:10 PM, James M Snell wrote:


At issue is whether or not authors of standardized
extensions should extend elements with undefinedContent when we know
full well that there are API implementations out there that have made
the extremely shortsighted decision to completely ignore such content.


Give me a break, we're in the first *days* of something that will be  
used for at least decades.  Todays' APIs will have a vanishingly- 
small lifespan in comparison; crippling our expressiveness in  
deference to them is, frankly, silly. -Tim

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 5:08 PM, A. Pagaltzis wrote:


The assertion is not that atom:link may not have child elements
or namespaced attributes. The assertion is that the list of
locations for Metadata elements in Section 6.4 should have
included atom:link.


Mountain, meet molehill.

If it turns out to be useful, it'll stick.  Otherwise not. -Tim

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 5:25 PM, Kyle Marvin wrote:


the motivation behind
sometimes using 'extensionElement' and other times 'undefinedContext'
in the Relax-NG schemas for various 4287 elements is a point of
confusion.


Agreed.  Fortunately the schema's non-normative. -Tim

Re: Feed thread update

[Tim Bray]

On May 4, 2006, at 3:43 PM, Thomas Broyer wrote:


Things would have been far easier if either a) atom:link were
extensible


This assertion that atom:link is not extensible is simply, flatly,  
completely, wrong.  I just went and reviewed 4287 and I think it is  
perfectly clear on this.  I suggest that interested parties review  
sections 4.2.7, 6.3, and 6.4 and, if they still think there is any  
problem with child elements of , find language in the RFC  
which says something other than what those sections say. -Tim

Re: Does xml:base apply to type="html" content?

[Tim Bray]

On Mar 30, 2006, at 9:20 PM, James M Snell wrote:


I would agree that, as a best practice, the xml:base should appear on
the content element, but implementations need to be prepared to use
whatever the in-scope URI is (e.g. if no xml:base is specified,  
relative

refs in the content will be relative to Content-Location or the feeds
Request URI).


Maybe.  Highly error-prone.


  In other words, consumers of the feed *have* to assume
that the current xml:base in context is going to be correct and
publishers of the feed simply have to be responsible for Doing The  
Right

Thing.


Agreed.  I think providing an xml:base in your feed is a best  
practice. -Tim

Re: atom:name ... text or html?

[Tim Bray]

On Mar 23, 2006, at 2:20 PM, Eric Scheid wrote:


Oh well, now to track down a list of html entities and
their corresponding unicodes ...


http://www.google.com/search?q=xhtml%20entities

Re: Does xml:base apply to type="html" content?

[Tim Bray]

On Mar 23, 2006, at 10:03 AM, David Powell wrote:




xml:base applies to type="xhtml" content, but I'm not sure whether it
is supposed to apply to escaped type="html" content? I reckon that it
does.


RFC4287, section 2:

   Any element defined by this specification MAY have an xml:base
   attribute [W3C.REC-xmlbase-20010627].  When xml:base is used in an
   Atom Document, it serves the function described in section 5.1.1 of
   [RFC3986], establishing the base URI (or IRI) for resolving any
   relative references found within the effective scope of the xml:base
   attribute.

Seems pretty clear to me.  Yes, the base URI of that HTML is now  
whatever xml:base said it was -Tim

Re: atom:name ... text or html?

[Tim Bray]

On Mar 23, 2006, at 8:16 AM, Eric Scheid wrote:

If I have an author with the name "Bertrand Café", is it acceptable  
to put

that into atom:author like this;



or should I be using the unicode numeric entity instead?


The key point is that the atom:name element, described in RFC4287  
3.2.1, is not a "Text Construct", as defined in 3.1, so you can't say  
; so no markup allowed.  So just say "Bertrand  
Café".  -Tim

Re: atom:name ... text or html?

[Tim Bray]

On Mar 23, 2006, at 8:57 AM, Eric Scheid wrote:



On 24/3/06 3:21 AM, "Anne van Kesteren" <[EMAIL PROTECTED]>  
wrote:





Even if it was "HTML" you couldn't really use the entity, could  
you? I think
you have to use a character reference or the actual character  
instead, yes.




It's true that XML has only a half dozen or so entities defined


To be precise, 5: < & > ' " -Tim

Re: atom:name ... text or html?

[Tim Bray]

On Mar 23, 2006, at 8:01 AM, Sylvain Hellegouarch wrote:






Seriously though, the atom:name element is described as "a human- 
readable name",
Do you mean that "human-readable" is equivalent to solely English?  
Because as a French, having accents in names is so natural that I  
see it as "human readable" too ;)


You can have accents, you just can't use HTML entities to get them. -Tim

Re: IE7 Feed Rendering Issue

[Tim Bray]

On Mar 9, 2006, at 7:51 AM, Sean Lyndersay wrote:

I hope this helps make the reasoning behind IE’s behaviour with  
feeds and stylesheets a little less murky.
I don't really have an opinion as to whether this is the ideal  
behavior.  But there is no doubt whatsoever that that Sean's software  
is entirely within its rights.  It is almost never possible nor  
desirable for the transmitter of a general-purpose data format like  
most of those based on XML to try to impose behavior on the  
recipient.  In the big picture, this is one of the big advantages of  
open data formats.


 -Tim

Re: Atom logo where?

[Tim Bray]

On Mar 6, 2006, at 12:43 PM, Anne van Kesteren wrote:


Quoting Tim Bray <[EMAIL PROTECTED]>:
Where can one go to get versions of the atom logo (the one in view  
at  atomenabled.org) in various sizes?  -Tim


I guess SVG fits that definition:
http://zcorpan.1go.dk/sandbox/svg/atom/.xml


Oooh, now that is *cool*. -Tim

Atom logo where?

[Tim Bray]

Where can one go to get versions of the atom logo (the one in view at  
atomenabled.org) in various sizes?  -Tim

Re: [rss-public] Microsoft Feeds API Enclosure Test

[Tim Bray]

On Feb 24, 2006, at 3:05 PM, Sean Lyndersay wrote:

I'm sure that many people -- on this list in particular -- think  
that the right thing to do is to normalize to Atom 1.0, instead.  
Yep, that's certainly one way to think about it. But then I'd be  
having this same discussion with Dave and with folks on rss- 
public. :) In short, I'd rather avoid the issue altogether and  
provide some value to the developers who are using the platform --  
which means preventing them from having to learn several different  
formats to get common data, while allowing them to get access to  
extensions.


Given that Atom 1.0, in practice, is a clean superset of RSS 2.0  
(there are things in RSS 2.0 that aren't in Atom, but they are  
typically not used; see http://www.tbray.org/atom/RSS-and-Atom), the  
only one that's been through a formal standardization process, and  
the only that's guaranteed not to change (see IETF rules) this feels  
a little weird.  But it's your API.


I will say, though, that there are already a lot of Atom 1.0 feeds  
and there are going to be more, so it does seem like a basic  
requirement that your interface be able to model Atom 1.0 accurately  
without data loss.  I assume you agree that a failure to do this  
would be a bug. -Tim

Re: Browser behaviour

[Tim Bray]

On Jan 30, 2006, at 12:57 PM, John Panzer wrote:

In other words, the application/xml content is a fallback for when  
users, despite our best efforts, end up looking at XML content  
inside a web browser.  I'd also be happy to make this behaviior  
browser-dependent so that we serve application/atom+xml to browsers  
which will display it inline with a style sheet, if there are any.


This means that users might possibly end up subscribing to  
something of type application/xml if they copy and paste URL #3...  
but we could also make this client dependent so that, for example,  
everything other than known web browsers get application/atom+xml.   
Not sure about that as it's changing the MIME type, but I think  
it's changing it for a good reason (working around what I think is  
a browser problem).


Seems sensible. -Tim

Re: Browser behaviour

[Tim Bray]

On Jan 30, 2006, at 8:23 AM, James M Snell wrote:



+1. Serving atom up at application/xml is perfectly acceptable


It is *not*.  Atom has a registered Internet media type (application/ 
atom+xml); using anything else is a bug. -Tim

Re: [Fwd: Approval of Atom LinkRelations Attribute Value Registrations]

[Tim Bray]

On Jan 25, 2006, at 11:56 AM, James M Snell wrote:



APP should use the values as registered.  That is, previous, next,  
first, last and current.  No need to modify the registrations.


+1

Re: finishing autodiscovery, like now

[Tim Bray]

On Jan 19, 2006, at 9:05 AM, Robert Sayre wrote:



PaceAnchorSupport and PaceDifferentRelValue don't seem very useful,
and they weren't proposed by implementors. The spec is extremely
well-written and reflects existing behavior.

Can we please un-expire this:
http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html

and be done?


+1.  Ship it.  -Tim



--

Robert Sayre

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

Re: Reader 'updated' semantics

[Tim Bray]

On Jan 10, 2006, at 9:07 AM, James M Snell wrote:


In RSS there is definite confusion on what constitutes an update. In
Atom it is very clear.  If  changes, the item has been  
updated.

No controversy at all.


Indeed.  There's a word for behavior of RssBandit and Sage: WRONG.   
Atom provides a 100% unambiguous way to say "this is the same entry,  
but it's been changed and the publisher thinks the change is  
significant."  Software that chooses to hide this fact from users is  
broken - arguably dangerous to those who depend on receiving timely  
and accurate information - and should not be used. -Tim

Re: Reader 'updated' semantics

[Tim Bray]

On Jan 9, 2006, at 5:08 PM, James M Snell wrote:

The updated element is used to indicate when a significant update  
has occurred to the entry.  If you are updating the updated element  
when you update your entry, you are doing the right thing.  If  
RSSBandit and FeedDemon are not picking up the fact that the entry  
has been modified based on a changed updated value (even if the  
updated element is the only thing that is different), then I would  
say those readers have a bug.  You should never be changing your id  
element value.


James is exactly right.  The whole reason 'updated' exists is  
*exactly* so you can tell the downstream software unambiguously when  
some entry has changed and this ought to be brought to the consumers'  
attention.  -Tim

Re: Category URI's

[Tim Bray]

On Jan 9, 2006, at 1:12 PM, James M Snell wrote:

I'm in the process of going through a number of application  
scenarios with Atom and I'm coming up with a problem because I  
cannot associate a URI with a  element.


From my Atom feed:

term='Technology/XML' />


The scheme is identified by a URI. -Tim

Re: Tag URIs

[Tim Bray]

On Dec 17, 2005, at 9:01 PM, Alan Gutierrez wrote:



I'm to understand that Atom has adopted the Tag URI as a a perferred.
GUID for an Atom 1.0 feed.


It has not.  There is no preferred scheme. -Tim

Re: clarification needed: order of children of atom:entry

[Tim Bray]

On Oct 26, 2005, at 9:46 PM, Eric Scheid wrote:



Section 4.1.2 of the Atom Syndication Format spec states this:

   "This specification assigns no significance to the order of
appearance of the child elements of atom:entry."

Is this referring to the immediate children only of atom:entry, or  
of all

descendents?


In the XML context, the term "child elements" is not ambiguous.  So I  
think it means what it says, which is what you want it to mean. -Tim

Re: How to represent an authenticated identity in an tag

[Tim Bray]

On Oct 25, 2005, at 5:02 PM, Byrne Reese wrote:


The above is accomodated by the current spec, but the following is
something we would also like to represent somehow in a standard way:

* their authenticated identity (e.g. "breese") and the authenticating
authority (e.g. "LiveJournal," "TypeKey," "OpenID," etc.)


Sounds like an obvious candidate for an exception; why don't you and  
one or two competitors sketch it out and do an I-D?  I'd sure be in  
favor.  -Tim

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 22, 2005, at 8:40 AM, Mark Nottingham wrote:

You seem to be saying that because link/@rel="self" was designed  
for a specific purpose, and even though its definition is quite  
descriptive (its definition *only* says it should be used to link  
to the current document; -11 says nothing about subscription) it  
should be the only way defined to do subscription.


Agreed that the description could be better.  What I'm actually  
saying is "since we already have a way to do subscription, we don't  
need to invent another."  Also that the problem of pointing from the  
static/archived version of a feed to the dynamic/subscribable one is  
a related but different problem, and the one that you ought to be  
solving.



OTOH, I'm happy to make this relation more declarative. How about:

 -  Attribute Value: current
 -  Description: A URI that, when dereferenced, returns a feed  
document containing the most recent entries in the feed.

 -  Expected display characteristics: Undefined.
 -  Security considerations: Automated agents should take care when  
this relation crosses administrative domains (e.g., the URI has a  
different authority than the current document).


Thank you.  +1 -Tim

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 22, 2005, at 3:28 AM, Eric Scheid wrote:


I think you've got the special case turned around. That is, if you are
looking at a representation of the active feed then the 'self' link  
would
happen to match the 'subscribe' link, which is the exception. The  
defining

text in the spec says this about 'self'

The value "self" signifies that the IRI in the value of
the href attribute identifies a resource equivalent to
the containing element.

atom:[EMAIL PROTECTED]'self'] can also appear in atom:entry, which would  
be used
for pointing to Atom Entry Documents, which explains why the text  
says "the
containing element". I don't believe anyone is thinking we should  
be able to

subscribe to Atom Entry Documents.


I'm entirely unconvinced.  There are two kinds of feed, the dynamic  
kind and the static kind.  For dynamic feeds, use rel="self" to  
subscribe.   For static feeds, use some new relationship like  
rel="dynamic" to point to the dynamic version that you might  
subscribe to.


I agree that, in retrospect, the spec should have said that one  
intended use of rel="self" is to support auto-subscribe.  I don't  
think adding on a new link relationship is the right answer.



Are we yet in a situation were we have a preponderance of deployed  
feeds
using 'self' to mean 'subscribe'? Actually, that's the wrong  
question to ask

(see below)


Well, all the Atom feeds I see use rel="self" in the way you'd expect.


Are we yet in a situation were we have preponderance of deployed
applications that look for 'self' for subscription purposes?


Well, no, because we actually don't have that many apps yet that  
really grok Atom.  When they do, and they want to do auto- 
subscription, Atom is well-equipped to support it.


I think we're in the early days of Atom 1.0 adoption, and we can  
very likely
talk up via blogs, articles, etc the idea of "subscribe in the  
general case"

using @rel='subscribe'.


No.  We already have a way to do that and don't need to invent another.

-1 on rel="subscribe". -Tim

(oh, and I should have said, +1 on the rest of those relationships)

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 21, 2005, at 5:03 PM, Mark Nottingham wrote:


How about:

 -  Description: A URI that refers to a feed document containing a  
set of the most recent entries in the feed. This URI is intended to  
be subscribed to to keep abreast of recent changes in the feed;  
when different from the URI of the document where it occurs, it  
indicates that its value should be used for this purpose in place  
of the current document's URI. For example, an archived feed  
document might contain a "subscribe" relation that points to the  
subscription feed's location, so that clients subscribe to the  
appropriate link. Note that the "self" relation was designed for a  
similar purpose, but is not suitable for that use in other feeds,  
whereas this relation can be used in those situations.


On consideration, I am -1 to rel="subscribe".  The reason is this:  
one of the big potential value-adds Atom brings is a standards- 
compliant way to do one-click auto-subscribe, via >.  You are proposing to introduce a  which  
is there to support autosubscribe.  But, it turns out, only in the  
special case where the feed is static and you wouldn't actually  
subscribe to it.  I think the risk of confusing implementors and  
weakening the value proposition around exceeds the benefit of supporting this special case.


Plus, I think the thing isn't properly named.  It isn't actually  
"subscribe in the general case", it's "in the special case where the  
version you are looking at is static, point to the places where the  
changes happen because they don't happen here".  So, perhaps we  
should consider rel="current-self" or rel="dynamic-version" or some  
such.


Finally, markup design that claims to enforce a specific action is  
always questionable.  The great virtue of descriptive markup in  
general is that the tags tell you not what to do with things but what  
they are.  So on that basis, rel="current-version" or something is  
better design.  -Tim

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 21, 2005, at 3:13 PM, Mark Nottingham wrote:

 -  Description: A URI that refers to a feed document containing a  
set of the most recent entries in the feed. This URI is intended  
to be subscribed to to keep abreast of recent changes in the feed.  
When different from the URI of the document where it occurs, it  
indicates that its value should be used for this purpose in place  
of the current document's URI.


Any suggestions?


Yes.  Acknowledge the specific case of an archival feed, an example  
is worth a thousand words.


And discuss why this exist when Atom already has specifically designed to support auto-subscribe. -Tim

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 21, 2005, at 7:38 AM, James Holderness wrote:

The idea being that if you were to come across an archived Atom  
document (however that might happen), the presence of this link  
would, (a) let you know that it was an archive document and thus  
shouldn't be subscribed to, and (b) provide you with a URL with  
which you could subscribe to the actual feed if you so chose.


Makes sense, but not self-evident.  I would think that the usefulness  
of this thing would be improved by a few words of explanation for  
those who come upon it without knowing the history. -Tim

Re: New Link Relations -- Ready to go?

[Tim Bray]

On Oct 20, 2005, at 4:52 PM, Mark Nottingham wrote:


 -  Attribute Value: subscribe


I'm puzzled by this one.  I thought that if you wanted to subscribe  
to a feed then, well, you would subscribe to a feed.  I must have  
missed the discussion.  Could someone provide a pointer to the  
archive? -Tim

Re: Question about [EMAIL PROTECTED]

[Tim Bray]

On Oct 7, 2005, at 10:20 AM, Byrne Reese wrote:

Are there any good examples of how the [EMAIL PROTECTED] attribute is  
used?
Over at 'ongoing', I have my own set of categories, so my category  
elements look like




Remember, it's optional, both for the producer and for the consumer  
(Technorati, for example, ignores the scheme); but for well-defined  
taxonomies like Dewey Decimal or whatever, I think it would be a good  
idea to put a URI there to disambiguate them. -Tim

Re: Atom 1.0 ootb with MT3.2

[Tim Bray]

On Sep 9, 2005, at 5:03 AM, Bill de hÓra wrote:




Here's the feedvalidator results for my journal served up as  
Atom1.0 as

per MT3.2's Atom1.0 template

http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.dehora.net% 
2Fjournal%2Fatom.xml


I'm getting a 404 on that (or rather the feedValidator is) -Tim




I also see it uses tag: uris as the atom:id value. I think I'll change
the template to use the http: URI generated by MT3.2 for the  
individual

entries instead of the tag: (what the rest of the world calls
permalinks). I haven't tried to import/export to see if the atom:id is
preserved across installations.

Speaking of URIs and IDs, there is a gotcha around archive URIs if you
are upgrading to MT 3.2 [1].

cheers
Bill

[1]

Re: "Top 10" and other lists should be entries, not feeds.

[Tim Bray]

On Aug 30, 2005, at 3:08 PM, Walter Underwood wrote:


That is one kind of order. Other kinds are relevance to a search term
(A9 OpenSearch), editorial importance (BBC News feeds), or datetime of
original publication (nearly all blog feeds, not the same as last  
update).


Well put.  It's obvious that there exist feeds that have ordering  
requirements that are orthogonal to atom:updated.


It's plausible, but not obvious, that the first two kinds of order  
Walter enumerates are instances of a class which we might label  
"importance" or "priority".  It's also plausible, but even less  
obvious, that there are going to be lots of places where non-updated  
order matters in a way that has to do with "importance", to the  
extent that a generally-implemented extension will be useful.  It's  
also plausible, but not obvious, that there's no usefully- 
generalizable notion of "importance", that the semantics of this  
stuff are really application-specific, and that interested parties  
should go and do their own NetFlix or A9 or BBC extensions.  Or just  
cram your Netflix queue in a single entry.


Fortunately, the format spec, with its "assigns no significance"  
language, doesn't get in the way of people who want to work on this  
problem.  I can see two generalized approaches; the first is a  
singleton attribute of child of  that says "in this feed,  
 order reflects importance".  The second is such an  
attribute that says "in this feed, an ordering by the following  
namespaced-element child of  reflects importance".  I  
prefer the first.  I haven't looked at the Microsoft proposal.


Clearly, the WG lacks consensus, at least in the short term. -Tim

Re: If you want "Fat Pings" just use Atom!

[Tim Bray]

On Aug 22, 2005, at 9:56 PM, Bjoern Hoehrmann wrote:


If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.


That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined. So this scenario is
unconstrained by the XML specifications.


No.  See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal  
error". -Tim

Re: If you want "Fat Pings" just use Atom!

[Tim Bray]

On Aug 22, 2005, at 9:27 PM, A. Pagaltzis wrote:


It's got another advantage.  You connect and ask for the feed.
You get

http://www.w3.org/2005/Atom";>
 ... goes on forever 

and none of the entry documents need to redeclare the Atom
namespace, which saves quite a few bytes after the first
hundred thousand or so entries. -Tim


That’s the first really solid pro-single-doc argument I see…


There's another.  You don't have to create a new XML parser for each  
of the entries.  In most programming environments, that's a time- 
saver. -Tim

Re: If you want "Fat Pings" just use Atom!

[Tim Bray]

On Aug 23, 2005, at 6:57 AM, Bjoern Hoehrmann wrote:


That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature...



No.  See, http://www.w3.org/TR/REC-xml/#sec-terminology, under "fatal
error". -Tim



Yes, exactly what I wrote...


No.  The specification clearly *forbids* proceeding with normal  
processing.  If you get a busted element in a feed, you'd better  
close that connection and open another one. -Tim

Re: If you want "Fat Pings" just use Atom!

[Tim Bray]

On Aug 22, 2005, at 6:15 PM, Justin Fletcher wrote:

Ah; I misread that in the specification. Thanks. It's just the lack  
of well-formedness that is an issue in my head then.


If you encounter a busted tag on the Nth entry, per the XML spec  
that's a fatal error and you can't process any more.  But I'm pretty  
sure that there's nothing in the XML specifications that says you  
can't process the material before the breakage occurs.  Given that  
the overwhelming majority of these are going to be machine generated  
by production applications, I suspect the amount of breakage at the  
well-formedness level to be low. -Tim

Re: If you want "Fat Pings" just use Atom!

[Tim Bray]

On Aug 22, 2005, at 7:26 AM, Joe Gregorio wrote:


Essentially, LiveJournal is making this data available to anybody who
wishes to access it, without any need to register or to invent a  
unique API.


Ahh, I had thought this was a more dedicated ping traffic stream. The
never ending Atom document makes much more sense now.


It's got another advantage.  You connect and ask for the feed.  You get

http://www.w3.org/2005/Atom";>
 ... goes on forever 

and none of the entry documents need to redeclare the Atom namespace,  
which saves quite a few bytes after the first hundred thousand or so  
entries. -Tim

Re: Extensions at the feed level (Was: Re: geolocation in atom:author?)

[Tim Bray]

On Aug 21, 2005, at 1:42 PM, A. Pagaltzis wrote:


* Paul Hoffman <[EMAIL PROTECTED]> [2005-08-21 21:55]:


Ah, I had missed that. This leads to a question for the mailing
list. Does an informative extension that appears at the feed
level (as compared to in entries) indicate:



d) completely unknown unless specified in the extension
definition


Atom itself has precedent for both b) and c). So I would say
it’s d) – but also that aggregators should assume b) when they
don’t know any better.


Right, the only possible answer. -Tim

Re: Feed History -03

[Tim Bray]

On Aug 17, 2005, at 4:10 AM, Henry Story wrote:

Yes. I agree the problem also exists for complex extensions. My  
question is the following:


How can a parser that parses atom and unknown extensions, know when  
to apply the xml base to

an extension element automatically?


It can't.

Anyway to summarise: if you don't want to use the atom:link element  
then perhaps it would
be best to use the xlink:link attributes. I have only read that  
spec quickly [1] but this would

mean that the following

  


That would work.  I haven't been following this discussion closely  
enough to understand why there's resistance to 


 -Tim

Re: xml:base abuse

[Tim Bray]

On Aug 15, 2005, at 7:28 AM, Tim Bray wrote:

The way Tim Bray's feed and the examples from James Snell on  
developerWorks use xml:base is what Roy T. Fielding calls an abuse.


I disagree with Roy, but agree that the way my links were set up was  
a little surprising to the eye, so I tweaked.  Check out


http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.tbray.org% 
2Fongoing%2Fongoing.atom


 -Tim

Re: xml:base abuse

[Tim Bray]

On Aug 15, 2005, at 6:20 AM, Sjoerd Visscher wrote:



Hi,

A while ago we had a discussion about how xml:base should be used.
We didn't reach a conclusion, but I think we need to act.

The way Tim Bray's feed and the examples from James Snell on  
developerWorks use xml:base is what Roy T. Fielding calls an abuse.


I do plan to revise my feed, will try to do so in the next day or  
two. -Tim

Re: Spec explanations for Pebble?

[Tim Bray]

On Aug 13, 2005, at 1:34 AM, Simon Brown wrote:

Just to quote an example, Tim is currently using URL based Atom  
IDs, such as :


http://www.tbray.org/ongoing/
http://www.tbray.org/ongoing/When/200x/2005/08/09/Web-2.0

If Tim *moves* his blog to www.timbray.com/ongoing, would you  
expect his Atom

IDs to remain the same?


Absolutely, otherwise everyone who subscribes to me is going to see  
all the same old articles again, exactly what atom:id exists to  
prevent.  The fact that I use HTTP URIs for identifiers reflects my  
belief that good Web citizenship requires that once something is  
published and its URI widely disseminated, it should never ever be  
moved; so in my case this scenario is unlikely to arise. -Tim

Re: Spec explanations for Pebble?

[Tim Bray]

On Aug 12, 2005, at 1:55 AM, Graham Parks wrote:

"categorization scheme" means the system used to categorize  
entries. Presumably each blog has its own system for doing so, so  
the scheme attribute should be the same for all posts from the same  
blog, and unique to the blog.


Mostly agree.

Except for, a bunch of blogs might agree to share a categorization  
scheme, so probably not "unique to each blog".


But I suspect that the notion of "categorization scheme" is  
underdefined enough that if someone wanted to use different URIs for  
each page like the example Carey cited, that's really dumb but not  
actually illegal. -Tim

Re: More about Extensions

[Tim Bray]

On Aug 9, 2005, at 5:11 PM, David Powell wrote:


No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must not expect it to be preserved.


Either the software understands the foreign markup, in which case it  
might recognize a relative URI, in which case it should apply the  
correct base URI, or it doesn't, in which case everything in the  
foreign markup is just a semantics-free string.


The problem could hypothetically arise when someone extracts  
properties from the foreign markup, stuffs them in a tuple store, and  
then when the software that knows what to do with comes along and  
retrieves it and recognizes the relative URI and can't do much  
because the base URI is lost.


So... IF you know how to handle some particular extension, AND IF you  
expect to handle it when the extension data has been ripped out of  
the feed and stored somewhere without any context, THEN you shouldn't  
use a relative reference.  Alternatively, IF you want to empower  
extensions to process they data they understand, AND IF you want to  
rip that data out of the feed and store it somewhere, THEN it would  
be smart to provide software an interface to retrieve context, such  
as feed-level metadata and the base URI.


Sounds like implementor's-guide material to me.

And, to whoever said relative references are "fragile": Wrong.  When  
you have to move bales of web content around from one place to  
another, and just supposing hypothetically that you have internal  
links, relative references are robust, absolute URIs are fragile.  -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 3, 2005, at 6:04 AM, Sam Ruby wrote:


To an Infoset person, this following is a completely different stream
from the example above (please ignore any line breaks that your email
client may insert):

http://exam 
;ple.com/fooatom:id>


I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 6




Infoset views the below two examples as different:


http://example.com/foo


I believe this is incorrect, see http://www.w3.org/TR/xml-infoset/ 
#omitted, item 19


Or am I missing something obvious? -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 7, 2005, at 5:41 PM, Bill de hÓra wrote:


Exclusive canonicalization (which is the one we care about here) like
canonicalization keeps whitespace inside element content significant.
Those bytes are counted. I take that as meaning in the dsig case,
trimming is broken.


The c14n/dsig implementations I know of would agree with you.  The  
XML and RFC3470 are both crystal-clear on this. -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 4, 2005, at 1:04 PM, Sam Ruby wrote:


Tim Bray wrote:



I'm getting increasingly grumpy and "just fail" is looking better and
better.  The current normative text, "The element's content MUST  
be  an

IRI", is clear and simple and supported by other well-understood
normative text, supported by lots of interoperable software, that   
make

the meanings of "element", "content", and "IRI" not really open  to
intelligent dispute.  I claim that text enjoyed strong, not rough,
consensus support from the WG.



I believe that the term "content" is open to intelligent dispute.
Apparently the authors of RFC3470/BCP70 believe so too.


Could you reference that?  It seems to me that the guidance we should  
take from 3470 is from section 4.16, which seems to me to make it  
clear that *we* should make it clear that



 http://example.com/foo


is an error and nothing but an error. -Tim

Re: Simple Extensions and xml:base

[Tim Bray]

On Aug 5, 2005, at 5:59 AM, David Powell wrote:

We say that Simple Extension Elements are not language sensitive,  
but

They *are* affected by xml:base.  xml:base establishes the base URI
for wherever it's in-scope, with a specific callout to RFC3986 for
the semantics.  Anytime you see something that you know is a relative
URI reference, you have to absolutize it using the base URI, and the
base URI is what xml:base says it is.  -Tim


Yes, I understand, but I disagree.  xml:base only affects things  
that are

designated to be URI references.  I wouldn't expect
/index.html to get resolved as a URI, because
atom:title isn't defined to be a URIRef.  Neither are Simple Extension
Elements.


Right, but anyone who reads a simple extension out of an Atom feed  
and finds something they consider to be a relative URI reference, and  
wants to absolutize the reference, either uses the base URI as  
established by xml:base, or they are wrong. -Tim

Re: Comments Draft

[Tim Bray]

On Aug 4, 2005, at 10:59 PM, Eric Scheid wrote:


http://www.example.com/atom";
  type="application/atom+xml"
  thread:idref="urn:foo:1" />

this way processors that have a basic understanding of what a  
 is can

still do something useful.


Uh, consider

http://example.org/evil"; />

What useful thing is there that software could sanely do, knowing  
only that something is a link? -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 4, 2005, at 7:24 PM, Robert Sayre wrote:


Leading and trailing whitespace input for
these fields should be discarded by a robust scanner, and doing so
proposes no risk to compliant feeds, unlike guessing the "true
meaning" of an ampersand in an RSS feed. So, it will be my
recommendation to ignore this MUST-level requirement of the Atom spec
in any consumer aggregator that I contribute to. I think it might be
useful as bozo filter in an Atom protocol server, because the lazy
thing for client implementors to do is find a decent serialization
library. The lazy thing for publishers to do is concatenate strings in
their loosely-typed language of choice.


Uh, anyone who's lazily concatenating strings is pretty soon going to  
end up with a free ampersand or something worse in their Atom feed.   
Right? -Tim

Re: Simple Extensions and xml:base

[Tim Bray]

On Aug 4, 2005, at 11:21 PM, David Powell wrote:


We say that Simple Extension Elements are not language sensitive, but
we don't say that Simple Extension constructs aren't affected by
xml:base.  I think that the implication is that they are not, but it
is not very explicit:


They *are* affected by xml:base.  xml:base establishes the base URI  
for wherever it's in-scope, with a specific callout to RFC3986 for  
the semantics.  Anytime you see something that you know is a relative  
URI reference, you have to absolutize it using the base URI, and the  
base URI is what xml:base says it is.  -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 4, 2005, at 6:53 AM, Robert Sayre wrote:


I propose trying harder, but I am open to "just fail".


As am I. I am not OK with a long treatise on whitespace, like the one
Tim suggested. If there is a MUST-breaking error in a feed, that's not
an Atom document and I don't want to talk about  it. I slightly prefer
documenting and allowing what the world's PHP scripts have been
observed to produce, but either way is fine. BTW, my proposed text was
taken from HTML 4.01.


I'm getting increasingly grumpy and "just fail" is looking better and  
better.  The current normative text, "The element's content MUST be  
an IRI", is clear and simple and supported by other well-understood  
normative text, supported by lots of interoperable software, that  
make the meanings of "element", "content", and "IRI" not really open  
to intelligent dispute.  I claim that text enjoyed strong, not rough,  
consensus support from the WG.


So my preferred course of action would be to leave it the way it  
bloody well is.  The Feed validator should throw whitespace-polluted  
pseudo-Atom on the floor, and if some bozos persist in producing it,  
and some implementors decide to work around this error, well, that's  
the way the Internet is.  But if a couple of leading implementations  
decide to be strict, and the producers develop a culture of Doing The  
Right Thing, well then, that's the way the Internet is too,  
sometimes.  PHP is, if nothing else, flexible and friendly to quick  
changes in deployed scripts, I can hear a zillion publishing-system  
hackers grumbling "Oh, it's that damn tight-assed Atom stuff, guess I  
have to use mod_finicky here".


So for now, I'm -1 on an weakening or removing "The element's content  
MUST be an IRI" or analogous text in any other section. I'll stop  
shouting if I'm in a small minority here.  -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 4, 2005, at 3:25 AM, Paul Hoffman wrote:



At 7:37 PM -0400 8/2/05, Robert Sayre wrote:


One way of saying this would be "Atom Processors MAY ignore leading
and trailing whitespace in _."



That works for me. Another idea is "Atom Processors MAY ignore  
leading and/or trailing whitespace in elements whose content does  
not allow leading and/or trailing whitespace, such as IRIs and  
."


The more I think about this family of suggestions, the less I like  
them.  There is no coherent argument from the published  
specifications of XML and IRIs that allows our 4.2.6 language "Its  
content MUST be an IRI" to regard



http://example.com/foo


as anything but an error.  I suggest an alternate formulation:
===

"Implementors are advised that there is a common class of error in  
which, when the content of an element is specified as being an IRI,  
software which generates Atom documents introduces spurious white  
space before and after the IRI, for example:



 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6


In this case, since [RFC3987] makes it clear that the leading and  
trailing white space cannot be part of the IRI, implementors MAY  
choose to be forgiving in regards to this error, by ignoring the  
leading and trailing white space."

===

I'm strongly -1 on treating this as anything but an error.  We may at  
our discretion make it forgiveable.  This formulation would also  
allow the feed validator to complain.


I suppose if we did this, we should generalize it slightly to apply  
to date constructs as well. -Tim

Re: spec bug: can we fix for draft-11?

[Tim Bray]

On Aug 2, 2005, at 4:37 PM, Robert Sayre wrote:


One way of saying this would be "Atom Processors MAY ignore leading
and trailing whitespace in _." That is, no existing
software is buggy, but if you want to be sure your document is
processed accurately, you should trim the space yourself.


Ecch.  Blecch.  Barf.

I suppose.

I personally think the framework of specifications is crystal-clear,  
and per the letter of the law



http://example.com/foo


is totally illegal because the string \nhttp://example.com/foo\n does  
not conform to the productions for either URI or IRI.


I am less convinced that people are actually going to do this, but I  
do agree that if a substantial number *do* do this, implementors will  
simply ignore us and code around it.  So if the WG really thinks this  
is a sensible clarification I won't scream too much.  -Tim

Re: Atom 1.0 xml:base/URI funnies

[Tim Bray]

On Jul 19, 2005, at 3:23 AM, Sjoerd Visscher wrote:



A. Pagaltzis wrote:

It makes me wonder whether the person who wrote the example was  
unaware of the consequences of the same-document reference  
specifications in the URI RFC. Surely, the xml:base WG must have  
noticed this issue and discussed it?




I wonder how many people are aware of it. I wonder if we managed to
convince any readers on the atom list at all. Tim Bray hasn't  
responded

yet, so I guess he is still in doubt.


Yeah, still thinking, haven't had time enough to think about all this  
correspondence. -Tim

Re: Atom 1.0 xml:base/URI funnies

[Tim Bray]

On Jul 17, 2005, at 8:16 AM, Sam Ruby wrote:

Upon further reading of 3986, I'm convinced that Tim's current feed  
is correct.


I think so too, but I'm worried how XML-reader implementations will  
do supporting all this base-URI stacking.  If this kind of thing is  
going to cause breakage, maybe it's not good practice.  Consider this  
in the context of http://diveintomark.org/archives/2004/08/16/specs


However, Base URI Embedded in Content.  In XML documents, this  
takes the form of xml:base attribute values.  This is the case in  
Tim's feed.


And further note that our section 2. of the Atom spec specifically  
calls out 5.1.1 of 3986; so I think the rules are on my side. -Tim

Re: Atom 1.0 xml:base/URI funnies

[Tim Bray]

On Jul 16, 2005, at 11:20 AM, Tim Bray wrote:

I got an email last night from a well known syndication implementor  
pointing out an obvious bug in my Atom feed.  The feed's valid, but  
the stuff in  was full of relative URIs which were broken  
because I'd borked the xml:base.  So I went through the code and  
got the xml:base right and ruthlessly pruned all the pointers.


Hey hey hey, it turns out xml:base is supposed to stack.  Thus.


ongoing


  ...

  Atom 1.0
  

Re: Atom 1.0 xml:base/URI funnies

[Tim Bray]

On Jul 16, 2005, at 1:28 PM, Sam Ruby wrote:


I didn't realize that "path-empty" was a valid URI-reference.


Yeah, it means "here".

While it clearly shouldn't be the default behavior, longer term  
(i.e., sometime well after basic Atom 1.0 support is more  
complete), how much value do you think that there would be value in  
an option to attempt to verify all potentially dereferencable URIs  
resolve to accessible resources?


I was actually going to propose that very thing.  I think it would be  
highly useful.  -Tim

Atom 1.0 xml:base/URI funnies

[Tim Bray]

I got an email last night from a well known syndication implementor  
pointing out an obvious bug in my Atom feed.  The feed's valid, but  
the stuff in  was full of relative URIs which were broken  
because I'd borked the xml:base.  So I went through the code and got  
the xml:base right and ruthlessly pruned all the pointers.  The feed  
looks a little weird and it's giving the (pre-alpha) validator a  
heartburn, but I sort of think it's right.  I also think it's good  
practice.  Check it out:



ongoing


rsslogo.jpg
/favicon.ico
2005-07-16T11:17:23-08:00
Tim Bray
ongoing fragmented essay by Tim Bray
http://www.tbray.org/ongoing/
All content written by Tim Bray and photos by Tim Bray  
Copyright Tim Bray, some rights reserved, see /ongoing/misc/ 
Copyright
Generated from XML source code using  
Perl, Expat, XML::Parser, Emacs, Mysql, and ImageMagick.  Industrial  
strength technology, baby.


  Atom 1.0
  
  http://www.tbray.org/ongoing/When/200x/2005/07/14/Atom-1.0
  2005-07-14T13:00:00-08:00
  2005-07-16T11:17:12-08:00
  term='Technology/Atom' />
It’s  
cooked

  ... eliding ...

  ... eliding ...
  

Re: The Atomic age

[Tim Bray]

On Jul 15, 2005, at 12:35 PM, Robert Sayre wrote:



http://feedvalidator.org/check.cgi?url=http%3A%2F% 
2Fwww.fondantfancies.com%2Fblog%2Fatom1%2F


Hmm... the feed looks OK to me; I wouldn't be surprised if it's  
tickling a bug in the just-barely-into-beta Atom 1.0 feedvalidator  
code. -Tim





:)

Robert Sayre

On 7/15/05, Graham <[EMAIL PROTECTED]> wrote:



On 15 Jul 2005, at 4:56 pm, Walter Underwood wrote:



Do we have a list of who is implementing it? That could be used in
the "Deployment" section of .




My blog has one here:
http://www.fondantfancies.com/blog/atom1/

I think it's valid, though it's hard to tell without a validator or
even a parser. I'm currently rewriting the engine of Shrook to be
compatible too.

(You may also notice I'm doing my little bit to make sure atom:id is
implemented properly)

Graham Parks

Re: The Atomic age

[Tim Bray]

On Jul 15, 2005, at 8:56 AM, Walter Underwood wrote:



--On July 14, 2005 11:37:05 PM -0700 Tim Bray  
<[EMAIL PROTECTED]> wrote:




So, implementors... to  work.



Do we have a list of who is implementing it? That could be used in
the "Deployment" section of <http://www.tbray.org/atom/RSS-and-Atom>.


Good idea.



Ultraseek will implement Atom. We need to think more about exactly
what it means for a search engine to implement it, but we'll at
least spider it.


Want to write a few words in web-space somewhere, Walter, and we can  
put that in the Wiki? -Tim

The Atomic age

[Tim Bray]

Paul assures me that the remaining IETF process steps will not  
introduce material technical changes, and so format-10 is appropriate  
as a basis for implementors to go to work.  So, implementors... to  
work.  And everyone, now is a good time to tell the world.  -Tim

Re: The Atom namespace, etc.

[Tim Bray]

On Jul 14, 2005, at 12:58 PM, Paul Hoffman wrote:



And, the two Security Area Directors have signed off on the  
Security Considerations section in -10.


Which is to say, we need one more sign-off and a couple of  
bureaucratic buttons pushed, and Atom will be an IETF "proposed  
standard", and we can all start telling the world, loudly.  (It'll be  
a while, months perhaps, before we get an RFC number, but that turns  
out not to matter).  I'd prefer to wait until we have those sign-offs  
and those button-pushes before we get too excited, because Things Can  
Go Wrong.  -Tim

Atom format progress

[Tim Bray]

The Atom Format draft was considered by the IESG today, and there  
remain some outstanding DISCUSS issues, see:


https://datatracker.ietf.org/public/pidtracker.cgi? 
command=print_ballot&ballot_id=1681&filename=draft-ietf-atompub-format
https://datatracker.ietf.org/public/pidtracker.cgi? 
command=view_id&dTag=11964&rfc_flag=0


We need a format-10 draft to incorporate solutions to these; Rob and  
Mark are on it.  The WG has seen all the currently-planned changes,  
so -10 should have no surprises.  Paul is working (a huge amount,  
you'd be astounded) on interfacing to the IESG.


Stand by. -Tim

Re: Major backtracking on canonicalization

[Tim Bray]

On Jul 6, 2005, at 3:28 PM, Paul Hoffman wrote:



Greetings again. I gravely misunderstood XML Canonicalization, and  
as it has been explained to me now, XML Canonicalization would be a  
disaster for Atom: what we want is Exclusive XML Canonicalization.


Urgh, I should have caught this.  Correct.  +1 -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 4:08 PM, Paul Hoffman wrote:

Intermediaries such as aggregators may need to add an atom:source  
element to an entry that does not contain its own atom:source  
element. If such an entry was signed, the addition will break the  
signature. Thus, a publisher of individually-signed entries should  
strongly consider adding an atom:source element to those entries  
before signing them.


Grumble grumble OK.  -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 1:05 PM, David Powell wrote:


Will we still be fixing some of bugs raised since the last draft
though?


Definitely.  A number of things have been pointed out as bugs,  
there's been no WG pushback on any of them, and since we were going  
to have to have a -10 draft anyhow for the namespace, we will roll in  
those fixes, as well as resolving any IESG-raised issues.  -Tim




Specifically, what are the resolutions for the disputed ban on
composite MIME types [1], and some of the specific bugs in section 6
[2] (mismatches with the RelaxNG etc)?

[1] http://www.imc.org/atom-syntax/mail-archive/msg15911.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg15915.html

--
Dave

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 12:50 PM, Walter Underwood wrote:


I'm fine with the delay. Two or three weeks on top of 18 months is
not a big deal.


I am *not*.   It's not "two or three weeks", it's "some  
uncontrollable time in the future" versus "now".  We have spent way  
too long already. -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 9:54 AM, Antone Roundy wrote:

"When signing individual entries that do not contain an atom:source  
element, be aware that aggregators inserting an atom:source element  
will be unable to retain the signature. For this reason, publishers  
might consider including an atom:source element in all individually  
signed entries."


Still -1, despite Bob's arguments, at least in part because we have  
no idea what kind of applications are going to be using signed  
entries and we shouldn't try to micromanage a future we don't  
understand. -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 9:27 AM, James M Snell wrote:
Huh?!  Pardon my ignorance, could you please provide an  
explanation  for the simple-minded as to how the absence of a  
source element in a  signed entry will lead to signatures being  
discarded?  Also, it would  be helpful to sketch in some of the  
surrounding scenario... -Tim


Bob can clarify exactly what he means but from my perspective it  
comes down to an aggregation problem.  If a signature is generated  
over an entry that does not contain an author element or a source  
element, that entry cannot be re-enveloped into an aggregate feed  
that does not contain a top level author element without breaking  
the signature


Well, yes.  Anyone who understands digsig, even someone such as  
myself with only a surface knowledge, can see this.  You can't change  
a signed object without breaking the sig, that's the point.  If I  
want to sign an entry and also want to make it available for  
aggregation then yes, I'd better put in an atom:source.  But this is  
inherent in the basic definition of digsig; not something we need to  
call out.   -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 5, 2005, at 8:58 AM, Bob Wyman wrote:


We can debate what it means to have an "interoperability" issue,
however, my personal feeling is that if systems are forced to break  
and
discard signatures in order to perform usual and customary  
processing on
entries that falls very close to the realm of interoperability if  
not within
it. Deferring this issue until the implementer's guide is written  
is likely
to defer it beyond the point at which common practice is  
established. The
result is likely to be that intermediaries and aggregators end up  
discarding

most signatures that appear in source feeds.


Huh?!  Pardon my ignorance, could you please provide an explanation  
for the simple-minded as to how the absence of a source element in a  
signed entry will lead to signatures being discarded?  Also, it would  
be helpful to sketch in some of the surrounding scenario... -Tim

Re: Roll-up of proposed changes to atompub-format section 5

[Tim Bray]

On Jul 4, 2005, at 7:38 PM, Bob Wyman wrote:



   I believe it would be very useful to specify that signed entries  
should include a  source element. This can/should be considered  
part of entry canonicalization.


-1.  Leave it to the market.  I suspect that you're right, but I'd be  
unsurprised if an application for signed un-sourced applications  
turned up.  -Tim


   The reason I suggest this is that signed entries are only really  
useful when extracted from their original source feeds. If entries  
are only read from their source feeds, then it is probably best for  
publishers to sign the feed, not the individual entries. (Note: It  
is my hope that feed publishers will anticipate that their entries  
will be extracted from the source feeds and will thus sign the  
individual entries rather than the feeds... i.e. Publishers should  
anticipate that intermediaries like PubSub and various other search/ 
discovery services will aggregate their entries and republish them  
in non-source feeds.)
   When an entry is removed from its source, it SHOULD have a  
source element inserted if one is not already present. However, if  
a republisher inserts a source element into a signed entry that  
would break the signature. Thus, it seems reasonable that we should  
strongly encourage those who sign entries to anticipate the needs  
of subsequent processors by inserting the source elements in the  
original signed entries. By inserting the source elements, the  
requirement for others to break the signature will be drastically  
reduced. If an entry is signed, yet contains no source element,  
much of the utility of the signature (allowing verification of the  
original publisher) is eliminated.


   bob wyman

Re: Clearing a "discuss" vote on the Atom format

[Tim Bray]

On Jun 30, 2005, at 6:26 PM, Paul Hoffman wrote:



Greetings again. Russ Housley, one of the two Security Area  
Directors, has placed a "discuss" vote on the Atom format document.  
You can read it at >. Fortunately, it  
seems reasonably easy to clear this discuss.


I'm +1 on Paul's changes. One editorial comment:


To be added near the beginning of Section 5 of atompub-format:

   Producers of feeds and/or entries, and intermediaries who aggregate
   feeds and/or entries, may have sound business reasons for signing
   and/or encrypting otherwise-unprotected content. For example,
   a merchant might digitally sign a message that contains a discount
   coupon for its products. A bank that uses Atom to deliver customer
   statements is very likely to want to sign and encrypt those
   messages to protect their customers' financial information and to
   assure the customer of their authenticity. Intermediaries may want
   to encrypt aggregated feeds so that a passive observer cannot tell
   what topics the recipient is interested in. There are hundreds
   of other reasons why Atom documents might be signed, encrypted,
   or both.


I'd cut this back to one sentence saying.

"There are many application scenarios where Atom users will wish to  
apply digital signature, encryption, or both to Atom documents."


The examples are non-comprehensive now and will probably look  
hopelessly quaint before too long.


But if people prefer Paul's language I can live with it. -Tim

Re: IESG defers discussion of the format document for two weeks

[Tim Bray]

On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:


If there are problems
that require repair, I don't want to wait two more weeks to find out
about them.  This is very disappointing. -Tim




we can start with these two...






Nope, these are non-controversial editorial improvements which need  
not slow us down, they can go into that last draft that we'd have to  
do anyhow to fix the errors that have been turned up and put in the  
contributors and so on.  Specifically, they want us to make it  
clearer that yes, we do have two similar-looking instances of type=  
with different rules, and to make it clear that to dereference a IRI  
you have to turn it into a URI.  The person who put the "defer" on  
didn't raise these issues.  -Tim

Re: IESG defers discussion of the format document for two weeks

[Tim Bray]

On Jun 23, 2005, at 7:18 AM, Paul Hoffman wrote:


In other words, this isn't bad news, just a delay.


Fully disagree.  The world has many implementors eagerly awaiting the  
arrival of Atom so they can start using it.  If there are problems  
that require repair, I don't want to wait two more weeks to find out  
about them.  This is very disappointing. -Tim

Re: Signature wording

[Tim Bray]

On Jun 22, 2005, at 12:03 PM, James M Snell wrote:

I'm planning to write a separate Internet-Draft that discusses  
digital signing of Atom feeds and entries.  Some parts of that  
document will includes mandates; other parts will include  
recommendations.  We can describe for entry producers a way of  
producing signed entries that can be aggregated with original  
signatures in tact and a set of recommendations to aggregators that  
wish to pass those signed entries around with signatures in tact.   
Sure, it's all up to the aggregators and content providers to  
decide whether or not they want to support those methods -- which  
is the whole point of I'm working on this as a separate I-D and  
positioning it as an optional extension to Atom. :-)


A man who spots a problem, then volunteers to do the work around  
fixing it!  We need more like that.  I suspect that there's an  
excellent chance that this might become a WG draft, but I remained  
concerned about our lack of hands-on experience. -Tim