Re: Atom Over XMPP I-D
In fact, many of us are, as it has been the foundation of the work we have been doing on another project that is somewhat related, but focused on area that is quite a bit different in regards to the primary focus of Atom over XMPP, which I think is GREAT as it showcases quite nicely how a well designed format can be extended to provide additional value-add without breaking the underlying specification that it extends from. Don't mean to sound like I am talking in code words... But will leave additional comments in Sylvains capable hands as one of the editors of the spec I am refering to... :)On 5/19/06, Sylvain Hellegouarch [EMAIL PROTECTED] wrote: Hi Peter,Just noticed your message (we've flooded the list with the FTE draft ;)).I can tell you this is a work that I'm really interested in and I'mlooking forward to your new draft.- Sylvain -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you may have noticed, the Atom Over XMPP I-D expired on February 20 of this year: http://www.xmpp.org/drafts/draft-saintandre-atompub-notify-04.html However, by no means is this I-D abandoned. Since January, the underlying publish-subscribe specification (JEP-0060) used by draft-saintandre-atompub-notify has been under revision within the Jabber Software Foundation's standards process, mainly in order to incorporate feedback based on implementation experience (also to make the specification easier to understand). The revision process is close to completion and the Jabber Council is currently requesting feedback on the revisions: http://mail.jabber.org/pipermail/standards-jig/2006-May/011101.html http://www.jabber.org/jeps/tmp/jep-0060-1.8.html If all goes well, the revised pubsub specification will be approved by the Jabber Council during the week of June 12. At that time (and before the IETF 66 cutoff date of June 26), I will submit a revised version of draft-saintandre-atompub-notify to the Secretariat. Thanks for your interest. Peter - -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEbJ00NF1RSzyt3NURAh/GAJ9Y3bOdSRu8sjL7fQJRyPK2gT8lawCghrPZ oR6vRLed4adw0a6ssgJvO2M= =Bb/z -END PGP SIGNATURE--- M:D/M. David Peterson http://www.xsltblog.com/
Re: Feed Thread in Last Call
On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Am I missing something in the case against the choice of location for the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in implementations who won't parse them. I think I've made that extremely clear. The previous draft addressed my concerns. My current plan is to implement the threading element, but I'll recommend against accepting bug reports on the other aspects of the document, since I think it's an underspecified mess. Kind of silly considering the clear lessons from earlier efforts, but the threading element is good enough. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)
Lisa Dusseault wrote:
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
Thanks for the pointer. I was aware of SIEVE's Filtering Extension but
didn't file it mentally as related to the Atom Rank Extension.
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.
Unfortunately this approach does not suit ranking entries very well; the
only canonical range I can think of being a superset of every
conceivable Ranking Scheme is xsd:decimal. Smaller sets simply won't do.
(While loss of information might be acceptable when classifying spam,
other ranking use cases, e.g., grades, are less tolerant to it.)
Now this would essentially mean dropping the r:scheme element
altogether, leaving only r:rank, which was, IIRC, a simplification
suggested by Robert Sayre some time ago.
But even when dropping r:scheme's capability to define a set of allowed
values having an r:scheme-like element around would still be useful:
- It provides a single place to specify a scheme's @significance
(ascending or descending). Otherwise each and every r:rank element needs
to carry its own @significance -- which is especially pointless since
@significance has not significance (no pun intended) for a single
ranking value; it only ever makes sense for a set of values.
- Furthermore, a scheme can also have a @label attached (e.g. Five
Stars), which might then be used in a UI, complementing r:rank's @label
(e.g. Good). But this issue is really independent of the question
whether r:scheme itself actually has the ability to restrict the
rankings to {1, 2, 3, 4, 5} or not.
To summarize, droppping r:scheme's datatyping capabilities might be
acceptable, but dropping the concepts of Ranking Scheme and Domain is
not. I would, however, like to see datatyping being included as well --
iff we can come up with a solution which can describe all the common
uses cases out there!
Andreas Sewe
Re: Atom Rank Extensions: Feedback on r:value and r:range elements wanted (long)
Andreas Sewe wrote: Lisa Dusseault wrote: 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 Thanks for the pointer. I was aware of SIEVE's Filtering Extension but didn't file it mentally as related to the Atom Rank Extension. Yes, I had reviewed SIEVE's mechanism a while back. In fact, one of the use cases I had originally considered for feed rank is that the r:rank element could be used by syndication intermediaries to express spam rankings for feed entries... e.g. scheme name=tag:example.org,2006:spamtest significance=ascending range minimum=0 maximum=100 step=1 / /scheme rank scheme=tag:example.org,2006:spamtest label=Not Spam0/rank rank scheme=tag:example.org,2006:spamtest label=Might be spam25/rank rank scheme=tag:example.org,2006:spamtest label=Likely spam50/rank rank scheme=tag:example.org,2006:spamtest label=Spam100/rank 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. Unfortunately this approach does not suit ranking entries very well; the only canonical range I can think of being a superset of every conceivable Ranking Scheme is xsd:decimal. Smaller sets simply won't do. (While loss of information might be acceptable when classifying spam, other ranking use cases, e.g., grades, are less tolerant to it.) Right. One of the goals for this work is to allow for as broad of a range of ranking scenarios as possible. No single c18n scheme is capable of covering such a range. [snip] But even when dropping r:scheme's capability to define a set of allowed values having an r:scheme-like element around would still be useful: - It provides a single place to specify a scheme's @significance (ascending or descending). Otherwise each and every r:rank element needs to carry its own @significance -- which is especially pointless since @significance has not significance (no pun intended) for a single ranking value; it only ever makes sense for a set of values. One point that I really do need to make clear in the draft is that ranks can be processed relative to ranking schemes other than what is identified in the rank element's scheme attribute. For instance, going back to the spam example, it is entirely possible that I, as a client, could define a variant of the spamtest ranking scheme that is much more restrictive in range than the generic scheme shown above. scheme name=tag:example.com,2006:myspamtest significance=ascending range minimum=0 maximum=50 step=1 / /scheme The set of entries produced by the processing the spamtest rankings against this scheme would automatically exclude all entries with a spamtest rank greater than 50. [snip] To summarize, droppping r:scheme's datatyping capabilities might be acceptable, but dropping the concepts of Ranking Scheme and Domain is not. I would, however, like to see datatyping being included as well -- iff we can come up with a solution which can describe all the common uses cases out there! +1 - James
Feed thread updates
All,
I am preparing an update to the Feed Thread draft based on the Last-Call
feedback received so far. The intent is to publish an update in time
for the May 26 cut-off date that has been set for the next IETF
face-to-face being held in Montreal in July.
Before sending that draft off, I wanted to run a number of the proposed
changes by the WG and request that folks weigh in on whether or not they
think the changes appropriately address the issues raised in the recent
discussions. If you do not feel the changes appropriately address the
issues, if would be very helpful if you would please either list the
specific issues not addressed or, better yet, propose some alternative
spec text that you think would deal with the issue more appropriately.
First, there is the question over the thr: attributes. To handle these
concerns, I would like to insert the following:
== snip ==
Considerations for using thr:count and thr:when
The thr:count and thr:when attributes provide additional metadata about
a resource linked to an Atom feed or entry using the replies link
relation. The values are intended to make it easier for feed consumers
to display basic contextual information about the thread of discussion
without requiring those consumers to dereference, parse and analyze the
linked resource. That said, there are a number of considerations
implementors need to be aware of.
First, the thr:count and thr:when attributes MUST NOT be considered to
provide completely accurate information about the thread of discussion.
That is, the actual total number of responses contained by the linked
resource MAY differ than the number specified in the thr:count
attribute. Feed publishers SHOULD make an effort to ensure that the
meta is accurate. The non-authoritative nature of external reference
metadata, like the replies link attributes, is discussed in detail in
section 3.3 of the W3C document Tag Finding 12: Authoritative Metadata
xref target=TAG12 /.
Second, the values of the thr:count and thr:when attributes are
volatile. Frequent updates to the value of the attributes, or to any
part of the Atom document, could have a detrimental impact on the
cacheability of Atom documents using the attributes, leading to an
increase in overall bandwidth consumption.
Feed publishers MUST consider a change to the thr:count and thr:when
attributes to be an insignificant update, meaning that the value of
the containing feed, entry or source element's atom:updated element MUST
NOT be affected by a change to the values of either of these attributes.
Lastly, implementors need to be aware that while the Atom specification
xref target=RFC4287 / explicitly allows the link element to contain
arbitrary extensions, the specification does not require that
implementations support such extensions. Specifically, relating to the
use of extensions, Atom does not define any level of mandatory
conformance on the part of feed consumers beyond a requirement that
implementations ignore any extension the implementation does not
understand. As a result, some implementations MAY NOT be capable of
fully utilizing the extensions defined by this or any specification.
== snip ==
Regarding the thr:in-reply-to element, there was a concern raised over
the optionality of the ref and href attributes and a potential for
interop issues. There was also a suggestion that the spec include a
comparison to the in-reply-to header defined by RFC 2822. To address
these concerns, I propose making the following change:
== snip ==
The in-reply-to element is used to indicate that an entry is a
response to another resource. The element MUST contain a ref attribute
identifying the resource that is being responded to.
The element is not unlike the references and in-reply-to email message
headers defined by xref target=RFC2822 /, with the exception that,
unlike those headers, the in-reply-to element is required only to
identify the unique identifier of a single parent resource as opposed to
the listing all of the unique identifiers for each preceding resource in
the thread. If the entry is a response to multiple resources,
additional in-reply-to elements MAY be used.
in-reply-to =
element thr:in-reply-to {
atomCommonAttributes,
ref,
href?,
source?,
type?,
( undefinedContent )
}
ref = attribute ref { atomURI }
href = attribute href { atomURI }
type = attribute type { atomMediaType }
source = attribute source { atomURI }
The ref attribute specifies the persistent, universally unique
identifier of the resource being responded to. The value MUST conform
to the same construction and comparison rules as the value of the
atom:id element. Though the IRI might use a dereferenceable scheme,
processors MUST NOT assume it can be dereferenced.
If the resource being responded to does not have a persistent,
universally unique identifier, the IRI used to retrieve a representation
of the resource MAY be used so long as that IRI
Re: Feed thread updates
I stand corrected... the cut off is *June* 26th, not *May* 26. (thanks Peter). Either way, please take a look at the changes and let me know your thoughts. - James James M Snell wrote: All, I am preparing an update to the Feed Thread draft based on the Last-Call feedback received so far. The intent is to publish an update in time for the May 26 cut-off date that has been set for the next IETF face-to-face being held in Montreal in July.
Re: Feed Thread in Last Call
Robert Sayre wrote: On 5/19/06, Lisa Dusseault [EMAIL PROTECTED] wrote: Am I missing something in the case against the choice of location for the metadata? Yes. That location is going to cause interoperability problems in my implementation, because the draft leaves too much undefined, and in Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. - James
Re: Feed Thread in Last Call
On 5/19/06, James M Snell [EMAIL PROTECTED] wrote: Other than the issue with the Microsoft implementation, which has already been thoroughly discussed, what other interop problems are you anticipating? A clear, non-editorialized, listing of the potential issues and the rationale for each would be most helpful. You've received several of those from me. I suggest you read your old mail, paying close attention to messages that you replied to in under 15 minutes. I have zero confidence that any technical change or compromise is possible from you, and I find interacting with you to be a giant time sink. My new policy will be to explain my problem *once*, and then I will verify that my concerns (if any) have been addressed at some later date when there is a revised document available. If my concerns aren't addressed, I will make a concerted effort to avoid writing or being responsible for maintaining any relevant functionality. -- Robert Sayre
Re: Feed thread updates
Hi James, * James M Snell [EMAIL PROTECTED] [2006-05-19 20:00]: Considerations for using thr:count and thr:when I’d still like thr:when called thr:updated, as it follows the same semantics as atom:updated and its value is of the same type. That is, the actual total number of responses contained by the linked resource MAY differ than the number specified in the thr:count attribute. Feed publishers SHOULD make an effort to ensure that the meta is accurate. This SHOULD seems way too prescriptive. If you keep this sentence at all, I suggest changing to an informal “may want to.” Feed publishers MUST consider a change to the thr:count and thr:when attributes to be an insignificant update, meaning that the value of the containing feed, entry or source element's atom:updated element MUST NOT be affected by a change to the values of either of these attributes. I would clarify this “an insignificant update in terms of RFC 4287”. However, I am not sure what this MUST buys, and more importantly, how it could be enforced. Suggesting SHOULD instead. Lastly, implementors need to be aware that while the Atom specification xref target=RFC4287 / explicitly allows the link element to contain arbitrary extensions, the specification does not require that implementations support such extensions. This concern could be partially addressed by including an element to specify a global reply count for an entry in an atom:entry Metadata element. The cost of such an inclusion is insignificant, and there are benefits for all consumers, including those which can support the namespaced link attributes. I strongly suggest adding such an element. I am willing to draft spec language for it if you want me to. The element is not unlike the references and in-reply-to email message headers defined by xref target=RFC2822 /, with the exception that, unlike those headers, the in-reply-to element is required only to identify the unique identifier of a single parent resource as opposed to the listing all of the unique identifiers for each preceding resource in the thread. If the entry is a response to multiple resources, additional in-reply-to elements MAY be used. This is an inaccurate description of the RFC 2822 headers. Suggest the following: The element is not unlike the references and in-reply-to email message headers defined by xref target=RFC2822 /. However, unlike the in-reply-to header, the in-reply-to element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional in-reply-to elements MAY be used. There is no direct equivalent to the references header, which lists the unique identifiers of each preceding message in a thread. If the resource being responded to does not have a persistent, universally unique identifier, the IRI used to retrieve a representation of the resource MAY be used so long as that IRI could also be used as a valid atom:id value and so long as the href attribute is also specified. It would improve interop if multiple disparate publishers publishing a response to the same resource were led to pick the same identifier, so I suggest changing this MAY to SHOULD. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Feed thread updates
A. Pagaltzis wrote: Hi James, * James M Snell [EMAIL PROTECTED] [2006-05-19 20:00]: Considerations for using thr:count and thr:when I’d still like thr:when called thr:updated, as it follows the same semantics as atom:updated and its value is of the same type. I'm still stewing over this and haven't quite made up my mind on it yet. The only reason I'm not quite comfortable with it is that it just seems confusing have both an atom:updated and a thr:updated. That is, the actual total number of responses contained by the linked resource MAY differ than the number specified in the thr:count attribute. Feed publishers SHOULD make an effort to ensure that the meta is accurate. This SHOULD seems way too prescriptive. If you keep this sentence at all, I suggest changing to an informal “may want to.” may want to is a little too weak for me, but yes, the SHOULD is too much. Let me think about it. If I can't come up with something better, I'll use the may want to suggestion. Feed publishers MUST consider a change to the thr:count and thr:when attributes to be an insignificant update, meaning that the value of the containing feed, entry or source element's atom:updated element MUST NOT be affected by a change to the values of either of these attributes. I would clarify this “an insignificant update in terms of RFC 4287”. However, I am not sure what this MUST buys, and more importantly, how it could be enforced. Suggesting SHOULD instead. Making this a MUST will (hopefully) reduce the likelihood false-updates for clients that don't understand FTE. That is, if I use a client that does not understand FTE and I suddenly see an entry that is marked as updated for no apparent reason, I'm likely to get quite annoyed after a while. (note that I included this after running some tests on a couple of feed readers and discovered that it is indeed quite annoying) Lastly, implementors need to be aware that while the Atom specification xref target=RFC4287 / explicitly allows the link element to contain arbitrary extensions, the specification does not require that implementations support such extensions. This concern could be partially addressed by including an element to specify a global reply count for an entry in an atom:entry Metadata element. The cost of such an inclusion is insignificant, and there are benefits for all consumers, including those which can support the namespaced link attributes. I strongly suggest adding such an element. I am willing to draft spec language for it if you want me to. Yeah, I'm still stewing over this. I've started and stopped writing a section for this about a dozen times over the last couple of days. On the one hand, it makes a lot of sense for the spec to have this. On the other, I could imagine feed reader implementors being quite pissed off that they have to support an element with identical form/function/semantics as slash:comments just so feed publishers can avoid having to declare one additional xml namespace. Also consider that even if FTE declares a thr:count5/thr:count element, most folks are likely going to keep on using slash:comments. (I mean, heck, look at the number of Atom 1.0 feeds that are still using dc:subject to indicate the category!!) The other elements/attributes in FTE don't suffer from this problem because they introduce useful new functionality/semantics while also reducing the number of xml namespaces that need to be declared. I dunno, I guess I'm not really against having the element; I'm just having a hard time getting myself to define it. The element is not unlike the references and in-reply-to email message headers defined by xref target=RFC2822 /, with the exception that, unlike those headers, the in-reply-to element is required only to identify the unique identifier of a single parent resource as opposed to the listing all of the unique identifiers for each preceding resource in the thread. If the entry is a response to multiple resources, additional in-reply-to elements MAY be used. This is an inaccurate description of the RFC 2822 headers. Suggest the following: The element is not unlike the references and in-reply-to email message headers defined by xref target=RFC2822 /. However, unlike the in-reply-to header, the in-reply-to element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional in-reply-to elements MAY be used. There is no direct equivalent to the references header, which lists the unique identifiers of each preceding message in a thread. Yeah, I got to thinking the same thing after I posted the note. Your text is much better. If the resource being responded to does not have a persistent, universally unique identifier, the IRI used to retrieve a representation of the resource MAY be used so long as that IRI could also be used
Re: Feed thread updates
* James M Snell [EMAIL PROTECTED] [2006-05-20 06:40]: A. Pagaltzis wrote: I’d still like thr:when called thr:updated, as it follows the same semantics as atom:updated and its value is of the same type. I'm still stewing over this and haven't quite made up my mind on it yet. The only reason I'm not quite comfortable with it is that it just seems confusing have both an atom:updated and a thr:updated. How so? I honestly can’t follow that. Explain? That is, the actual total number of responses contained by the linked resource MAY differ than the number specified in the thr:count attribute. Feed publishers SHOULD make an effort to ensure that the meta is accurate. This SHOULD seems way too prescriptive. If you keep this sentence at all, I suggest changing to an informal “may want to.” may want to is a little too weak for me, but yes, the SHOULD is too much. Let me think about it. If I can't come up with something better, I'll use the may want to suggestion. Oh wait. I was bewildered because I read it as “Feed aggregators” rather than “Feed publishers.” Sorry! Comment retracted, the SHOULD is perfectly appropriate. Feed publishers MUST consider a change to the thr:count and thr:when attributes to be an insignificant update, meaning that the value of the containing feed, entry or source element's atom:updated element MUST NOT be affected by a change to the values of either of these attributes. I would clarify this “an insignificant update in terms of RFC 4287”. However, I am not sure what this MUST buys, and more importantly, how it could be enforced. Suggesting SHOULD instead. Making this a MUST will (hopefully) reduce the likelihood false-updates for clients that don't understand FTE. That is, if I use a client that does not understand FTE and I suddenly see an entry that is marked as updated for no apparent reason, I'm likely to get quite annoyed after a while. (note that I included this after running some tests on a couple of feed readers and discovered that it is indeed quite annoying) That means it falls into the “compliance cannot reasonably be tested but non-compliance is likely to cause interop problems” bucket, which is exactly when a SHOULD is appropriate. This concern could be partially addressed by including an element to specify a global reply count for an entry in an atom:entry Metadata element. […] I could imagine feed reader implementors being quite pissed off that they have to support an element with identical form/function/semantics as slash:comments just so feed publishers can avoid having to declare one additional xml namespace. I dunno; it seems like a drop in the bucket compared to the rest of the spec, and if they’ve already implemented slash:comments semantics it seems like the effort to support an equivalent element in another extension is minimal. Also consider that even if FTE declares a thr:count5/thr:count element, most folks are likely going to keep on using slash:comments. (I mean, heck, look at the number of Atom 1.0 feeds that are still using dc:subject to indicate the category!!) If they were previously already using it, sure. I’m willing to bet money that next to noone who implemented Atom 1.0 support from scratch is doing that, though. Rather, I’d posit that these are (nearly?) all template-based Atom 0.3 implementations that were upgraded to Atom 1.0 with minimum effort. I believe that those who come to Atom 1.0 with a clean slate benefit from the inclusion of a native atom:category element, and likewise those who come to the FTE with a clean slate will benefit from the inclusion of a native atom:entry Metadata element equivalent to slash:comments. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
