Podping currently only serves to notify consumers of changes in Podcasting 2.0 RSS feeds. If a change is made to an external file referenced from an RSS feed, we currently have no way to notify consumers of such a change (beyond mechanisms built into HTTP, which don't translate to other protocols).
If we want to solve this the most straightforward solution would be to include a list of strings of external resources changed in a given feed. The problem with this is we only have so much space available to us and there's really no need to reference the external resources directly in Podping.
Therefore, we can remedy this with Podping by adding a new reason code that notifies consumers when an existing RSS feed that utilizes The Podcast Namespace and has a defined <podcast:guid> along with a list of digests of the resources that have been changed.
The digest provided does not need to be secure and should be as small as possible. I am leaning toward CRC32 as it is small and fast. CRC16 is another possibility if we determine it's unique enough and can decide on a specific implementation.
The proposed definition of this reason is as follows:
updateExt -- An indication that an existing RSS feed with a defined <podcast:guid> has changed externally available resources. The given <podcast:guid> MUST be present within the RSS feed.
As well as the following proposed Podping schema change:
Where version becomes 2.0 and crcs is a new optional property of a valid list of lists of CRC numbers that must match in length to guids. The order of crcs MUST match the order of guids for sake of correlation. When the reason is updateExt, iris becomes optional and SHOULD NOT be set for the sake of efficiency. The CRCs are digests of the identifiers of the resources, not the resources themselves.
The logic behind iris becoming optional for the updateExt reason is external resources can only ever be updated if the feed already exists.
Add "updateExt" reason
Podping currently only serves to notify consumers of changes in Podcasting 2.0 RSS feeds. If a change is made to an external file referenced from an RSS feed, we currently have no way to notify consumers of such a change (beyond mechanisms built into HTTP, which don't translate to other protocols).
If we want to solve this the most straightforward solution would be to include a list of strings of external resources changed in a given feed. The problem with this is we only have so much space available to us and there's really no need to reference the external resources directly in Podping.
Therefore, we can remedy this with Podping by adding a new reason code that notifies consumers when an existing RSS feed that utilizes The Podcast Namespace and has a defined
<podcast:guid>along with a list of digests of the resources that have been changed.The digest provided does not need to be secure and should be as small as possible. I am leaning toward CRC32 as it is small and fast. CRC16 is another possibility if we determine it's unique enough and can decide on a specific implementation.
The CRC is of the resource URI/IRI, not the resource content. For example, the CRC32 of the string "https://noagendaassets.com/enc/1601061118.678_pciavatar.jpg" is 3756971431.
The proposed definition of this reason is as follows:
updateExt-- An indication that an existing RSS feed with a defined<podcast:guid>has changed externally available resources. The given<podcast:guid>MUST be present within the RSS feed.As well as the following proposed Podping schema change:
Where
versionbecomes2.0andcrcsis a new optional property of a valid list of lists of CRC numbers that must match in length toguids. The order ofcrcsMUST match the order ofguidsfor sake of correlation. When thereasonisupdateExt,irisbecomes optional and SHOULD NOT be set for the sake of efficiency. The CRCs are digests of the identifiers of the resources, not the resources themselves.The logic behind
irisbecoming optional for theupdateExtreason is external resources can only ever be updated if the feed already exists.