Summary

  • RFC 5333 registers ical-access for CalDAV calendar or free/busy access and ical-sched for scheduling through mailto: and iMIP. The URI produced by ENUM is a typed discovery result, not a grant of authority or a receipt for an application action.
  • DNSSEC may authenticate the NAPTR answer under its validation model. Calendar authentication, resource authorization, mail delivery, object processing, attendee acceptance and operational outcome remain separate evidence.

The lookup ended before the consequential work began

Consider an application that starts with a telephone number. It applies the ENUM procedure, reaches a NAPTR RRset and finds two records. One rewrites to an HTTPS URI that resembles a calendar collection. The other rewrites to a mailto: URI. A dashboard compresses the result into one green statement: “calendar connected.”

Nothing in that statement identifies what was connected. RFC 5333 gives the records distinct enumservices because they expose different operating surfaces. ical-access identifies a place where a client may attempt CalDAV access to calendar or free/busy information. ical-sched identifies an address to which a client may send an iTIP scheduling object using iMIP. Reading a collection and sending a scheduling message are not interchangeable acts.

The difference is a governance boundary, not merely a protocol detail. Access can reveal availability or calendar contents and may permit creation or modification. Scheduling can solicit an action from a recipient without exposing a collection. Each has different credentials, policy, logging, failure modes and privacy implications. A generic calendar_uri column erases the type that determines what the next system is allowed to do.

A public locator is not a public permission

RFC 5333 assumes that ENUM DNS records are available to all inquirers. DNS does not decide which caller deserves which record. That makes the output a public discovery surface even when the application behind the URI is private.

The distinction is easy to miss because the discovered URI looks actionable. An HTTPS URI can be opened. A mail address can receive a message. But syntax and reachability are not authorization. A CalDAV server may require authentication and then evaluate privileges for the specific principal, resource and method. It may permit free/busy queries while denying event bodies, or allow reads while rejecting writes. ENUM carries none of those decisions.

An access-control system should therefore refuse to accept source = ENUM as a privilege source. The useful fields are narrower: the E.164 input, the derived query name, the RRset, its validation status, the enumservice token, the rewritten URI and the time observed. The later service must issue its own authentication and authorization receipts.

The mail door does not become a calendar door

The ical-sched:mailto registration connects ENUM to iMIP, the use of Internet mail to carry iTIP scheduling messages. That endpoint can be appropriate for sending a meeting request. It is not a CalDAV collection and cannot safely be passed to code that expects to enumerate or modify calendar resources.

Nor does a successful mail handoff prove the human outcome. A sending MTA may accept the message. A receiving system may deliver it, quarantine it, rewrite it or reject it later. A calendaring client may parse the iCalendar object, associate it with an attendee, display it, suppress it or treat it as an update to an existing object. The attendee may accept, decline, tentatively respond or never see it. Those are different receipts.

This matters when automated agents schedule on behalf of people. An agent that treats discovery as consent can convert a public routing hint into apparent human authority. The safe rule is monotonic: discovery may enable an attempt; only an authenticated application response may advance state, and only an attendee response may support a claim about attendance.

The access door does not disclose the room behind it

The ical-access:http and ical-access:https registrations identify resources accessed with CalDAV. RFC 4791 provides the application protocol. HTTPS can protect the transport and authenticate the server when its TLS checks succeed. It does not tell a client what it may see after connection.

A calendar URL might resolve and still reject every request. It might expose only free/busy periods, redirect to a login service, require a client certificate, or grant a narrow principal read access without write permission. It may have moved while the DNS record remains unchanged. It may refer to a resource whose owner has changed. Each possibility leaves the ENUM record syntactically valid while changing the operational truth.

Observability must preserve those layers. uri_resolved, tls_authenticated, principal_authenticated, method_authorized, calendar_response_received and object_committed are not synonyms. They should not be calculated from a single Boolean called available.

DNSSEC signs the answer, not the calendar decision

DNS answers can be forged, altered or redirected. DNSSEC matters because a validating resolver can authenticate DNS data through an appropriate chain of trust and surface validation state. That is a strong result within the DNS layer.

It is not a transitive credential for the URI target. A secure NAPTR answer can lead to a service that is unavailable, misconfigured or unwilling to authorize the caller. The server still needs its own identity proof. The caller still needs credentials. The resource still needs an access policy. A scheduling recipient still needs to interpret and act on the message.

Automation should record DNSSEC as secure, insecure, bogus or an equally explicit resolver result, together with the validating context. It should never translate secure into trusted calendar, authorized user or meeting confirmed. Doing so turns one protocol's proof into authority over systems it never evaluated.

Public DNS can reveal a private relationship

RFC 5333 names a privacy cost: a calendaring URI can reveal a person's name, employer or affiliation if those strings appear in the URI. A record may disclose this relationship even when authentication prevents outsiders from reading the calendar itself.

An opaque or anonymous URI reduces the most obvious disclosure. It is still not proof of unlinkability. Repeated DNS queries, stable targets, redirects, TLS names, service logs and later login flows can correlate the opaque identifier. The mapping can also become stale after role changes, number reassignment or service migration.

Privacy review therefore belongs before publication, not after an access incident. Operators should minimise human-readable identity in public URIs, define a rotation and revocation process, measure query exposure, and keep the public locator separate from internal account identifiers. The desired question is not merely “is the calendar protected?” It is “what relationship does discovery itself disclose?”

NAPTR selection is not health checking

NAPTR order and preference help a client select among records. They express selection policy within the record set. They do not report latency, current service health, mailbox acceptance, CalDAV authorization or successful delivery.

A common automation error is to treat the first selected URI as the primary live service and a later record as a proven fallback. If the first target is stale, selection can be correct while the operation fails. If two caches hold different RRset versions, clients can select different targets without either parser violating the standard. If the mail and access records are collapsed, a fallback routine may even cross from one operation type to another.

Selection telemetry should show RRset version or observation time, TTL context, NAPTR order and preference, service token, rewrite result and the independent probe or transaction result. That record permits a reviewer to say where the chain broke without blaming the registry or inferring user impact.

Registration supplies a vocabulary, not a deployment census

The IANA registry makes the service tokens interoperable. It tells implementers what ical-access and ical-sched are intended to mean and which URI schemes belong to them. It does not list which telephone numbers publish the service, which providers implement it, whether a particular record is current, or whether any discovered target is healthy.

Counting a registry row as a deployed endpoint is a category error. Counting a NAPTR record as a successful use is another. A credible inventory needs observation of the record, resolution of the URI, identification of the service and a time-bounded operational test. A credible outcome claim needs the application receipts that follow.

This separation also protects standards governance. A registry can remain stable while deployment rises, falls or changes implementation. The vocabulary should not be rewritten to match a momentary inventory, and an inventory should not borrow certainty from the permanence of the vocabulary.

Build a typed chain rather than a green badge

The minimum useful evidence model starts with the input number and the exact normalization applied. It stores the derived DNS name, resolver, response, DNSSEC state and observation time. For each NAPTR record it stores order, preference, flags, service token, rewrite expression and resulting URI. It then starts a new protocol record for URI resolution and service interaction.

For ical-access, the later record should identify redirects, TLS peer, authenticated principal, CalDAV resource, method, authorization decision, response and any committed state change. For ical-sched, it should identify the iTIP object, message identity, transport handoffs, recipient interpretation and response. Missing stages remain missing. They are not filled from a nearby success.

This design supports both incident review and restraint. A forged DNS answer, expired URI, authorization failure, mail bounce and attendee decline produce different breaks in the chain. The dashboard can be useful without pretending they are the same failure.

What the sources do not establish

The reviewed sources define protocols, registrations, threats and security considerations. They do not show a current public URI leaking a named person's affiliation. They do not show unauthorized calendar access, a forged invitation, a service outage or a provider defect. This Article therefore makes no such allegation.

The absence of a documented current incident is not evidence that every deployment is safe. It is a boundary on what may be claimed. Leaders can still act on the architecture: avoid overbroad inference, collect the missing receipts, minimise public identifiers and test revocation. They should not manufacture an affected party to make the risk sound concrete.

Sources