...
Error — hosted OFF responded with TDA code 5 ("Not published, no authorization to permit access filed"):
| Code Block |
|---|
|
{
"systemId": "WIPO_DAS",
"notificationCategory": "available",
"dateTime": "2026-10-19T10:00:00.000Z",
"totalQuantity": 1,
"documentRetrievalRequestStatusBag": [
{
"requestAckId": "USIB20260101010101",
"requestStatusCategory": "failure",
"errorCode": "-6",
"statusMessage": "ACCESS NOT AUTHORIZED"
}
]
} |
TDA/PDX code → what the OSF actually receives in the notification today (OFF on legacy TDA/PDX)
| TDA code | TDA/PDX meaning | errorCode sent | statusMessage sent |
|---|
| 0 / 14 / 15 | Successful / Registered / Updated | 0 | Operation Successful |
| 1 | Application number not found (or withdrawn/missing-field, see 5.1.1) | -7 | APPLICATION NUMBER NOT FOUND — ⚠️ even the "document withdrawn" case ends up with this same generic text |
| 2 | File is not available (security) | -8 | FILE WAS NOT AVAILABLE (REQUESTED APPLICATION EXISTS BUT IS NOT CLEARED FOR DISSEMINATION, e.g. security) |
| 3 | Document(s) not found | -9 | DOCUMENT(S) WAS NOT AVAILABLE (COMPLETE SET OF REQUIRED DOCUMENTS FOR CERTIFIED COPY IS NOT AVAILABLE) |
| 5 | Not published / no authorization | -6 | ACCESS NOT AUTHORIZED |
| 7 | Oversize document, CD will be mailed | (none) | (none — getEDIMessageByTDACode(7) returns undefined, no EDI entry defined) |
| 11 | ACC invalid | -4 | INVALID DATA |
| 12 | Request under processing | (none) | (none — no EDI entry; also flagged obsolete in the code) |
| 16 | ACC and priority date mismatch | -15 | MISMATCH ACCESS CODE AND PRIORITY FILING DATE |
| 17 | Priority date mismatch | -12 | MISMATCH PRIORITY FILING DATE OR ACCESS CODE |
| 18 | ACC mismatch (or missing, reused) | -14 | MISMATCH ACCESS CODE |
| 19 | Priority date not provided | -13 | MISSING PRIORITY FILING DATE |
| -1 | System scheduled downtime | (none) | (none — no EDI entry) |
| -2 | System unavailable (back-end) | (none) | (none — no EDI entry) |
| -6 | XML output processing failure (duplicate doc / already registered) | -1 | DUPLICATE (ENTRY ALREADY EXISTS) |
🆕 What changes once this OFF migrates from TDA/PDX to REST
This EDI-translation step only happens for offices answering over the TDA/PDX protocol:
| Code Block |
|---|
|
if ('tda' == event.respondingProtocol) {
let ediErrorMsg = getEDIMessageByTDACode(parseInt(errorCode));
ediCode = getEDICodeByTDACode(parseInt(errorCode));
data.documentRetrievalRequestStatusBag[0].errorCode = ediCode;
data.documentRetrievalRequestStatusBag[0].statusMessage = ediErrorMsg;
} else {
// REST / remote OFF: passed through AS-IS, no translation at all
data.documentRetrievalRequestStatusBag[0].errorCode = errorCode;
data.documentRetrievalRequestStatusBag[0].statusMessage = errorMessage;
} |
sm-rest-retrieval-service.ts)Once an OFF implements the draft REST interface instead (5.1.1.- Responses from OFF to DAS (TDA/PDX codes)), DAS stops translating anything — whatever errorCode/statusMessage the OFF's own REST endpoint sends is forwarded to the OSF verbatim.
| Today (OFF on TDA/PDX) | After migration (OFF on REST, per the draft) |
|---|
| Translation step | TDA numeric code → EDI numeric code/message, via the fixed lookup table above | None — DAS passes through whatever the OFF sent |
errorCode | Fixed legacy EDI number (e.g. -6) | Whatever the OFF's REST endpoint put in errorCode — the draft types this as a loosely-defined string with no fixed enum. In every example in the draft itself, errorCode is null; only statusMessage actually carries information |
statusMessage | Legacy ALL-CAPS EDI phrase (e.g. "ACCESS NOT AUTHORIZED") | Whatever free text the OFF sent — expected, per the draft, to reuse the same vocabulary DAS itself uses internally (das-status.ts), e.g. "document awaiting security clearance" instead of "ACCESS NOT AUTHORIZED" |
| Consistency guarantee | Strong — DAS controls the translation table, so the vocabulary is fixed and documented above | ⚠️ Weak — since nothing is validated or translated, the OSF only gets whatever text that specific OFF chose to send. Treat statusMessage as advisory/free text, not a stable enum, until the draft defines and enforces a closed vocabulary |
Worked example — TDA code 5 ("Not published, no authorization to permit access filed"): - Today: errorCode: "-6", statusMessage: "ACCESS NOT AUTHORIZED" - After migration (per the 5.1.1 migration table): errorCode: null, statusMessage: "document awaiting security clearance" (the OFF's own choice — no guarantee it matches exactly this text until the vocabulary is formally closed)
Caveats (legacy TDA/PDX translation)
- Lossy translation: because the reverse mapping only keeps a single
defaultReverseMapping per TDA code, distinct real-world situations can collapse into one generic EDI phrase (e.g. TDA 1 for a withdrawn document still produces APPLICATION NUMBER NOT FOUND). - Missing EDI entries:
OPERATION_IN_PROGRESS (oversize 7) and DAS_SYSTEM_ERROR (-1, -2) have no EDI translation registered — the notification fields are simply absent for these. - This only fires for requests answered via the TDA/PDX protocol. If the office responded over plain REST/API instead, DAS forwards the raw
errorMessage/errorCode it received, unmodified (see migration section above). - If the OSF is not registered for push notifications, none of this applies — they must poll instead, see 5.1.3.- Responses from DAS to OSF via GET.
