Subject: [cuss] Fwd: I-D Action:draft-johnston-cuss-sip-uui-01.txt

From: Alan Johnston <[email-masked]>
Date: Tue, 14 Dec 2010 01:02:40 -0600

FYI

---------- Forwarded message ----------
From: <[email-masked]>
Date: Tue, Dec 14, 2010 at 12:45 AM
Subject: I-D Action:draft-johnston-cuss-sip-uui-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : A Mechanism for Transporting User to User Call
Control Information in SIP
       Author(s)       : A. Johnston, et al.
       Filename        : draft-johnston-cuss-sip-uui-01.txt
       Pages           : 12
       Date            : 2010-12-13

There is a need for applications using SIP to exchange User to User
Information (UUI) data during session establishment.  This
information, known as call control UUI, is a small piece of data
inserted by an application initiating the session, and utilized by an
application accepting the session.  This data is opaque to SIP and
its function is unrelated to any basic SIP function.  Several
approaches to transporting call control UUI in SIP have been
proposed.  As networks move to SIP it is important that applications
requiring this data can continue to function in SIP networks as well
as the ability to interwork with this ISDN service for end-to-end
transparency.  This document discusses three mechanisms to meet the
requirements defined in the Requirements for SIP Call Control UUI
document.  A new SIP header field which bests meets these
requirements is proposed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-johnston-cuss-sip-uui-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Alan Johnston <[email-masked]>
Date: Tue, 14 Dec 2010 08:07:50 -0600

Here are the major updates to the proposed mechanism draft:

- Added a Section on Discovery Mechanisms relating to REQ-8 and REQ-10
using a SIP option tag and feature tags for applications/usages
- Rewrote the requirements analysis of each of the three mechanisms,
as the previous text was out of date.  This includes the new security
requirements
- Added text outlining how a History-Info extension could help the
header field mechanism meet REQ-12.
- Rewrote Security Considerations section

In addition, we accidentally dropped the IA5 encoding - it will be
added back in the next version.  The details in Section 5 have not
been updated as I have been concentrating on the earlier sections for
now. I believe there is enough detail there for the working group to
understand the direction of the proposed header field - we can refine
them going forward.

Comments and feedback are most welcome.  Looking forward to next
week's interim discussions...

- Alan -

On Tue, Dec 14, 2010 at 1:02 AM, Alan Johnston
<[email-masked]> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>        Title           : A Mechanism for Transporting User to User Call Control Information in SIP

---

From: Laura Liess <[email-masked]>
Date: Fri, 17 Dec 2010 17:19:05 +0100

Hi,

I read the new version of the UUI draft and it seems to me that the
added text clarifies most major issues raised. Among others, it makes
more clear the intention for UUI, which requirements can be fulfilled
for each of the possible solutions and how the discovery mechanism
could work.

I think it would make a good starting point for a WG item.

Thanks
Laura

2010/12/14 Alan Johnston <[email-masked]>:
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 Dec 2010 15:17:09 +0100

Hi All,

I have read the latest update to this cuss mechanism draft and believe it is going in the right direction.

The recommendation to define a new SIP header is in my opinion the right approach.

Regards
Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: 14 December 2010 14:08
To: [email-masked]
Subject: Re: [cuss] I-D Action:draft-johnston-cuss-sip-uui-01.txt

- Alan -

---

From: <[email-masked]>
Date: Tue, 21 Dec 2010 11:26:37 +0100

Hi Alan,

I've read the latest version of the draft and I fully agree with Andrew's opinion.

Regards
Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von Hutton, Andrew
> Gesendet: Montag, 20. Dezember 2010 15:17
> An: Alan Johnston; [email-masked]
> Betreff: Re: [cuss] I-D Action:draft-johnston-cuss-sip-uui-01.txt
>
> Hi All,
>
> I have read the latest update to this cuss mechanism draft
> and believe it is going in the right direction.
>
> - Added a Section on Discovery Mechanisms relating to REQ-8
> and REQ-10 using a SIP option tag and feature tags for
> applications/usages
> - Rewrote the requirements analysis of each of the three
> mechanisms, as the previous text was out of date.  This
> includes the new security requirements
> - Added text outlining how a History-Info extension could
> help the header field mechanism meet REQ-12.
> In addition, we accidentally dropped the IA5 encoding - it
> will be added back in the next version.  The details in
> Section 5 have not been updated as I have been concentrating
> on the earlier sections for now. I believe there is enough
> detail there for the working group to understand the
> direction of the proposed header field - we can refine them
> going forward.
>
> Comments and feedback are most welcome.  Looking forward to
> next week's interim discussions...
>
> - Alan -
>
> > application accepting the session.  This data is opaque to
> SIP and its
> > function is unrelated to any basic SIP function.  Several
> approaches
> > to transporting call control UUI in SIP have been proposed.  As
> > networks move to SIP it is important that applications
> requiring this
> > data can continue to function in SIP networks as well as
> the ability
> > to interwork with this ISDN service for end-to-end
> transparency.  This
> > document discusses three mechanisms to meet the
> requirements defined
> > in the Requirements for SIP Call Control UUI document.  A new SIP
> > header field which bests meets these requirements is proposed.
> >
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >

---

From: Leon Portman <[email-masked]>
Date: Tue, 21 Dec 2010 13:22:03 +0200

+1 

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 21, 2010 12:27 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [cuss] I-D Action:draft-johnston-cuss-sip-uui-01.txt

Hi Alan,

Regards
Martin

---

From: James Rafferty <[email-masked]>
Date: Tue, 21 Dec 2010 09:06:50 -0500

Alan, 

The latest draft looks good.  I agree that we need to add the IA5 encoding back in to be consistent with some of the usages we are seeing in customer deployments.  

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Tuesday, December 14, 2010 9:08 AM
To: [email-masked]
Subject: Re: [cuss] I-D Action:draft-johnston-cuss-sip-uui-01.txt

- Alan -

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Dec 2010 15:55:43 +0100

Before we do that, can I ask what the function of the encoding is? Does it specify something that occurs at the SIP protocol layer, or something at the application?

One thing we need to watch with this is that the ISDN working may be one or other, and that is specified by values of the protocol discriminator octet, which comes after this. 

Keith 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of James Rafferty
> Sent: Tuesday, December 21, 2010 2:07 PM
> To: Alan Johnston; [email-masked]
> The latest draft looks good.  I agree that we need to add the 
> IA5 encoding back in to be consistent with some of the usages 
> we are seeing in customer deployments.  
> 
> James
>

---

From: James Rafferty <[email-masked]>
Date: Tue, 21 Dec 2010 21:50:48 -0500

Keith, my view is that the IA5 is simply an alternate encoding that can be specified by the enc-param.  

Its use would tend to be driven by the application.  

James

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2010 9:56 AM
To: James Rafferty; Alan Johnston; [email-masked]
Subject: RE: [cuss] I-D Action:draft-johnston-cuss-sip-uui-01.txt

Keith 

> Behalf Of Alan Johnston

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Dec 2010 13:10:20 +0100

Well I'm looking at it from the perspective of the no. 1 application (as in at least first), which is the ISDN one. The protocol discriminator (i.e. the first octet of the ISDN payload) describes specifically an IA5 encoding as one value, and has other values that are not IA5. I suspect the IA5 one is the one that is most used.

Now I do not think we should force an incoming ISDN gateway to look at the payload part to decide how to encode the SIP part of this. Thus the ISDN application should ideally always use the same value, particularly if that usage has zero impact on SIP functionality.

Your reply seems to indicate that you regard the coding has zero impact on the SIP level of functionality, therefore my suggestion would be that the ISDN application would always use the binary value, and we make sure that the semantics of that codepoint do encapsulate that.

But I would also ask whether, if the encoding is specific to the application identifier, why doesn't the application identifier subsume that semantic, i.e. if I use application value X, then that automatically means IA5 encoding. So without further discussion of the use cases, I have a strong doubt as to whether we need a value at all.

regards

Keith

> From: James Rafferty [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2010 2:51 AM
> To: DRAGE, Keith (Keith); Alan Johnston; [email-masked]
> Keith, my view is that the IA5 is simply an alternate 
> encoding that can be specified by the enc-param.  
> 
> Before we do that, can I ask what the function of the 
> encoding is? Does it specify something that occurs at the SIP 
> protocol layer, or something at the application?
> 
> One thing we need to watch with this is that the ISDN working 
> may be one or other, and that is specified by values of the 
> protocol discriminator octet, which comes after this. 
> 
> Keith 
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of James Rafferty
> > IA5 encoding back in to be consistent with some of the 
> usages we are 
> > seeing in customer deployments.
> > 
> > James
> > 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Alan Johnston
> and REQ-10 
> mechanisms, 
> > >        Title           : A Mechanism for Transporting 
> User to User 
> > > Call Control Information in SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Dec 2010 10:24:58 -0500

IMO the encoding is independent of whether this is going to/from the 
ISDN or not. The encoding simply gives different ways to represent the 
same set of bits. IA5 can be used if all the bits you want to include 
happen to have an IA5 encoding. The hex encoding can be used for any set 
of bits, but isn't as readable for things that have a natural IA5 encoding.

IA5 happens to work better for some of the ISDN protocol discriminators 
than others. And it would be annoying if your ISDN value was all IA5 but 
the protocol discriminator was not, so that you had to use hex so you 
could embed the protocol discriminator in the value.

My thinking is that the ISDN protocol discriminator ought to be used to 
select the "application" - in principle there would then be up to 256 
potential "ISDN applications". (Though in practice they probably aren't 
all used. Then it wouldn't be in the "value" in sip.

	Thanks,
	Paul

The

On 12/22/2010 7:10 AM, DRAGE, Keith (Keith) wrote:
>>>> From:<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Dec 2010 16:41:36 +0100

I don't think you've answered the point.

Consider an ISDN to SIP gateway. I receive UUI. It happens to have a protocol discriminator that may be understood to be IA5 encoding. 

With such interworking, which encoding value should I use in the SIP world, and why? 

Does that decision introduce an undesirable inspection of the protocol discriminator at the gateway, and if so, is that justified?

At one point in your mail you imply readability is an advantage. Why should I be able to read the application carried by SIP?

Note that nothing in the ISDN standards requires the actual contents to correspond to the protocol discriminator, and nothing in the ISDN checks that the contents actually do. ISDN allows a binary contents - the main constraint being length.

regards

Keith

> Behalf Of Paul Kyzivat
> Sent: Wednesday, December 22, 2010 3:25 PM
> To: [email-masked]
> IMO the encoding is independent of whether this is going 
> to/from the ISDN or not. The encoding simply gives different 
> ways to represent the same set of bits. IA5 can be used if 
> all the bits you want to include happen to have an IA5 
> encoding. The hex encoding can be used for any set of bits, 
> but isn't as readable for things that have a natural IA5 encoding.
> 
> IA5 happens to work better for some of the ISDN protocol 
> discriminators than others. And it would be annoying if your 
> ISDN value was all IA5 but the protocol discriminator was 
> not, so that you had to use hex so you could embed the 
> protocol discriminator in the value.
> 
> My thinking is that the ISDN protocol discriminator ought to 
> be used to select the "application" - in principle there 
> would then be up to 256 potential "ISDN applications". 
> (Though in practice they probably aren't all used. Then it 
> wouldn't be in the "value" in sip.
> 
> 	Thanks,
> 	Paul
> 
> The
> 
> > Well I'm looking at it from the perspective of the no. 1 
> application (as in at least first), which is the ISDN one. 
> The protocol discriminator (i.e. the first octet of the ISDN 
> payload) describes specifically an IA5 encoding as one value, 
> and has other values that are not IA5. I suspect the IA5 one 
> is the one that is most used.
> >
> > Now I do not think we should force an incoming ISDN gateway 
> to look at the payload part to decide how to encode the SIP 
> part of this. Thus the ISDN application should ideally always 
> use the same value, particularly if that usage has zero 
> impact on SIP functionality.
> >
> > Your reply seems to indicate that you regard the coding has 
> zero impact on the SIP level of functionality, therefore my 
> suggestion would be that the ISDN application would always 
> use the binary value, and we make sure that the semantics of 
> that codepoint do encapsulate that.
> >
> > But I would also ask whether, if the encoding is specific 
> to the application identifier, why doesn't the application 
> identifier subsume that semantic, i.e. if I use application 
> value X, then that automatically means IA5 encoding. So 
> without further discussion of the use cases, I have a strong 
> doubt as to whether we need a value at all.
> >
> > regards
> >
> > Keith
> >
> >
> >
> >> Before we do that, can I ask what the function of the encoding is? 
> >> Does it specify something that occurs at the SIP protocol 
> layer, or 
> >> something at the application?
> >>
> >> One thing we need to watch with this is that the ISDN 
> working may be 
> >> one or other, and that is specified by values of the protocol 
> >> discriminator octet, which comes after this.
> >>
> >> Keith
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Dec 2010 11:00:04 -0500

IMO the sender should have free choice to use any encoding that is 
capable of representing the bits.

Using IA5 has some advantages:
- its generally more compact than hex
- it may be easier to construct than hex if the nature
   of the content is known
- its more easily read by someone looking at the message

This doesn't make processing any easier for the recipient, who must be 
prepared for any of them. But the advantages others remain.

Readability is probably not the major benefit, but it can still be 
appreciated by those who have to scrutinize raw logs.

An ISDN GW, when *sending* UUI, might choose to always encode in hex 
because that can be certain of working regardless of the value. Or it 
might choose to do analysis to see if IA5 can be used in order to save 
bytes in the message, or to enhance readability. But that is an 
implementation choice.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 22 Dec 2010 10:07:39 -0600

Keith's point is an excellent one, and we need to be very clear about
the answer.

The encoding we specify in the SIP mechanism should be the encoding
done by the SIP layer.  The SIP layer will be given a blob of data,
which should be treated as an octet string, and the SIP layer then
encodes it per the encoding specified.

In the case of ISDN, the raw blob of information might, in addition,
be encoded in some other way internally - perhaps in IA5?  However,
this is not the encoding at the SIP layer.  We do not want ISDN
gateways to have to decode and re-encode UUI received from ISDN - we
just want them to encapsulate it and forward it.

For non-ISDN uses, there might be multiple encoding options for a
given piece of application data, although there must be a default
encoding defined.  I believe the mechanism draft currently has some
wording to this effect.

Does this make sense?

- Alan -

On Wed, Dec 22, 2010 at 10:00 AM, Paul Kyzivat <[email-masked]> wrote:
> IMO the sender should have free choice to use any encoding that is capable
> of representing the bits.
>
> An ISDN GW, when *sending* UUI, might choose to always encode in hex because
> that can be certain of working regardless of the value. Or it might choose
> to do analysis to see if IA5 can be used in order to save bytes in the
> message, or to enhance readability. But that is an implementation choice.
>
>        Thanks,
>        Paul
>
>> Consider an ISDN to SIP gateway. I receive UUI. It happens to have a
>> protocol discriminator that may be understood to be IA5 encoding.
>>
>> Does that decision introduce an undesirable inspection of the protocol
>> discriminator at the gateway, and if so, is that justified?
>>
>> At one point in your mail you imply readability is an advantage. Why
>> should I be able to read the application carried by SIP?
>>
>> Note that nothing in the ISDN standards requires the actual contents to
>> correspond to the protocol discriminator, and nothing in the ISDN checks
>> that the contents actually do. ISDN allows a binary contents - the main
>> constraint being length.
>>
>> regards
>>
>> Keith
>>
>>> encoding that
>>>>> can be specified by the enc-param.
>>>>>
>>>>>> as the previous text was out of date.  This includes the
>>>>>
>>>>> new security
>>>>>>
>>>>>> requirements
>>> help the
>>>>>> In addition, we accidentally dropped the IA5 encoding -
>>>
>>> it will be
>>>>>>
>>>>>> added back in the next version.  The details in Section 5
>>>
>>> have not
>>>>>>
>>>>>> been updated as I have been concentrating on the earlier
>>>>>
>>>>> sections for
>>>>>>
>>>>>> now. I believe there is enough detail there for the working
>>>>>
>>>>> group to
>>>>>>
>>>>>> understand the direction of the proposed header field - we
>>>>>
>>>>> can refine
>>>>>>
>>>>>> them going forward.
>>>>>>
>>>>>>> A New Internet-Draft is available from the on-line
>>>>>>
>>>>>> Internet-Drafts directories.
>>>>>>>
>>>>>>> There is a need for applications using SIP to exchange
>>>>>
>>>>> User to User
>>>>>>>
>>>>>>> inserted by an application initiating the session, and
>>>>>>
>>>>>> utilized by an
>>>>>>>
>>>>>>> in the Requirements for SIP Call Control UUI document.
>>>
>>> A new SIP
>>>>>>>
>>> http://www.ietf.org/internet-drafts/draft-johnston-cuss-sip-uui-01.tx
>>>>>
>>>>> t
>>>>>>>
>>>>>>> implementation to automatically retrieve the ASCII
>>>
>>> version of the
>>>>>>>
>>>>>>> Internet-Draft.
>>>>>>>
>>>>>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Dec 2010 17:13:35 +0100

Why are you envisaging that it would save bytes in the message. At the moment, noone has defined anything about two alternative payload formats for the two different encodings.

Indeed that was the very first question I asked - what is the impact on the SIP level functionality. To which I seemed to receive the answer: "It's for the application only." 

Different payload formats would have impact on the SIP level functionality - because presumably we would send an IA5 character as 1 octet, and binary ones as two or more octets.

But moving on to implementation. If this is part of a header field, then presumably even if it is IA5, I'm going to have to escape certain codes anyway. Can we come up with a coding scheme that works for binary as well, and still allows IA5 characters to be sent as one octet? Presumably this has been addressed before.

regards

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2010 4:00 PM
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> IMO the sender should have free choice to use any encoding 
> that is capable of representing the bits.
> 
> This doesn't make processing any easier for the recipient, 
> who must be prepared for any of them. But the advantages 
> others remain.
> 
> Readability is probably not the major benefit, but it can 
> still be appreciated by those who have to scrutinize raw logs.
> 
> An ISDN GW, when *sending* UUI, might choose to always encode 
> in hex because that can be certain of working regardless of 
> the value. Or it might choose to do analysis to see if IA5 
> can be used in order to save bytes in the message, or to 
> enhance readability. But that is an implementation choice.
> 
> 	Thanks,
> 	Paul
> 
> > Consider an ISDN to SIP gateway. I receive UUI. It happens 
> to have a protocol discriminator that may be understood to be 
> IA5 encoding.
> >
> > Does that decision introduce an undesirable inspection of 
> the protocol discriminator at the gateway, and if so, is that 
> justified?
> >
> > At one point in your mail you imply readability is an 
> advantage. Why should I be able to read the application 
> carried by SIP?
> >
> > Note that nothing in the ISDN standards requires the actual 
> contents to correspond to the protocol discriminator, and 
> nothing in the ISDN checks that the contents actually do. 
> ISDN allows a binary contents - the main constraint being length.
> >
> > regards
> >
> > Keith
> >
> >> Of Paul Kyzivat
> to/from the 
> >> ISDN or not. The encoding simply gives different ways to represent 
> >> the same set of bits. IA5 can be used if all the bits you want to 
> >> include happen to have an IA5 encoding. The hex encoding 
> can be used 
> >> for any set of bits, but isn't as readable for things that have a 
> >> natural IA5 encoding.
> >>
> >> discriminators than others. And it would be annoying if your ISDN 
> >> value was all IA5 but the protocol discriminator was not, 
> so that you 
> >> had to use hex so you could embed the protocol 
> discriminator in the 
> >> value.
> >>
> >> My thinking is that the ISDN protocol discriminator ought 
> to be used 
> >> to select the "application" - in principle there would 
> then be up to 
> >> 256 potential "ISDN applications".
> >> payload) describes specifically an IA5 encoding as one 
> value, and has 
> >> other values that are not IA5. I suspect the IA5 one is 
> the one that 
> >> is most used.
> >>>
> >> to look at the payload part to decide how to encode the 
> SIP part of 
> >> this. Thus the ISDN application should ideally always use the same 
> >> value, particularly if that usage has zero impact on SIP 
> >> functionality.
> >>>
> >> suggestion would be that the ISDN application would always use the 
> >> binary value, and we make sure that the semantics of that 
> codepoint 
> >> do encapsulate that.
> >>>
> identifier 
> >> subsume that semantic, i.e. if I use application value X, 
> then that 
> >> automatically means IA5 encoding. So without further discussion of 
> >> the use cases, I have a strong doubt as to whether we need 
> a value at 
> >> all.
> >>>
> >>> regards
> >>>
> >>> Keith
> >>>
> >>>
> >>>
> encoding is?
> >>>>> Subject: Re: [cuss] I-D 
> Action:draft-johnston-cuss-sip-uui-01.txt
> >>>>>
> >>>>> Alan,
> >>>>>
> >>>>> Subject: Re: [cuss] I-D 
> Action:draft-johnston-cuss-sip-uui-01.txt
> >>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Dec 2010 14:55:42 -0500

> Why are you envisaging that it would save bytes in the message. At the moment, noone has defined anything about two alternative payload formats for the two different encodings.

I was envisioning it because the alternative that has been proposed 
before is hex.

> Different payload formats would have impact on the SIP level functionality - because presumably we would send an IA5 character as 1 octet, and binary ones as two or more octets.

Or we would send the entire payload as either IA5 or hex.

> But moving on to implementation. If this is part of a header field, then presumably even if it is IA5, I'm going to have to escape certain codes anyway. Can we come up with a coding scheme that wor…

Well, there's lots of ways to skin that cat.
But its probably best not to get too creative here and invent something 
entirely new. Better to use something we have. Some that come to mind are:

- hex
- radix64
- something involving 'escaped' from 3261, such as 'user'

Note that usual suspects, such as 'generic-param' and its 'gen-value' 
don't allow all possible bytes, unless you lay another level of excaping 
on top, such as hex or radix64 (which can conform to 'token').

Using 'user' or something like it would support simple text on a byte 
for byte basis while also allowing any arbitrary binary byte. But for 
the stuff the has to be escaped the expansion is 3:1.

Alternatively, using hex takes 2:1 regardless of what the bytes are. 
Radix64 is better - 4:3. One might argue that for efficiency radix64 is 
good enough.

Having alternative formats allows choosing the one that is most 
efficient in any case, but then requires something else to indicate 
which format is being used, which reduces the efficiency some.

I sense that from a convenience perspective some would like the option 
to just send text when they know what they are sending *is* text, while 
having the option to send another way when text isn't sufficient.

As a thought, how about allowing either radix64 or a quoted string, 
distinguished by the presence of the quotes? Sender's choice - receiver 
must handle both.

	Thanks,
	Paul