Fwd: Last Call: draft-nottingham-atompub-feed-history (Feed Paging and Archiving) to Proposed Standard
FYI --Lisa Begin forwarded message: From: The IESG [EMAIL PROTECTED] Date: January 19, 2007 1:07:21 PM PST To: IETF-Announce ietf-announce@ietf.org Subject: Last Call: draft-nottingham-atompub-feed-history (Feed Paging and Archiving) to Proposed Standard Reply-To: ietf@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Feed Paging and Archiving ' draft-nottingham-atompub-feed-history-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. In particular, the IESG would like to know of planned implementations and considerations of appropriateness for Standards Track. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-nottingham-atompub-feed- history-08.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi? command=view_iddTag=13260rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Atom Entry Documents
I don't feel that changing parts of RFC4287 is appropriate for an individual draft, particularly when the WG that did RFC4287 exists. Certainly in order to update RFC4287 it would *have* to be Proposed Standard. What constitutes an update or change (rather than an optional extension) might be open to some debate. Echoing Tim, I agree there's no problem with James doing an individual draft for now so that everybody can evaluate a specific proposal and suggest what should be done with it. Lisa On Dec 11, 2006, at 11:39 PM, James M Snell wrote: *If* the document proceeds to Proposed Standard, the new RFC would update RFC4287 either by adding a new type param or by deprecating the use of application/atom+xml for atom entry documents in favor of a new media type. No other part of RFC4287 would be affected. Ideally, I would much rather this be a WG draft. I pinged Tim about it the other day and he suggested that I go ahead with a I-D for now and that we can explore whether or not to move forward with it as a WG draft later. - James Mark Nottingham wrote: What would the relationship of that document be to RFC4287? Cheers, On 2006/12/11, at 7:32 PM, James M Snell wrote: The I-D would be an individual draft, not a WG draft. -- Mark Nottingham http://www.mnot.net/
Re: AD Evaluation of draft-ietf-atompub-protocol-11
I guess I'm assuming that one would want clients to be able to extend Atom unilaterally. The choices that I highlighted as problematic make it harder for clients to reliably add extensions to Atom documents. (It remains easy for servers to add extensions to Atom feeds and entries using prescribed mechanisms like adding new elements in custom namespaces. ) Since clients post Atom entries and other clients retrieve them, it seemed reasonable to want to extend Atom client-to-client. If I used AtomFu client that was able to annotate my entries automatically with what music I was listening to (track name, album and artist in XML elements) while I wrote a blog posting, I thought AtomFu should just store that as XML markup in the entry. Other users running AtomFu will see that information and nobody else needs to upgrade -- not servers, not other clients. Eventually if other clients see this as a useful feature they'll make the additional markup visible. Servers probably would never need to upgrade to use or touch that markup. A model where servers aren't required to keep such information won't, in practice, allow that kind of extension. If clients can't rely on their markup getting stored, then clients can't extend Atom unilaterally using XML markup. But implementors of client software are innovative, too. You can't stop them from putting cool information in entries -- they'll just put it in a place where the server decides it's just natural-language or some other component that it does allow the client to create unmodified. So maybe instead of seeing track name, album and artist in XML elements, we'll see them in square brackets or some other format in the blog entry text. This will hurt interoperability to a certain extent, as there is no standard way of extending the machine-parsable information within the *text* of an entry. We won't see this today -- with new protocols, servers typically lead adoption, implementing the protocol before many clients emerge. But in the long run, server deployments get old and yet as long as they're still running, admins avoid changing software or even upgrading. Yet people who've gotten used to the new functionality start expecting more from it and seek out clients that do cool new things and still interoperate with their servers. Bare bones clients are the first generation of a new technology, and innovative (whatever the barriers) clients come much later. 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? thx, Lisa On Dec 15, 2006, at 8:13 AM, Tim Bray wrote: 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?
Re: AD Evaluation of draft-ietf-atompub-protocol-11
Thanks for responding to my review. I look forward to seeing a revised draft. Below I've excerpted the stuff that is still giving me serious problems. On Dec 7, 2006, at 8:36 AM, Joe Gregorio 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. This is the kind of thing that clients come to completely rely on, and then you find some special-purpose server that decides this doesn't fit in its model. Well, the spec doesn't require me to accept link relations which point to other servers. Finger- pointing rather than interoperability. If that's completely unacceptable, the only alternative that would allow good interoperability is to have an error code or feature advertisement that allows the client to detect that the server won't allow this. A generic Forbidden error (or other choice that could be made by the server) is not enough to know what is disallowed and whether it is always disallowed. What did I do wrong? the client plaintively asks. 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. Clients are left with the illusion of flexibility -- it *seems* you can use Atom syntax extensions and do creative things that other extended clients can understand -- but in fact the server can alter this at will leaving the client without any control over what it's really publishing. In many cases, the client won't even want the server to store some stripped version of what it POSTed, because it can really change the meaning of some entry to have the server strip some of the content and markup. Imagine removing the start time and location when I'm trying to publish an event entry to what I believe ought to be a calendar feed. Some server changes to submitted documents is of course going to be allowable (edit dates, server-provided IDs, changes which are effectively XML canonicalization) but I believe these need to be limited. The general case, which is how servers deal with unrecognized elements, needs to be severely limited so that the server can either reject the whole request or store as provided. Lisa
How to do RESTful SEARCH (was Re: Adding POST capability to atom:link)
On Oct 26, 2006, at 1:02 PM, Jan Algermissen wrote:If you aim to provide a REST interface, do not mimick a query interface (at least not a complex one). Think of your 'asset space' in terms of pre-defined, useful collections that you expose as resources (feeds) and provide light weight query interfaces to them that fit with GET requests.Think in terms of browsing and drilling-down; REST interfaces guide the client into the content instead of assuming the knowledge to constructa query does reside in the client.This is an interesting assertion about REST. I don't yet agree with it as stated though I might after further discussion and elaboration. To provide a possible counter-example, I always found the HTTP SEARCH proposal http://www.greenbytes.de/tech/webdav/draft-reschke-webdav-search-latest.html to be RESTful because - The results of a search are returned as a set of resource identifiers - It doesn't necessarily break for dynamic resources as long as the server can handle that - It doesn't break the layering of representations, or use of connectors, or caching of resources - It's general -- can be used for WebDAV resources but also for any HTTP server, CalDAV resources or probably (with some thought) Atom resourcesA server that instead provides light-weight query interfaces as you describe, or guides the client into the content, does not work with a client that doesn't do HTML (a CalDAV, WebDAV or possibly Atom authoring client); correct?Lisa
Re: AD Evaluation of draft-ietf-atompub-protocol-11
On Oct 18, 2006, at 1:04 AM, Sylvain Hellegouarch wrote: My assumption: a client cannot create a media resource without also creating a media link entry. When I POST a media resource to a collection, a media link entry is *always* created. Same here. Lisa what do you mean by creating a media resource manually? If you do not use an APP service to create a media resource then it does not fall into APP to tell how this resource will be accessible. To me it's like it's not even part of the collection. I was assuming the opposite of what James assumed, so under my personal world-view "create a media resource manually" meant to create a media resource without also creating the media link entry at the same time.To illustrate my disconnect more, I'll borrow James Snell's concrete example and show what I thought would obtain instead:On 2006/10/17, at 4:40 PM, James M Snell wrote:My assumption: The relationship between a media link entry and a mediaresource is always 1-to-1. If I want an entry to point to multiplemedia resources, then I would create one media link entry for each mediaresource, then create a separate entry that points to each of theindividually created media resources.e.g., entry1 -- pic1 entry2 -- pic2 entry3 -- pic3 entry4 -- pic1 -- pic2 -- pic3Entries 1, 2 and 3 will always point to their respective media resources(using atom:content/@src).My idea was that if I want to create an entry to point to multiple media resources, I might first create the entry as I edit text about my fabulous trip to Lisbon, entries: entry1Then when I add pictures to the entry I'm editing, my client would "manually" create the media resources by posting to the media collection, such that no media link entry was created for each of them. At the same time, the client would probably PUT to the entry each time to update and add the link to the pictures. entries: entry1 -- pic1 -- pic2 -- pic3 media resources: pic1 pic2 pic3Of course this can be done in fewer steps if the client is implemented to do editing offline and only upload the whole kaboodle when I'm done. In that scenario, entry2 with images pic4 and pic5 would be created with a minimum of POSTs and no PUTs, step 1 is POSTing the images: entries: entry1 -- pic1, pic2, pic3 media resources: pic1, pic2, pic3 NEW pic4 NEW pic5Step 2 is POSTing the entry with the links obtained from creating the images: entries: entry1 -- pic1, pic2, pic3 NEW entry2 -- pic4, pic5 media resources: pic1, pic2, pic3 pic4 pic5I may be wrong about this model and James is likely to be right as having followed the discussion more carefully, but I don't believe the draft clearly leads the reader to James' model. Lisa
Re: AD Evaluation -- extensions
Yes, absolutely, a way to distinguish extensions-to-the-entry from extensions-for-the-feed would be great, even if there's a possibility that the server would reject one or both. I hadn't even considered that, must have missed that discussion. Client-to-client extensions (metadata or markup that the server can safely ignore and pass through from author to feed consumer) seem very likely and useful in Atom, even more so than in other applications I've compared to (calendaring, file sharing, email). I guess I can turn the flexibility argument around: imagine if Web servers in 1995 rejected, just refused to store, anything that wasn't defined in HTML 3.0; the Web never would have been as flexible as it is today. Of course we can't require Web servers or Atom servers to absolutely accept all content, but we can make it clear what the expectation is and perhaps even offer safe ways of violating the expectation. Lisa On Oct 17, 2006, at 4:31 PM, Eric Scheid wrote: On 18/10/06 8:07 AM, Lisa Dusseault [EMAIL PROTECTED] wrote: Extensions When the client puts extension elements in a MER, MUST the server store those unrecognized extension elements? I think the answer to this is actually that servers often do not and should not be required to do so. That makes it hard for clients to extend AtomPub's syntax in ways that other clients will understand but servers don't care about. Consider the consequences: when some enterprising client developer decides to do something cool and useful and encounters servers that don't store their metadata in the obvious place, the client developer is going to quickly work around that by storing in some unobvious place. For example in HTML comments in the atom entry content, or microformats, etc. Is that all cool? This issue also has implications on what extensions are passed through to the published feed ... a client might insert some extension metadata they want published (eg. geo-coordinates), and a client might insert some extension metadata they only want visible within the collection feed (eg. editor workflow comments) ... with the understanding also that if the server actually understands a particular extension it might result in extensions being added/modified outside of the bucket (eg. ext:include trackbacks=yes / resulting in lots of link/ elements being added) We did at one time discuss providing a bucket container specifically for the latter, with the assumption that extensions outside the bucket are data elements meant for publication. Having a bucket container would make life simpler for server implementations -- just store everything as an xml blob, the same as they do for atom:[EMAIL PROTECTED] Lisa, would that help? e.
Re: Atom Syndication Format To Draft Standard?
The Draft Standard requirement for demonstrated interoperability for all features is documented in RFC2026. It's that requirement which leads to the popular conclusion that in many cases, adding a new feature is incompatible with moving to Draft Standard at the same time -- that popular conclusion is part of the folklore, not part of the requirements, which is appropriate. You could draw a different conclusion and argue for that conclusion and might meet with some success, because determining sufficient "demonstrated interoperability" is sometimes going to be a judgement call anyway.LisaOn Oct 2, 2006, at 11:23 AM, Robert Sayre wrote: That's unfortunate. A documented process is a requirement for open standards development, in the opinion of many http://blogs.sun.com/dennisding/resource/Open%20Standard%20Definition.pdf
Fwd: Last Call: 'Atom License Extension' to Experimental RFC (draft-snell-atompub-feed-license)
FYIBegin forwarded message:From: The IESG [EMAIL PROTECTED]Date: August 14, 2006 6:35:53 PM PDTTo: IETF-Announce ietf-announce@ietf.orgSubject: Last Call: 'Atom License Extension' to Experimental RFC (draft-snell-atompub-feed-license) Reply-To: iesg@ietf.org The IESG has received a request from an individual submitter to consider the following document:- 'Atom License Extension ' draft-snell-atompub-feed-license-06.txt as an Experimental RFCThe IESG plans to make a decision in the next few weeks, and solicitsfinal comments on this action. Please send any comments to theiesg@ietf.org or ietf@ietf.org mailing lists by 2006-09-11.The file can be obtained viahttp://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-06.txt___IETF-Announce mailing listIETF-Announce@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
I can't speak for all of the IESG, how closely they reviewed the document and how carefully they considered the appropriateness of the namespace. We don't have rules against such namespace choices. We could argue about whether or not we should have such rules, but the results of that argument would most likely affect future specs. To be clear about Sam's issue, Sam asked about change control for the document, and did not suggest changing the namespace or some other change. He said I want to confirm that we hae sufficient control over this specification that we have change control for the future. We do, so a simple Yes answer was the resolution that addressed Sam's concern. It's too bad if Sam's review raised a point that you would have preferred to consider in Last Call. At this point, it's very rare to pull a document or change something like this that would affect implementations. Often the remedy at this stage is to start working on the next revision of the RFC and/or to make a note to fix in the next revision. So the IETF change control over this document may answer your concern, one way or another, as well. Lisa On Jul 9, 2006, at 9:43 PM, Robert Sayre wrote: On 7/4/06, Lisa Dusseault [EMAIL PROTECTED] wrote: I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Hi Lisa, Thanks for the clarification. You may have missed another question I recently asked, so I'll repeat it here. I am concerned that purl.org lists the document author as the owner of the namespace URI, and I wonder how the IESG came to the conclusion that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
I wrote the synopsis, in which I was careful not to state that it was a WG document. I believe it was accurate for what it said although it's very brief. I discussed explicitly with the IESG during the IESG tele-conference calls that there was some lengthy debate and disagreement over certain mechanisms in the draft. Lisa On Jun 26, 2006, at 7:23 PM, Robert Sayre wrote: On 6/26/06, Robert Sayre [EMAIL PROTECTED] wrote: On 6/26/06, Paul Hoffman [EMAIL PROTECTED] wrote: Your reading might differ from others'. I've read a lot of these, so I know this synopsis differs others. Usually they stuff like WG is OK with this. It's perfectly natural to question and appropriate things that seem out of the ordinary. er, a little steamed here, that's not English. It's perfectly natural to question whether things that seem out of the ordinary are appropriate. Anyway, you don't seem to have accurate answers on the process when it doesn't match the outcome you're looking for. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atompub WG meeting at the Montreal IETF
The deadline for requesting an official BOF is Monday. The IAB and IESG are having a bit of discussion of upcoming BOFs this Thursday, even before the Monday deadline, so it would be good to have an indication of a possible request ASAP :) If an official BOF does not come together, there's always Bar BOFs, or even a mini-BOF (pseudo- BOF?) in the Apps Area meeting which is typically the Monday morning of IETF week. I'm also trying to put together some topics of general interest for the Apps Area open meeting, and there's the HTTP Authentication or anti-Phishing BOF which has already been requested and should be of interest to Atom people. I personally have had a lot of people tell me of interest in Atom extensions but it's hard to tell if there's a real possibility of the work items gelling into a charter. Lisa On May 23, 2006, at 2:31 PM, James M Snell wrote: This sounds good so long as we can get the extensions BOF scheduled the on the same day as the WG meeting. Also, it would be great if we could get together for some face-to-face interop testing before and/or after the WG meeting. - James Paul Hoffman wrote: Greetings again. The Atompub WG will have our first (and maybe last!) face-to-face meeting at the upcoming IETF meeting in Montreal at the beginning of July. The timing of us having our first WG meeting may seem odd, given the fact that we completed the Atom format document long ago, and are making good progress on the publishing protocol. However, there are reasons other than moving documents forwards for WGs to meet. Lisa Dusseault, our Area Director, asked us to have a meeting so that people active in the Atompub WG can have more interaction with the IETF, and vice versa. There is interest in the Atom format from other WGs, and there may be interest in the Atom publishing protocol as well. I propose the following agenda, which should fit well into a one- hour slot: - Intro: 10 mins - Brief overview of protocol status: 10 mins - Use of Atom format in other WGs: 30 mins - draft-saintandre-atompub-notify - Overlap with calendar formats - Overlap with mail Note that we are explicitly *not* going to discuss extensions to the Atom format at this WG meeting because they are not part of the WG charter. Lisa has said that she may help arrange a BoF session on creating a new Working Group for Atom extensions, and having at least a higher-level discussion of what extensions are out there would be appropriate in that BoF. But, to use asterisks again, such discussion is *not* part of the Atompub WG meeting. See http://www.ietf.org/meetings/IETF-66.html for details about the IETF meeting. I will let the WG know when there are preliminary and near-permanent agendas for the meeting. It would be good to meet some of you there! --Paul Hoffman, Director --Internet Mail Consortium
Re: Feed Thread in Last Call
On May 23, 2006, at 12:16 PM, Tim Bray wrote: 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 find this to be a pretty compelling argument. Unless RFC4287 were rewritten (with a time machine, perhaps) to forbid extensions in attributes, extension writers will occasionally put data in attributes, and the libraries will have to deal with this, regardless of how the Thread proposal works. Lisa
Fwd: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
This announcement is for a document that will obsolete RFC3548, which is referenced by a couple APPS area RFCs: XMPP (RFC3920) and Atom Syntax (RFC4287).There are also a few drafts that reference RFC3548 that caught my eye: - draft-ietf-nntpext-base, which is in RFC ED queue - draft-josefsson-sasl-gs2-00 - draft-otis-dkim-options-00 - draft-snell-atompub-author-extensions-00 thanks,LisaBegin forwarded message:From: The IESG [EMAIL PROTECTED]Date: May 18, 2006 7:51:48 AM PDTTo: IETF-Announce ietf-announce@ietf.orgCc: Internet Architecture Board iab@iab.org, RFC Editor rfc-editor@rfc-editor.orgSubject: Protocol Action: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard The IESG has approved the following document:- 'The Base16, Base32, and Base64 Data Encodings ' draft-josefsson-rfc3548bis-04.txt as a Proposed StandardThis document has been reviewed in the IETF but is not the product of anIETF Working Group. The IESG contact person is Ted Hardie.A URL of this Internet-Draft is:http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-04.txtTechnical Summary This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, and use of different encoding alphabets. It obsoletes the descriptions in RFC 3548.Working Group Summary This work is the product of an individual submitter. There were significant IETF Last Call comments, and the draft was updated to respond to them.Protocol Quality This document was reviewed for the IESG by Ted Hardie.___IETF-Announce mailing listIETF-Announce@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Feed Thread in Last Call
On May 18, 2006, at 8:56 AM, Robert Sayre wrote: Look at that giant email. Seems to me that it's a debate taking place for no discernable reason. There's no technical reason for the placement of the attributes, and management has made it clear that any objections are irrelevant. I realize that the placement of the attributes is one choice among many. Sometimes you just have to make a choice and there's no reason beyond it needs to go somewhere. I've been trying to understand if there's a technical problem with the draft's chosen placement of the attributes and the best case I've seen is that that location is technically disallowed by RFC4287, an assertion which is disputed (alas, natural language meanings are often disputed). Am I missing something in the case against the choice of location for the metadata? Thanks, Lisa
Re: Informational vs. standards-track for Atom Threading Extensions
On May 17, 2006, at 7:41 PM, Robert Sayre wrote: On 5/18/06, Lisa Dusseault [EMAIL PROTECTED] wrote: On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? My question has yet to be answered. I answered your question as fully as I could from the information I know, as I reviewed one revision of the draft before agreeing to shepherd the document. I can't tell you why James made any particular change from one draft to another but I don't find that question very relevant to the quality of the final document. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I think this is an excellent standard. If another individual, such as myself, were to submit an individually authored document, it would have to meet the same standard, right? Yes, along with the other considerations I mentioned earlier in that email, about usefulness, adoption and review. I hope that makes the situation clearer! Sure does! Good :) Lisa
Re: Informational vs. standards-track for Atom Threading Extensions
On May 17, 2006, at 10:02 AM, Robert Sayre wrote: Well, you clearly don't think they're important. But then you felt compelled to change them back and got an instant stamp of approval from our AD. What happened there? I read this as implying causality between two events. Those two events happened to be near each other in time but weren't causally related. The changes just before the last revision had no impact on my decision to post an IETF Last Call for moving this proposal onto the standards track. It could not have had an impact because I wasn't so closely tuned into the revisions of this draft that I noticed any particular change -- I just reviewed the version presented to me with the shepherding request. My decision to shepherd this document was because I was asked, read the proposal, and felt it was not obviously too harmful and could be useful. It's customary to ask the advising AD for a WG, to shepherd a document closely related to that WG. My decision to recommend Standards Track was because I saw evidence of multiple independent implementations and even some interoperability testing. I could still recommend Experimental instead of Standards Track if I learned of some possible harm to security/privacy or Internet health, or some deep barrier to interoperability, but I have not yet learned of a high enough risk+severity of such concerns to change my mind there. I would be less likely to recommend Informational status for a document like this which has been implemented and has normative statements intended for implementors (e.g. it's not a requirements document or a design overview). Confusingly, Informational is also used sometimes for documents which do not undergo significant community review (e.g. RFC-Editor submissions) but the 4-week IETF last call, previous postings to this list, and comments of implementors, combine to make this document one that is getting significant community review. I hope that makes the situation clearer! Lisa
Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)
For related work, you could look at the email spam filtering stuff
from SIEVE: http://www.ietf.org/internet-drafts/draft-ietf-sieve-
spamtestbis-02.txt
The similar problem is that many spam libraries already produce some
kind of linear or similar scale of severity/likelihood rating for
emails, much like existing services already provide their own scale
of post rankings. The approach SIEVE took, very roughly, was simply
to tell implementors to find some way to map their implementation's
ranking scheme to a canonical range of numerical values. A SIEVE
implementation might have one algorithm for converting SpamAssassin
rankings to the canonical scale, and a different algorithm for some
different library.
Since spam rankings are intended more for automated filters than for
user display (though clearly the user is sometimes involved in
evaluating the rankings, as when the user creates/edits a mail filter
rule like file all email with a spam rating 5 to spam folder),
the considerations of course could be different from the case of Atom
post rankings.
Lisa
On May 5, 2006, at 7:48 AM, Andreas Sewe wrote:
Having ended up as co-author of the Atom Rank Extensions draft
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-
index-09.txt
I would like to encourage some more discussion on the extension's
features. I would especially like to know whether they are flexible
enough to cope with all the major use cases while being at the same
time
reasonably simple to implement.
The extension should, e.g., be able to cope with most grading
schemes in
use; it needs to be able to describe the set of permissible rank
values
(grades). So we are talking (totally) ordered sets here.
Now the order part is easy; that is what @significance
(=ascending/descending) is for. The hard part is to describe the
underlying set of numbers.
Now the current draft defines two elements, r:value and r:range, for
this purpose. Those two elements can be, however, be collapsed into a
single one, and, with cleverly chosen defaults, defining sets using
this
new r:values element is IMHO as simple, if not simpler, as with the
old
approach. Others might have different opinions, though, which I would
really like to hear about.
At any rate, the proposed change looks basically as follows (Note,
however, that the issue of rounding rank values has intentionally been
left out, since this would only distract from the design issue at
hand.)
The r:scheme Element
Ranking Schemes are defined using the r:scheme element. Each scheme
defines the set of rank values permissible for all r:rank elements
with
the associated scheme.
[...]
The set of rank values defined by an r:scheme element is the union of
the sets of rank values defined by each of its r:values elements.
Note
that those sets may overlap.
The r:values Element
The r:values elements defines a set of rank values, each of which
has to
conform to the XML Schema decimal data type [W3C.REC-
xmlschema-2-20041028].
values = element r:values {
atomCommonAttributes,
attribute minimum { xsd:decimal | unbounded }?,
attribute maximum { xsd:decimal | unbounded }?,
attribute steps { xsd:decimal | continuous }?,
attribute origin { xsd:decimal }?,
undefinedContent
}
The minimum attribute specifies an inclusive lower bound on the
set of
rank values defined by the r:values element. Here, the special
value of
unbounded denotes negative infinity. If not specified, the value of
the minimum attribute is considered to be unbounded.
The maximum attribute specifies an inclusive upper bound on the
set of
rank values defined by the r:values element. Here, the special
value of
unbounded denotes positive infinity. If not specified, the value of
the minimum attribute is considered to be unbounded.
The steps attribute specifies either an increment or has the special
value continuous. If not specified, the value of the steps
attribute is considered to be 0.
The origin element specifies the base from which steps are to be
calculated. If not specified, the value of the origin attribute is
considered to be 0.
If the value of the steps attribute is continuous the set of rank
values defined by the r:values element is
{ x | minimum = x = maximum }.
Otherwise the set of rank values defined by the r:values element is
{ x | minimum = x = maximum,
x = (origin + i * steps) for some integer i }.
The following examples illustrate how different sets of rank values
can
be defined by means of a single r:value element:
!-- The rank value 1 --
r:values origin=1 /
!-- The rank values 1, 2, 3, 4, 5 --
r:values minimum=1 maximum=5 steps=1 /
!-- The rank values 0.0, 0.5, 1.0, 1.5, , 10.0 --
r:values minimum=0.0 maximum=10.0 steps=0.5 /
!-- The rational interval [0, 100] --
r:values minimum=0 maximum=100 steps=continuous /
!-- The integers ..., -2, -1, 0, +1, +2, ... --
r:values steps=1 /
Re: [Fwd: draft-reschke-http-addmember-00]
On Feb 17, 2005, at 4:58 AM, Stefan Eissing wrote: I think What Would Make The World A Better Place is a mechanism that generic clients can discover POST service points where they can persist new entities. There is nothing wrong with POST, it is just that a client cannot discover if and where a server supports that feature. Atom solves this problem by embedding the POST service uri into the feed document. That is fine, but a) has low reusablity for other protocols/applications b) has no usability from the view of a generic client Not only that, the Atom approach makes it very difficult for a client to synchronize a set of items such as a blog in such a way that the blog can be authored offline and synched with both local changes and server changes. It might be possible for a specialized Atom client but certainly not for an out-of-the-box WebDAV client. That's what concerns me for the feature of adding a new resource and letting the server choose a location -- it would be nice for a tool like Sitecopy to still be able to work. I'm using that more and more to get content to and from sites like ietf.webav.org. I think this is what Julian tries to address with ADDMEMBER, since this method will be visible in an OPTIONS response. Alternatively, an OPTIONS reponse could carry an extra Header with the URI of such a POST service. I think ADDMEMBER would be worthwhile if it did have more of an extensibility model and provide the ability to support specialized applications. For example, some calendar servers need to reject non-iCalendar formatted submissions. ADDMEMBER reminds me a lot of MKRESOURCE if it leans in that direction. Lisa
