You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per RFC 6350#6.3.1, in the LABEL parameter on the ADR property, "[n]ewlines are encoded as \n, as they are for property values."
Consequently, upon parsing, \n should be decoded to newline characters. This is currently not the case.
Example (from the RFC):
ADR;GEO="geo:12.3457,78.910";LABEL="Mr. John Q. Public, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
Because of the updating RFC 6868, I believe that for encoding, ^n must be used in place of \n (as is currently the case). However, I believe that \n should still be decoded to a newline character--if strict adherence to the RFCs is desired.
On the other hand, I think RFC 6350 is somewhat broken in this case. It is open to speculation whether, as with property values, \N and \\ (and possibly others) are also special encodings. If not, it is impossible to encode a literal \n.
The text was updated successfully, but these errors were encountered:
Per RFC 6350#6.3.1, in the
LABEL
parameter on theADR
property, "[n]ewlines are encoded as\n
, as they are for property values."Consequently, upon parsing,
\n
should be decoded to newline characters. This is currently not the case.Example (from the RFC):
Because of the updating RFC 6868, I believe that for encoding,
^n
must be used in place of\n
(as is currently the case). However, I believe that\n
should still be decoded to a newline character--if strict adherence to the RFCs is desired.On the other hand, I think RFC 6350 is somewhat broken in this case. It is open to speculation whether, as with property values,
\N
and\\
(and possibly others) are also special encodings. If not, it is impossible to encode a literal\n
.The text was updated successfully, but these errors were encountered: