{"format":"mailschema-registry/1","types":[{"record":{"slug":"content-review","name":"Content Review","summary":"Request changes or approve a specific revision of content.","category":"Review","status":"Draft","version":"0.1","origin":"MailSchema draft","profile":"Email + authenticated HTTPS (draft)","overview":"A service sends content for review. The recipient can submit feedback or record approval of the revision they received. Editing the draft and sending or publishing it remain separate service operations.","target":"Service-owned content identified by its exact revision.","operations":[{"name":"Request changes","description":"Record feedback on the identified revision."},{"name":"Approve","description":"Record approval of that revision."}],"inputs":"The target revision and, for a change request, review feedback.","results":"Feedback recorded or approval recorded, with the revision identified. Requests without permission or against stale revisions leave the current review decision unchanged.","permissions":"The service checks the caller’s review permission. Editing and any later sending or publication require their own permissions.","humanRoute":"A review page showing the same content and revision.","example":{"title":"Review a campaign draft","steps":["The service emails a review request for revision 3 of a campaign.","A reviewer asks for a timezone to be added to the opening paragraph.","The service records the feedback. An editor prepares revision 4.","The reviewer approves revision 4 and the service records that decision."],"exception":"An approval request for revision 3 is refused once that revision is stale. Approval of revision 4 does not send the campaign."},"references":[{"title":"Schema.org Actions","href":"https://schema.org/docs/actions.html","description":"Candidate vocabulary for describing available operations and their routes."},{"title":"Schema.org ReviewAction","href":"https://schema.org/ReviewAction","description":"Describes an opinion about an object. It is not equivalent to the revision approval in Content Review."}],"openQuestions":["Wire representation and operation identifiers.","Revision references and retry behaviour."],"history":[{"label":"0.1 · Working draft","description":"The MAP draft describes review feedback and revision approval. The browser example illustrates the exchange."}],"definition":{"label":"Read the Content Review definition","href":"/specification/content-review/"},"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]},"digest":"a48411f3372e87f3a5fc74725a9ad85f86dee0cea0b747a96338084c4f1fdd04","href":"/registry/content-review/"},{"record":{"slug":"event-response","name":"Event Response","summary":"Tell an organiser whether an invitee expects to attend.","category":"Calendar","status":"Reuse assessment","version":null,"origin":"MailSchema binding proposal","profile":"Existing calendar standards under review","overview":"An invitation asks the recipient to respond for a specified event. This record examines how agents can use existing calendar protocols and whether a MAP binding would add useful behaviour.","target":"The event identifier, occurrence where applicable, and invitation update sequence.","operations":[{"name":"Accept","description":"Indicate that the invitee expects to attend."},{"name":"Decline","description":"Indicate that the invitee does not expect to attend."},{"name":"Respond tentatively","description":"Record a tentative attendance response."}],"inputs":"The invitation reference and response for the appropriate event or occurrence.","results":"An attendance response recorded for the identified invitation, with updates and cancellations handled by the applicable calendar protocol.","permissions":"The agent needs permission to respond for the invitee. Receiving an invitation alone does not grant that permission.","humanRoute":"The ordinary invitation response in a calendar or service interface.","example":{"title":"Respond to a workshop invitation","steps":["An invitation identifies a workshop and its scheduled time.","The recipient asks their agent to respond tentatively.","The agent uses the supported calendar route and records the response."],"exception":"If the invitation has changed, the client must reconcile the update before replying. It must avoid sending the same response through two different routes."},"references":[{"title":"iCalendar · RFC 5545","href":"https://www.rfc-editor.org/rfc/rfc5545","description":"The calendar object model."},{"title":"iTIP · RFC 5546","href":"https://www.rfc-editor.org/rfc/rfc5546","description":"Scheduling exchanges and invitation responses."},{"title":"iMIP · RFC 6047","href":"https://www.rfc-editor.org/rfc/rfc6047","description":"Calendar exchanges carried by email."},{"title":"Schema.org RsvpAction","href":"https://schema.org/RsvpAction","description":"Related vocabulary for attendance responses."}],"openQuestions":["Whether a MAP binding adds a capability beyond existing calendar protocols.","Updates, recurrence and duplicate response handling.","Any new execution profile; iMIP is not the current MAP HTTPS profile."],"history":[{"label":"Reuse assessment","description":"Existing calendar protocols are the starting point. A MAP binding has not been defined."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]},"digest":"51b2530801aae0005bf79af410be87f59b7d780930a11d4fc41dc60c1e8ee78a","href":"/registry/event-response/"},{"record":{"slug":"information-request","name":"Information Request","summary":"Supply specified information in response to a service’s request.","category":"Information","status":"Proposal","version":null,"origin":"MailSchema editorial proposal","profile":"Under consideration","overview":"A service asks for a defined set of information. The recipient supplies the requested values, and the service reports which response it recorded or which values need attention.","target":"A request identifier and the version of the requested fields.","operations":[{"name":"Submit response","description":"Supply values for the requested fields."},{"name":"Decline","description":"Decline to provide the information. Whether this is recorded by the service or kept local remains open."}],"inputs":"Values for the requested fields. The definition must specify required fields, validation rules and any supported attachments.","results":"A recorded response, rejected values or a request that can no longer be answered. Supplying information does not approve a separate business operation.","permissions":"The client needs permission to disclose the requested information. The service checks that the caller may respond to the request.","humanRoute":"A form with the same questions and validation rules.","example":{"title":"Confirm a company’s contact details","steps":["A directory asks for the company’s support address and website.","An authorised representative supplies the two requested fields.","The directory validates the values and records the response."],"exception":"If the request has expired, the service reports that the response was not recorded. Providing contact details alone does not prove company ownership."},"references":[{"title":"Schema.org AskAction","href":"https://schema.org/AskAction","description":"Related vocabulary for posing a question."},{"title":"Schema.org ReplyAction","href":"https://schema.org/ReplyAction","description":"Related vocabulary for a response."},{"title":"JSON Schema 2020-12","href":"https://json-schema.org/draft/2020-12","description":"A candidate for describing and validating JSON inputs."}],"openQuestions":["Field representation, partial responses and replacement of an earlier response.","Attachments, deadlines and disclosure permissions.","Whether declining a request is a service operation."],"history":[{"label":"Initial proposal","description":"MailSchema is assessing the response model and its relationship to existing vocabularies. No version has been assigned."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]},"digest":"6966ef25e4870decb534cb773caa11f3d2134dbcc628232146269d24e7d015a8","href":"/registry/information-request/"},{"record":{"slug":"subscription-preferences","name":"Subscription Preferences","summary":"Choose which emails a service sends and how often.","category":"Email","status":"Proposal","version":null,"origin":"MailSchema editorial proposal","profile":"Preference interaction under consideration","overview":"A recipient changes the email topics or delivery frequency offered by a service. This proposal concerns email preferences; it does not describe paid subscription management.","target":"The recipient’s subscription with the specified service or list.","operations":[{"name":"Update preferences","description":"Set the offered topic and frequency options."}],"inputs":"The subscription reference and selected values from the settings the service offers.","results":"The recorded settings and when they take effect, or an explanation of why the requested change was not applied.","permissions":"The preference interaction needs permission to update that recipient’s settings. An existing one-click unsubscribe route keeps its own requirements.","humanRoute":"The service’s email preference page, with its unsubscribe option available.","example":{"title":"Switch to a weekly digest","steps":["A service offers immediate product announcements or a weekly digest.","The recipient selects the weekly digest.","The service records that preference and reports when it applies."],"exception":"If the selected frequency is no longer offered, the service reports the problem without silently selecting another option."},"references":[{"title":"One-click unsubscribe · RFC 8058","href":"https://www.rfc-editor.org/rfc/rfc8058","description":"Preserve the existing unsubscribe mechanism. Its POST excludes cookies and HTTP authorization and requires recipient consent."}],"openQuestions":["Available settings, partial updates and when changes take effect.","Identity binding for preference changes.","How clients expose the existing unsubscribe route without adding MAP credential requirements."],"history":[{"label":"Initial proposal","description":"The preference interaction is being scoped around existing email unsubscribe behaviour. No version has been assigned."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]},"digest":"0386907ea6240c57d635de1d78eeb5b0c14336c1ba54932510ab399f12ad0eb9","href":"/registry/subscription-preferences/"},{"record":{"slug":"task-assignment","name":"Task Assignment","summary":"Accept assigned work and report its progress or completion.","category":"Tasks","status":"Reuse assessment","version":null,"origin":"MailSchema binding proposal","profile":"Existing task standards under review","overview":"A service assigns work to a person or agent. The recipient can respond to the assignment and report its state. The proposal examines which existing task semantics can be reused.","target":"A task identifier, its assignment and the applicable update version.","operations":[{"name":"Accept or decline","description":"Respond to the assignment."},{"name":"Report progress","description":"Update the task’s recorded state."},{"name":"Report completion","description":"Provide a completion report. The service may still need to verify the work."}],"inputs":"The assignment reference, response or progress information, and any completion evidence required by the service.","results":"A recorded assignment response or task update. Acceptance of an assignment and verification of its completion are separate states.","permissions":"Accepting a task does not grant access to the resources needed to carry it out. The service and client retain their existing permissions.","humanRoute":"The service’s task interface.","example":{"title":"Check links in a documentation release","steps":["A service assigns an agent to check links in a specified documentation release.","The agent accepts the assignment and performs the permitted checks.","It submits a report and the service records the update."],"exception":"A cancelled or changed assignment needs to be reconciled before a completion report is accepted. Acceptance does not permit editing or publishing the release."},"references":[{"title":"iCalendar · RFC 5545","href":"https://www.rfc-editor.org/rfc/rfc5545","description":"Defines task data through VTODO."},{"title":"iTIP · RFC 5546, section 3.4","href":"https://www.rfc-editor.org/rfc/rfc5546#section-3.4","description":"Defines task responses and completion updates. A proposed MAP binding must identify any remaining gap."}],"openQuestions":["The mapping to existing task semantics and whether a MAP binding is needed.","Completion evidence, cancellation and changes to an accepted assignment."],"history":[{"label":"Reuse assessment","description":"The existing task protocols are being evaluated. No MAP binding or compatibility claim is established."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]},"digest":"a5ba7255b7fd8caac6e803639891e9025a26f6a95c32477a8e0d4bb27ebb9bbb","href":"/registry/task-assignment/"}],"snapshots":[{"digest":"a48411f3372e87f3a5fc74725a9ad85f86dee0cea0b747a96338084c4f1fdd04","record":{"slug":"content-review","name":"Content Review","summary":"Request changes or approve a specific revision of content.","category":"Review","status":"Draft","version":"0.1","origin":"MailSchema draft","profile":"Email + authenticated HTTPS (draft)","overview":"A service sends content for review. The recipient can submit feedback or record approval of the revision they received. Editing the draft and sending or publishing it remain separate service operations.","target":"Service-owned content identified by its exact revision.","operations":[{"name":"Request changes","description":"Record feedback on the identified revision."},{"name":"Approve","description":"Record approval of that revision."}],"inputs":"The target revision and, for a change request, review feedback.","results":"Feedback recorded or approval recorded, with the revision identified. Requests without permission or against stale revisions leave the current review decision unchanged.","permissions":"The service checks the caller’s review permission. Editing and any later sending or publication require their own permissions.","humanRoute":"A review page showing the same content and revision.","example":{"title":"Review a campaign draft","steps":["The service emails a review request for revision 3 of a campaign.","A reviewer asks for a timezone to be added to the opening paragraph.","The service records the feedback. An editor prepares revision 4.","The reviewer approves revision 4 and the service records that decision."],"exception":"An approval request for revision 3 is refused once that revision is stale. Approval of revision 4 does not send the campaign."},"references":[{"title":"Schema.org Actions","href":"https://schema.org/docs/actions.html","description":"Candidate vocabulary for describing available operations and their routes."},{"title":"Schema.org ReviewAction","href":"https://schema.org/ReviewAction","description":"Describes an opinion about an object. It is not equivalent to the revision approval in Content Review."}],"openQuestions":["Wire representation and operation identifiers.","Revision references and retry behaviour."],"history":[{"label":"0.1 · Working draft","description":"The MAP draft describes review feedback and revision approval. The browser example illustrates the exchange."}],"definition":{"label":"Read the Content Review definition","href":"/specification/content-review/"},"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]}},{"digest":"51b2530801aae0005bf79af410be87f59b7d780930a11d4fc41dc60c1e8ee78a","record":{"slug":"event-response","name":"Event Response","summary":"Tell an organiser whether an invitee expects to attend.","category":"Calendar","status":"Reuse assessment","version":null,"origin":"MailSchema binding proposal","profile":"Existing calendar standards under review","overview":"An invitation asks the recipient to respond for a specified event. This record examines how agents can use existing calendar protocols and whether a MAP binding would add useful behaviour.","target":"The event identifier, occurrence where applicable, and invitation update sequence.","operations":[{"name":"Accept","description":"Indicate that the invitee expects to attend."},{"name":"Decline","description":"Indicate that the invitee does not expect to attend."},{"name":"Respond tentatively","description":"Record a tentative attendance response."}],"inputs":"The invitation reference and response for the appropriate event or occurrence.","results":"An attendance response recorded for the identified invitation, with updates and cancellations handled by the applicable calendar protocol.","permissions":"The agent needs permission to respond for the invitee. Receiving an invitation alone does not grant that permission.","humanRoute":"The ordinary invitation response in a calendar or service interface.","example":{"title":"Respond to a workshop invitation","steps":["An invitation identifies a workshop and its scheduled time.","The recipient asks their agent to respond tentatively.","The agent uses the supported calendar route and records the response."],"exception":"If the invitation has changed, the client must reconcile the update before replying. It must avoid sending the same response through two different routes."},"references":[{"title":"iCalendar · RFC 5545","href":"https://www.rfc-editor.org/rfc/rfc5545","description":"The calendar object model."},{"title":"iTIP · RFC 5546","href":"https://www.rfc-editor.org/rfc/rfc5546","description":"Scheduling exchanges and invitation responses."},{"title":"iMIP · RFC 6047","href":"https://www.rfc-editor.org/rfc/rfc6047","description":"Calendar exchanges carried by email."},{"title":"Schema.org RsvpAction","href":"https://schema.org/RsvpAction","description":"Related vocabulary for attendance responses."}],"openQuestions":["Whether a MAP binding adds a capability beyond existing calendar protocols.","Updates, recurrence and duplicate response handling.","Any new execution profile; iMIP is not the current MAP HTTPS profile."],"history":[{"label":"Reuse assessment","description":"Existing calendar protocols are the starting point. A MAP binding has not been defined."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]}},{"digest":"6966ef25e4870decb534cb773caa11f3d2134dbcc628232146269d24e7d015a8","record":{"slug":"information-request","name":"Information Request","summary":"Supply specified information in response to a service’s request.","category":"Information","status":"Proposal","version":null,"origin":"MailSchema editorial proposal","profile":"Under consideration","overview":"A service asks for a defined set of information. The recipient supplies the requested values, and the service reports which response it recorded or which values need attention.","target":"A request identifier and the version of the requested fields.","operations":[{"name":"Submit response","description":"Supply values for the requested fields."},{"name":"Decline","description":"Decline to provide the information. Whether this is recorded by the service or kept local remains open."}],"inputs":"Values for the requested fields. The definition must specify required fields, validation rules and any supported attachments.","results":"A recorded response, rejected values or a request that can no longer be answered. Supplying information does not approve a separate business operation.","permissions":"The client needs permission to disclose the requested information. The service checks that the caller may respond to the request.","humanRoute":"A form with the same questions and validation rules.","example":{"title":"Confirm a company’s contact details","steps":["A directory asks for the company’s support address and website.","An authorised representative supplies the two requested fields.","The directory validates the values and records the response."],"exception":"If the request has expired, the service reports that the response was not recorded. Providing contact details alone does not prove company ownership."},"references":[{"title":"Schema.org AskAction","href":"https://schema.org/AskAction","description":"Related vocabulary for posing a question."},{"title":"Schema.org ReplyAction","href":"https://schema.org/ReplyAction","description":"Related vocabulary for a response."},{"title":"JSON Schema 2020-12","href":"https://json-schema.org/draft/2020-12","description":"A candidate for describing and validating JSON inputs."}],"openQuestions":["Field representation, partial responses and replacement of an earlier response.","Attachments, deadlines and disclosure permissions.","Whether declining a request is a service operation."],"history":[{"label":"Initial proposal","description":"MailSchema is assessing the response model and its relationship to existing vocabularies. No version has been assigned."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]}},{"digest":"0386907ea6240c57d635de1d78eeb5b0c14336c1ba54932510ab399f12ad0eb9","record":{"slug":"subscription-preferences","name":"Subscription Preferences","summary":"Choose which emails a service sends and how often.","category":"Email","status":"Proposal","version":null,"origin":"MailSchema editorial proposal","profile":"Preference interaction under consideration","overview":"A recipient changes the email topics or delivery frequency offered by a service. This proposal concerns email preferences; it does not describe paid subscription management.","target":"The recipient’s subscription with the specified service or list.","operations":[{"name":"Update preferences","description":"Set the offered topic and frequency options."}],"inputs":"The subscription reference and selected values from the settings the service offers.","results":"The recorded settings and when they take effect, or an explanation of why the requested change was not applied.","permissions":"The preference interaction needs permission to update that recipient’s settings. An existing one-click unsubscribe route keeps its own requirements.","humanRoute":"The service’s email preference page, with its unsubscribe option available.","example":{"title":"Switch to a weekly digest","steps":["A service offers immediate product announcements or a weekly digest.","The recipient selects the weekly digest.","The service records that preference and reports when it applies."],"exception":"If the selected frequency is no longer offered, the service reports the problem without silently selecting another option."},"references":[{"title":"One-click unsubscribe · RFC 8058","href":"https://www.rfc-editor.org/rfc/rfc8058","description":"Preserve the existing unsubscribe mechanism. Its POST excludes cookies and HTTP authorization and requires recipient consent."}],"openQuestions":["Available settings, partial updates and when changes take effect.","Identity binding for preference changes.","How clients expose the existing unsubscribe route without adding MAP credential requirements."],"history":[{"label":"Initial proposal","description":"The preference interaction is being scoped around existing email unsubscribe behaviour. No version has been assigned."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]}},{"digest":"a5ba7255b7fd8caac6e803639891e9025a26f6a95c32477a8e0d4bb27ebb9bbb","record":{"slug":"task-assignment","name":"Task Assignment","summary":"Accept assigned work and report its progress or completion.","category":"Tasks","status":"Reuse assessment","version":null,"origin":"MailSchema binding proposal","profile":"Existing task standards under review","overview":"A service assigns work to a person or agent. The recipient can respond to the assignment and report its state. The proposal examines which existing task semantics can be reused.","target":"A task identifier, its assignment and the applicable update version.","operations":[{"name":"Accept or decline","description":"Respond to the assignment."},{"name":"Report progress","description":"Update the task’s recorded state."},{"name":"Report completion","description":"Provide a completion report. The service may still need to verify the work."}],"inputs":"The assignment reference, response or progress information, and any completion evidence required by the service.","results":"A recorded assignment response or task update. Acceptance of an assignment and verification of its completion are separate states.","permissions":"Accepting a task does not grant access to the resources needed to carry it out. The service and client retain their existing permissions.","humanRoute":"The service’s task interface.","example":{"title":"Check links in a documentation release","steps":["A service assigns an agent to check links in a specified documentation release.","The agent accepts the assignment and performs the permitted checks.","It submits a report and the service records the update."],"exception":"A cancelled or changed assignment needs to be reconciled before a completion report is accepted. Acceptance does not permit editing or publishing the release."},"references":[{"title":"iCalendar · RFC 5545","href":"https://www.rfc-editor.org/rfc/rfc5545","description":"Defines task data through VTODO."},{"title":"iTIP · RFC 5546, section 3.4","href":"https://www.rfc-editor.org/rfc/rfc5546#section-3.4","description":"Defines task responses and completion updates. A proposed MAP binding must identify any remaining gap."}],"openQuestions":["The mapping to existing task semantics and whether a MAP binding is needed.","Completion evidence, cancellation and changes to an accepted assignment."],"history":[{"label":"Reuse assessment","description":"The existing task protocols are being evaluated. No MAP binding or compatibility claim is established."}],"contributors":[{"name":"MailSchema"}],"maintainers":[{"name":"MailSchema"}]}}],"contributions":[],"implementations":[]}