Add "newIRI" reason

[agates]

Add "newIRI" reason

The current method of notifying consumers of new RSS feeds for existing podcasts is unreliable due to being stateful and depends upon implementation semantics of HTTP. This causes errors in feed redirection, due to various different implementations, as well as depends upon HTTP for feed delivery.

We can remedy this with Podping by adding a new reason code that notifies consumers when a new feed URL has been published for an existing RSS feed that utilizes The Podcast Namespace and has a defined <podcast:guid>.

To further mitigate abuse, use of this reason SHOULD also check if the existing RSS feed defines both <podcast:podping usesPodping="true"> to indicate the feed utilizes Podping and at least one <podcast:hiveAccount account="..."> to indicate the accounts authorized to post Podpings to for the feed. If provided, the given accounts MUST match the account that posted any given Podping. If, at the time of polling, these do not match in any given Podping or if the feed has usesPodping="false", the given Podping SHOULD be ignored.

Note: This mitigation technique can be used in combination with any Podping, but is specifically called out here due to the possibility of abuse if one were not to check these values. Without this mitigation, anyone could post a redirect to any feed.

The proposed definition of this reason is as follows:

• newIRI -- An indication that a new RSS feed is available for an existing feed with a defined <podcast:guid>. The given <podcast:guid> MUST be present and correlated to the new RSS feed within the Podping message body.

Along with the following proposed language to the overall Podping reasons section of documentation:

Please see <podcast:podping> for means to mitigate abuse.

As well as the following proposed Podping schema change:

{
    "version": "1.1",
    "medium": "<ex: podcast>",
    "reason": "<ex: update>",
    "iris": ["list", "of", "iris", "example"],
    "guids": ["list", "of", "<podcast:guid>s", "00000000-0000-0000-0000-000000000000"],
}

Where version becomes 1.1 and guids is a new optional property of a valid list of RFC 4122 UUIDs (without the URN namespace prefix) that must match in length to iris. The order of guids MUST match the order of iris for sake of correlation.

[brianoflondon]

Great but did you forget newIRIs from the example and have one two many GUIDs?

{
    "version": "1.1",
    "medium": "<ex: podcast>",
    "reason": "<ex: update>",
    "iris": ["list", "of", "iris"],
    "newIRIs": ["list", "of", "new iris"],
    "guids": ["list", "of <podcast:guid>s", "00000000-0000-0000-0000-000000000000"],
}

[agates]

Great but did you forget newIRIs from the example

{
    "version": "1.1",
    "medium": "<ex: podcast>",
    "reason": "<ex: update>",
    "iris": ["list", "of", "iris"],
    "newIRIs": ["list", "of", "new iris"],
    "guids": ["list", "of <podcast:guid>s", "00000000-0000-0000-0000-000000000000"],
}

No, because a Podping payload with the newIRI reason is dedicated only for new IRIs. That would be redundant, no?

and have one two many GUIDs?

Yes 😅