I am implementing context token support. The specification provides examples: JRS, NYC, URBAN. But it also says "any token matching the syntax is valid."
If I receive @JRS, what do I do with it? The specification says I must accept it. But what does it mean?
It means Jerusalem. The specification says so in the examples table.
The examples are "illustrative, not normative." The specification explicitly disclaims them.
Which Jerusalem?
My grandfather would have asked a different question. Not "what does JRS mean?" but "who is asking, and why do they need to know?"
If you are in Jerusalem, you do not need the token. If you are not in Jerusalem, the token tells you "this observation was made by someone who considers themselves to be in Jerusalem." What more do you need?
But what if two people both use @JRS and mean different things? One means the Old City, another means the suburbs, a third means "according to the minhag Yerushalmi." The token is the same. The meanings diverge.
Should the specification not define these things precisely?
Define them how? By listing every possible meaning of Jerusalem?
Perhaps we need a registry. A central list of tokens and their definitions. Each token would have one meaning. Communities that want to be understood would use the tokens from the registry. Communities that want their own tokens could still have them, but they would be... local. Unregistered. The registry would be the common vocabulary.
There must be organizations that maintain such things. Some kind of authority that assigns identifiers and ensures they do not collide. If we were to establish such an authority, or partner with an existing one—
Who would maintain this registry?
My grandfather used to say: "Two Jews, three opinions." But he also said: "Two Jews in different cities, four time zones."
He meant: when Jews lived in separate communities, they could each have their own practices and never conflict. The baker in Munkács did not need to agree with the baker in Pressburg. They would never meet.
But now we build systems. Systems require agreement. And agreement requires authority. And authority requires—what? A vote? A rabbi? A committee?
My grandfather never finished that thought. I suspect he did not have an answer.
R. Kovacs raises the core difficulty. A registry requires governance. Governance requires authority. But the specification describes observational context—which is inherently local and perspectival. Who has authority over perspective?
If we establish a registry, we create a new problem: who decides what goes in it? If we do not establish a registry, we have the current problem: tokens mean whatever their users intend.
Why is the current situation a problem? The specification says tokens are "opaque identifiers whose meaning is socially understood." This seems correct. @JRS means what the community using it understands it to mean. If you are not part of that community, the token is not for you.
But what if I want to understand? What if I receive a time assertion from another community and wish to interpret it correctly? Without shared definitions, interoperability is impossible.
Is interoperability the goal?
Let us consider what interoperability would require. Two communities use @JRS. For their assertions to be comparable, they must mean the same thing by the token. But the specification says context includes "customary behavior" and "local practice." Two communities may have different customs. If their customs differ, their contexts differ, even if both call it Jerusalem.
A registry cannot solve this. It can only mask it.
Then what do I do when I receive @JRS?
You accept it. You do not reject it. You do not claim to understand it. You record that the assertion was made in a context the sender calls JRS. If you need to know more, you ask the sender.
This is what my grandfather would have done. He would not have demanded a registry. He would have written a letter.
And if the sender is not available?