Subject: [apps-discuss] (no subject)

From: Yves Lafon <[email-masked]>
Date: Mon, 6 Feb 2012 15:51:29 -0500 (EST)

Dear all,

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Document: draft-snell-atompub-tombstones-14
Title: The Atom "deleted-entry" Element
Reviewer: Yves Lafon
Review Date: 6 Feb 2012

Summary: This draft is almost ready for publication as Informational RFC, 
there is a minor issue with the ref. section, and a clarification request 
on a MUST-level requirement that is non-blocking.

First, the clarification request: I noted that in 3/ "The at:deleted-entry 
element"

It says:
<<
    An Atom feed MAY contain any number of at:deleted-entry elements, but
    MUST NOT contain more than one with the same combination of ref and
    when attribute values.
then later
<<
    Implementors should note that the at:deleted-entry element is
    informative in nature only and may be ignored by Atom processors.
    The presence of an at:deleted-entry element does not guarantee that
    the atom:entry to which it is referring will no longer be available.

If it is informative only, why in the first paragraph there is a MUST NOT 
on duplicate at:deleted-entry with same 'ref' and 'when', especially as 
two delete may happen in the same second while being different.
What is the rationale for having a MUST NOT instead of a SHOULD NOT?

-- 

In the reference section, the link to XML is to the third edition while 
the fifth edition was published in 2008 [1], for namespaces in XML, it is 
to the first edition while the third edition [2] was published in 2009, 
and for XML base, the first edition instead of the second edition [3].
Was that done on purpose (and then why?) or should the ref section be 
updated?

Cheers,

[1] <http://www.w3.org/TR/2008/REC-xml-20081126/>
[2] <http://www.w3.org/TR/2009/REC-xml-names-20091208/>
[3] <http://www.w3.org/TR/2009/REC-xmlbase-20090128/>

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Yves Lafon <[email-masked]>
Date: Tue, 7 Feb 2012 03:46:46 -0500 (EST)

On Mon, 6 Feb 2012, Yves Lafon wrote:

It's always better with a proper subject line :)

> Dear all,
>
> I have been selected as the Applications Area Directorate reviewer for this 
> draft (for background on appsdir, please see 
> there is a minor issue with the ref. section, and a clarification request on 
> a MUST-level requirement that is non-blocking.
>
> If it is informative only, why in the first paragraph there is a MUST NOT on 
> duplicate at:deleted-entry with same 'ref' and 'when', especially as two 
> delete may happen in the same second while being different.

         ~~Yves

---

From: James M Snell <[email-masked]>
Date: Tue, 7 Feb 2012 15:46:11 -0800

Yves Lafon <[email-masked]> wrote on 02/07/2012 12:46:46 AM:

[snip]
>
> Review of draft-snell-atompub-tombstones-14
>

Yes, quite... my spam filter flagged the first one because of the lack of a
subject line ;-)

>
> > Dear all,
> >
> > I have been selected as the Applications Area Directorate reviewerfor
this
> > What is the rationale for having a MUST NOT instead of a SHOULD NOT?

While SHOULD NOT would likely work here, the motivation for the MUST NOT is
that I was unable to find any valid cases where multiple deleted-entry
elements for the same entry at the same time would appear in a single feed.
If such duplication did occur, it is either certainly an error or a
possible attack vector.

The Informative nature is purely a recognition that, as an extension to
Atom, there mere presence of the deleted-entry element in a field does not
guarantee that Atom implementations will be able to actually do anything
with it.