Bill, Thank you very much for the detailed feedback. Comments inline.
Bill de hÓra wrote: >[snip] > 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. > I am not opposed to informational status for the extension. I would prefer Standards Track, of course, but in general, In general, I have a number of deep concerns over whether or not there is enough of a consensus in the Atom community about the right ways of extending the format. It may very well make more sense to hold off on standardizing any extensions to the format until the community has had more time to figure out the "right" approach. Perhaps it would also make sense to consider a formal WG focusing on Atom extensions. >[snip] > == 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. > This design stems from a design decision to support responses to resources that do not have an Atom representation (and therefore no atom:id to reference). Alternatively, the resource being responded to may only exist as an entry within an Atom feed and therefore only be referenceable via it's atom:id. Or, the resource being responded to may only exist as an item within an RSS feed that has no guid NOR a stable URI that may be used to reference it. We could require ref at a minimum. Doing so would require that implementations using the element to reference non-Atom resources would be required to come up with some way of uniquely identifying those resources. I think this is acceptable as I believe it safely covers the majority of the use cases. I do not believe that mandating ref would require any kind of atom:id lookup mechanism. > > == @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. > Agree. > == 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? > What kinds of issues are you anticipating would be a problem? Specifically, I'm not sure what you mean by "There are multiple publishing options in terms of how to associate comments with entries/comments." Can you expand a bit on this? > > == 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... :) > A statement could be added to the Security Considerations recommending the use of XML digital signatures per RFC4287. Also, a statement describing the possibility for abuse, particularly in aggregator/planet scenarios is a good idea. I will work on beefing this up. - James > cheers > Bill > >
