[PD] OSC strings and Pd symbols

[Roman Haefeli]

Hi all

Nowadays, Pd supports UTF-8 and it's possible to type non-ASCII
characters into a symbol box (or a message box, if you like). This is
generally good thing.
When working with [packOSC],  every symbolic (non-number) element is
treated automagically as a OSC string (unless you create type-forced OSC
messages). This generally is also a good thing.
The OSC specification states that OSC strings must only contain ASCII
characters (which I find a real PITA). As a patch writer, however, I
have no measure to make sure, that only pure ASCII symbols are sent to
[packOSC]. 

Currently, the situation is that [packOSC] happily creates invalid
(according to the specification) OSC strings, but only [unpackOSC]
complains about it when receiving such a string. The error in the
console:

---
unpackOSC: PrintTypeTaggedArgs: Type tag said this arg is a string but it's not!
---

I don't know what the best solution is to deal with that problem.
Strictly sticking to the specification, [packOSC] shouldn't package Pd
symbols containing non-ASCII chars into OSC strings in the first place
or at least it should chop them off.
Another way to deal with it would be to make [packOSC] and [unpackOSC]
both support UTF-8 strings instead of ASCII-only strings. In other
words, those classes would support an 'extended' OSC string type, which
is fully compatible with the 'strict' OSC string type. This also would
remove any constraints put on the kind of Pd symbols that can be used as
OSC strings. 
Some (many/most?) other OSC implemenations are _not_ strict in that they
do not check if the OSC strings only contain ASCII strings. I checked
pyliblo and pyOSC and both allow to transmit deutsche Umlaute in
strings. I don't know if there are also strict implementations.

The current behaviour of [packOSC] and [unpackOSC] is IMHO the least
favorable, in that it still allows to create 'invalid' OSC strings
(possibly causing troubles with strict non-Pd receivers), but complains
about them on reception.

Any thoughts on this are welcome.

Roman