Core — Data Model & Wire Formats

1 · Scope

This document defines the CX1 Core:

• DNS TXT record grammar
• Optional /.well-known/cx.json JSON format
• Validation and canonicalization rules
• Client resolution algorithm

Verification and attestations are defined separately in RFC-02.

2 · Terminology

Term	Definition
Endpoint	A chat address or handle reachable on a given app.
Intent	The purpose of the endpoint (e.g., support, sales).
Entry	One published record describing a single endpoint + intent.

3 · DNS TXT Record

Records are published under _cx.<domain> or _cx.<subdomain>.<domain>.
Each entry MUST be a single TXT value string; multiple DNS character-strings MUST be concatenated per RFC 1035.

_cx.<domain>. IN TXT "v=CX1; app=<app>; id=<identifier>; intent=<intent>[; meta=<k:v[,k:v... ]>]"

3.1 Grammar (ABNF per RFC 5234)

Rule	Definition	Notes
CXTXT	"v=" ver ";" WSP* "app=" app ";" WSP* "id=" id ";" WSP* "intent=" intent [ ";" WSP* "meta=" meta ]	Main record format
ver	"CX1"	Version identifier
app	1*( ALPHA / DIGIT / "-" / "_" )	lowercase RECOMMENDED
id	1*( %x21 / %x23-3A / %x3C-7E )	printable, no DQUOTE/semicolon
intent	stdintent / vendorintent	Standard or vendor intent
stdintent	"support" / "sales" / "info" / "hr" / "legal"	Standard intents
vendorintent	"x-" 1*( ALPHA / DIGIT / "-" / "_" )	Vendor-specific intents
meta	pair *( "," pair )	Metadata key-value pairs
pair	key ":" value	Single metadata pair
key	1*( ALPHA / DIGIT / "-" / "_" )	Metadata key
value	1*( %x21 / %x23-3A / %x3C-7E )	Metadata value

Canonicalization

• Keys MUST be lowercase.
• app tokens MUST be lowercase ASCII.
• id for WhatsApp MUST use E.164 format (+<countrycode><number>).
• URIs MUST be valid per RFC 3986

3.2 Examples

_cx.example.com. IN TXT "v=CX1; app=whatsapp; id=+14155550101; intent=support; meta=hours:10-18,locale:en-IN"
_cx.shop.example.com. IN TXT "v=CX1; app=rcs; id=rcs:example_shop; intent=sales"
_cx.example.com. IN TXT "v=CX1; app=apple; id=abm:yourbrand; intent=info"
_cx.hr.example.com. IN TXT "v=CX1; app=telegram; id=@yourbrand_hr; intent=hr; meta=locale:en-IN|hi-IN"

4 · Well-Known JSON Representation

Domains MAY publish /.well-known/cx.json as an authoritative, machine-readable index.
When both TXT and JSON exist, clients SHOULD merge entries, preferring JSON when fields conflict.

{
  "version": "CX1",
  "authoritative_domain": "example.com",
  "entries": [
    {
      "app": "whatsapp",
      "id": "+14155550101",
      "intent": "support",
      "meta": { "hours": "10-18", "locale": ["en-IN", "hi-IN"] }
    },
    { "app": "rcs", "id": "rcs:example_shop", "intent": "sales" }
  ]
}

JSON Schema (draft 2020-12)

A minimal example for tooling:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "CX1 Record Set",
  "type": "object",
  "required": ["version", "entries"],
  "properties": {
    "version": { "const": "CX1" },
    "entries": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["app", "id", "intent"],
        "properties": {
          "app": { "type": "string" },
          "id": { "type": "string" },
          "intent": { "type": "string" },
          "meta": { "type": "object" }
        }
      }
    }
  }
}

5 · Validation Rules

• TXT MUST parse per ABNF. Unknown keys MUST be ignored.
• App MUST be in the registered token list (Appendix A) or vendor namespace x-*.
• ID MUST follow app-specific rules (E.164 for WhatsApp, URI for others).
• Intent MUST be from registry or vendor x-*.
• Duplicate intents for the same app and domain SHOULD be rejected.
• JSON files MUST serve over HTTPS.

6 · Client Resolution Algorithm

Input:
domain, optional preferred_intents[], locale[], apps_allowlist[]

Process

1. Fetch TXT records from _cx.domain (and subdomains if provided).
2. Optionally fetch /.well-known/cx.json and merge entries.
3. Filter to verified entries when available (see RFC-02).
4. Rank candidates by:
   1. intent match
   2. locale match (exact → prefix)
   3. apps_allowlist
   4. server-provided priority (future)
   5. lexical tie-break on app,id
5. Return top candidate(s) and compose deep link.

7 · Deep Link Conventions (Non-Normative)

App	Deep-Link Format
WhatsApp	https://wa.me/<E164>
RCS	rcs:<handle>
Apple Business Messages	abm:<business-id>
Telegram	https://t.me/<handle>

8 · Security & Privacy Considerations

• DNSSEC RECOMMENDED.
• Short TTLs (≤ 1 hour) encouraged for agility.
• Clients MUST avoid leaking user identifiers in discovery requests.
• JSON fetches MUST use HTTPS.
• Attestations and transparency log are defined in RFC-02.

9 · Operational Guidance

• One entry per endpoint/intent.
• Use subdomains to scope (e.g., _cx.apac.example.com).
• Locales MAY be expressed in meta as BCP 47 tags.
• Vendor extensions MUST use x- prefix.
• Recommended TTL: 3600 seconds.

Appendix A — Token Registries (Provisional)

A.1 Registered Apps

whatsapp, rcs, apple, telegram, line, viber, wechat, signal

A.2 Registered Intents

support, sales, info, hr, legal

Change Log

Version	Date	Notes
0.1	2025-10-06	Initial draft for public review.

---

Feedback: himanshu@edgecx.com