The IESG wrote:
The IESG has received a request from an individual submitter to consider
the
following document:
- 'Atom Threading Extensions '
<draft-snell-atompub-feed-thread-10.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send any comments to the
[email protected] or [email protected] mailing lists by 2006-06-12.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-10.txt
I'm -0 this becoming a Proposed Standard. I think this is really cool,
has room for interop problems, probably has security issues, and thus is
arguably premature/innovative and could be considered informational.
One reason I think it's cool is not for commenting support but for cheap
full duplex/reliable messaging - traditionally a SOAP use case.
FTR, I have no implementation experience with Feed Thread, haven't
studiously followed the discussion on atom-syntax and that basis feel my
opinion doesn't count for that much.
== Multiple references
<thr:in-reply-to
ref="tag:entries.com,2005:1"
type="application/xhtml+xml"
href="http://www.example.org/entries/1"/>
In particular the RNC:
in-reply-to =
element thr:in-reply-to {
atomCommonAttributes,
( ref, source?
| href, type?
| ref, source?, href, type? )
}
varies in co-occurrence constraints. No one attribute seems to be
required in all cases, which is a problem imo (if I'm wrong I'll argue I
still have a point that it's unclear what an implementor should look
for). I think this will be an interop headache and that either ref or
href should always be required. Naturally ref to atom:id is to spec the
right choice, but in practice it seems the first thing anyone will want
to do unless they are the authority for the comment *and* the entry is
pull down what's being replied to via href. Otoh, mandating ref implies
as yet undeployed/unstandardised lookup/query services for atom:id - we
have enough experience now with identity lookup services
(CORBA/Agents/JNDI/UDDI/SPARQL) to suggest that this kind of service
won't ever be deployed uniformly, or will be deployed in a way that
isn't some kind of SPOF or business model or outright failure. That, or
the feature will end being limited to local cases where ref is preferred
over href (point to point integrations come to mind, hence the mention
of SOAP).
This of course is fallout from the way identity in Atom is specced,
which is also a hedge. Feed Thread imvho should consider getting off the
fence on id v link and providing guidance for follow on extensions.
== @rel optionality
[[[
allow Atom clients that are not familiar with the in-reply-to
extension to know that a relationship exists between the entry and
the resource being responded to, publishers are advised to consider
including a "related" link referencing a representation of the
resource identified by the in-reply-to element.
]]]
I think to do anything useful with this relation you would have had
enough code written to switch on thr:in-reply-to to begin with. It could
be struck.
== Interop
There are multiple publishing options in terms of how to associate
comments with entries/comments. That this hasn't bitten anyone yet seems
to me to be a combination/result of lack of implementations targeting
the feature, Atom's mU policy for extensions, and (possibly) a lack of
experience with comment aggregation across publishing and aggregating
authorities.
Do the WG believe this will work out with multiple authorities using
multiple stacks?
== Security
[[[
As this specification defines an extension to the Atom Syndication
Format, it is subject to the same security considerations as defined
in [RFC4287].
]]]
I have a serious enough quibble with this statement (the ddos attack
note notwithstanding). As an atom foreign markup extension, it's true on
the face of things, but the thr:reply-to semantics introduce
attribution/repudiation issues as well as providing aggregator/planet
spamming options. IOW thr:in-reply-to seems to standardise the same
attack/spam vectors we see in mail for feeds and this needs to be
acknowledged given spam mail is a multi-billion dollar sinkhole (or
industry depending on the pov). That's a dramatic way to state things
sure, but not without some truth. So - where's the digest/sig hook?
James, you know this stuff... :)
cheers
Bill
