ADML is not really an AOTS deployment but an simple ADML one

[anna.git] / example / diameter / launcher / deployments / adml / HINTS.md

diff --git a/example/diameter/launcher/deployments/adml/HINTS.md b/example/diameter/launcher/deployments/adml/HINTS.md
new file mode 100644 (file)
index 0000000..a9314e3
--- /dev/null
+++ b/example/diameter/launcher/deployments/adml/HINTS.md
@@ -0,0 +1,28 @@
+# ADML hints
+
+## AF-Application-Identifier
+
+Diameter RFC assigned the format 'OctetString' to this AVP although it is almost always intended to be human-readable. 'UTF8String' format could be more appropiate, but probably the intention was to avoid possible limits.
+
+ADML message codec shows readable data when possible using the field 'data'. When this is not possible, the 'hex-data' field will encode the information. The 'OctetString' format is hexadecimal by nature (string of octets), then always 'hex-data' will be shown for this kind of AVPs.
+
+For example:
+<avp name="AF-Application-Identifier" hex-data="75726e25334175726e2d787878253341336770702d736572766963652e696d732e696373692e6d6d74656c"/>
+
+You could decode using hex dump utility: 'xxd'
+
+$> echo "75726e25334175726e2d787878253341336770702d736572766963652e696d732e696373692e6d6d74656c" | xxd -p -r
+$> urn%3Aurn-xxx%3A3gpp-service.ims.icsi.mmtel
+
+But the thing that you may probably need, is to encode a desired value into xml messages while designing a test case. For this situation, use the opossite (drop reverse flag '-r' to xxd):
+
+$> echo -n "urn%3Aurn-xxx%3A3gpp-service.ims.icsi.mmtel" | xxd -p | tr -d '\n'
+$> 75726e25334175726e2d787878253341336770702d736572766963652e696d732e696373692e6d6d74656c
+
+or use 'od' (files dump) utility:
+
+$> echo -n "urn%3Aurn-xxx%3A3gpp-service.ims.icsi.mmtel" | od -A n -t x1 | tr -d ' ' | tr -d '\n'
+$> 75726e25334175726e2d787878253341336770702d736572766963652e696d732e696373692e6d6d74656c
+
+The '-n' in the echo is neccessary to avoid encoding of carriage return (0x0a) for the string provided.
+