On 29 Aug 2019, at 4:11, Marc Groeneweg wrote:
So, we have our implementation live! But how can we make sure (if not
ICANN but at least the community) what compliancy means... (e.g. we
return a null when we don't have a value and "" when we have an empty
string value. The mobile app wants "" in all empty situations... Just
an interpretation?).
There are many cases. Let’s try to cover them.
a) the server has no value to send. sends empty string as value
b) the server has no value to send. sends null as value
c) the server has no value to send. do not send the member and its value
c) the server has value to send but because of policy (such as GDRP or
else), the value has to be redacted. In this context, it may want to
tell the user the data was redacted
I’ve seen all a),b),c) and d). I’ve only seen b) on your server,
but that is not the point. let’s try to find the right answer.
As Andy was saying, to me, the server should do c) whenever possible.
However, some members are required by the standard or by policy (icann
profile). Then either we do a) or b).
I guess RFC7483 and RFC7095 are almost silent on what to do. Except for
ADR fields:
For ADR member in jCard, RFC7095 says: « Its equivalent in jCard is a
structured
property value, which is an array containing one element for each
text component, with empty/missing text components represented by
zero-length strings. »
However, some members are redacted and need to be signaled to the user.
Right now, it is pretty bad, as people are sending all kind of strings
in caps letter, in one language (en). Given that it is not normalized, I
can’t find it was redacted and as a client show it nicely. I think we
need to define some normalized attribute to signal it was redacted.
Marc.
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
