Subject: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 19 Jan 2012 18:25:46 +0100

Dear all

Checking draft-ietf-cuss-sip-uui-04, I found that the definition of hex encoding could be improved:

What came closest to a definition of the encoding was the following:

"
5.  Guidelines for UUI Packages
...
   This specification defines only the value of "hex" for the "encoding"
   parameter.  Hex encoding, as used for UUI data is defined to use only
   the characters 0-9, A-F, or a-f.  Hex encoded UUI data must have an
   even number of octets, and is considered invalid if has an odd
   number.  Hex encoding is normally done as a token, although quoted-
   string is permitted, in which case the quotes are ignored.  Hex
   encoding yields a sequence of octets, one octet per two hex digits,
   in the same order, with the first digit of each pair defining the
   high order four bits of the octet and the second digit providing the
   low order four bits.
"

I see a couple of issues:

1. This seems to be in a strange place within the draft to define the hex encoding. I would rather suggest a dedicated subclause "4.x Hex encoding definition"

2. "Hex encoding yields a sequence of octets, one octet per two hex digits"
I believe it is rather the other way round: "Hex encoding of a series of octets of binary data yields a series of hexadecimal digits, two hexadecimal digits for each octet of binary data.". Hexadecimal digits seem to be called "octets" throughout the text, which is highly confusing.

3. "Hex encoded UUI data must have an even number of octets, and is considered invalid if has an odd number." This is a similar problem, and the text is quite ambiguous: Does "octet" refer to the binary data to be encoded or the result of the encoding? The text only makes sense if "octet" is understood as the result of encoding. Speaking about "characters" or "hexadecimal digits" rather than "octets" would remove this ambiguity.

4. Lack of normative language ("MUST")

5. Allowing minor characters:
In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler.

6. Allowing "quoted-string" encoding.
Earlier versions of predecessor draft-johnston that might be in the field (see above) allowed only "token". Again, it would improve backward compatibility and slightly simplify implementations if only "token" is allowed for "hex" encoding. (It is fine to keep "quoted-string" for other encodings.)

To sum up, a text proposal:

4.x Hex encoding definition
   This specification defines only the value of "hex" for the "encoding"
   parameter.  It is used to encode binary UUI data.
   Each octet of binary data to be represented in the hex encoding MUST
   be mapped to two hexadecimal digits (represented by ASCII characters
   0-9 and A-F), each representing four bits within the octet. The four
   most significant bits MUST be mapped to the first hexadecimal digit
   and the four least significant bits MUST be mapped to the second
   hexadecimal digit. Thus, Hex encoded UUI data must have an even number
   of hexadecimal digits, and MUST be considered invalid if has an odd
   number. For "hex" encoding, "uui-data" MUST be encoded as "token".

BR, Thomas

----------------------------------
Dr. Thomas Belling 
3GPP Standardisation 
Nokia Siemens Networks

---

From: Alan Johnston <[email-masked]>
Date: Thu, 19 Jan 2012 12:13:50 -0600

Thomas,

Thank you for the detailed feedback.  We definitely want to get the
definition of hex encoding correct, and have it be very clear.

I'm working on an update to the draft now.  I'll post the edited text
on hex encoding on the list before I submit.

In the meantime, perhaps some others want to comment on your proposal.

- Alan -

On Thu, Jan 19, 2012 at 11:25 AM, Belling, Thomas (NSN - DE/Munich)
<[email-masked]> wrote:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jan 2012 15:11:59 -0500

> 1. This seems to be in a strange place within the draft to define the hex encoding. I would rather suggest a dedicated subclause "4.x Hex encoding definition"

Seems reasonable.

> I believe it is rather the other way round: "Hex encoding of a series of octets of binary data yields a series of hexadecimal digits, two hexadecimal digits for each octet of binary data.". Hexadec…

I agree.

> 3. "Hex encoded UUI data must have an even number of octets, and is considered invalid if has an odd number." This is a similar problem, and the text is quite ambiguous: Does "octet" refer to the b…

I agree.

> 5. Allowing minor characters:

My "minor characters" do you mean "lower case" characters?

> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition withi…

I just find this distinctly unfriendly.
Is this a real problem, or a theoretical one? What do the existing 
implementations of the above specs actually do?
(As an implementer I would always support both cases even if the spec 
didn't require it - unless I was writing a conformance test.)

> Earlier versions of predecessor draft-johnston that might be in the field (see above) allowed only "token". Again, it would improve backward compatibility and slightly simplify implementations if o…

I would rather not see this change made.
But I won't fight if it is.

	Thanks,
	Paul

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 20 Jan 2012 10:35:37 +0100

Thanks, Paul

Replies are below.

> By "minor characters" do you mean "lower case" characters?

Yes

>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on
old versions of the predecessor draft-johnston and provide our own
definition of hex encoding (in the lack of any definition within the
draft). This 3GPP/TISPAN definition seems to be largely aligned, but
allows only major characters. This has been in those specs already for
some years and might be implemented; operators raised such concerns when
we discussed updating our references. It would make life simpler for us
if you also only allow major characters. Besides, implementations would
become slightly simpler.

I believe this is a real problem:
In 3GPP a couple of operators raised general concerns about backward
compatibility, and CRs to update references to the latest version of the
drafts had to be postponed for this reason. This is why I believe
something might already be rolled out or be very close to be rolled out.
The issue of only "upper case" characters was not yet specifically
discussed, though. But from 3GPP and TISPAN specs it is currently
absolutely clear that only upper case is allowed.

I agree with your robust implementation principle that a receiver should
be tolerant. Unfortunately we cannot be sure that this is true with
respect to "lower case" characters for rolled out receivers. (And the
other half of the robust implementation principle is that the sender
should accurately follow the standards. This is what I was aiming at.)

>> Earlier versions of predecessor draft-johnston that might be in the 
>> field (see above) allowed only "token". Again, it would improve 
>> backward compatibility and slightly simplify implementations if only 
>> "token" is allowed for "hex" encoding. (It is fine to keep 
>> "quoted-string" for other encodings.)

> But I won't fight if it is.

This is a very similar issue. Without backward compatibility
considerations, I would also be fine with allowing both. 

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Paul Kyzivat
Sent: Thursday, January 19, 2012 9:12 PM
To: [email-masked]
Subject: Re: [cuss] Definition of hex encoding in
draft-ietf-cuss-sip-uui-04

On 1/19/12 12:25 PM, Belling, Thomas (NSN - DE/Munich) wrote:
> 1. This seems to be in a strange place within the draft to define the
hex encoding. I would rather suggest a dedicated subclause "4.x Hex
encoding definition"

Seems reasonable.

> I believe it is rather the other way round: "Hex encoding of a series
of octets of binary data yields a series of hexadecimal digits, two
hexadecimal digits for each octet of binary data.". Hexadecimal digits
seem to be called "octets" throughout the text, which is highly
confusing.

I agree.

> 3. "Hex encoded UUI data must have an even number of octets, and is
considered invalid if has an odd number." This is a similar problem, and
the text is quite ambiguous: Does "octet" refer to the binary data to be
encoded or the result of the encoding? The text only makes sense if
"octet" is understood as the result of encoding. Speaking about
"characters" or "hexadecimal digits" rather than "octets" would remove
this ambiguity.

I agree.

> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old
versions of the predecessor draft-johnston and provide our own
definition of hex encoding (in the lack of any definition within the
draft). This 3GPP/TISPAN definition seems to be largely aligned, but
allows only major characters. This has been in those specs already for
some years and might be implemented; operators raised such concerns when
we discussed updating our references. It would make life simpler for us
if you also only allow major characters. Besides, implementations would
become slightly simpler.

> Earlier versions of predecessor draft-johnston that might be in the 
> field (see above) allowed only "token". Again, it would improve 
> backward compatibility and slightly simplify implementations if only 
> "token" is allowed for "hex" encoding. (It is fine to keep 
> "quoted-string" for other encodings.)

	Thanks,
	Paul

---

From: "VAN GEEL Jan (SDV/PSE)" <[email-masked]>
Date: Fri, 20 Jan 2012 13:44:00 +0100

Paul,

Maybe to help understanding my concern:

At present we implemented the following encoding (as described in ETSI TISPAN TS 183 036) in a media gateway controller (interworking gateway between IMS and legacy ISDN):

        The format of the uuidata field shall be the hexadecimal representation of binary data coded in ascii alphanumeric
        characters. For example, the 8- bit binary value 0011- 1111 is 3F in hexadecimal. To code this in ascii, one 8- bit
        byte containing the ascii code for the character '3' (0011- 0011 or 033H) and one 8- bit byte containing the ascii
        code for the character 'F' (0100- 0110 or 046H) are required. For each byte value, the high-order hexadecimal digit
        is always the first digit of the pair of hexadecimal digits. The ascii letters used for the hex digits shall always be
        capital form.

My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies the encoding slightly different and also allows lower case.
In fact during our testing we experienced that an ISDN converter implemented the encoding slightly different and the result is that the
UUS doesn't interwork with legacy ISDN.

If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by 3GPP and ETSI any MGCF or ISDN gateway implementing this version will be incompatible with our existing implementation.

Unfortunately not all implementers have your attitude of implementing of building robust implementations coping with unrequired stuff. In order to help them building interoperable and compatible products some backward compatibility should be ensured.

Therefore I would propose to include the text with the encoding example above in the draft so that it is very clear how it should be done.

Kind regards

Jan Van Geel
IT and Network Specialist
Belgacom SDE/SDV/PSE/FVC
Tel: +32 2 202 1035
Tel: +32 2 207 9032
Email : [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Belling, Thomas (NSN - DE/Munich)
Sent: 20 January 2012 10:36
To: ext Paul Kyzivat; [email-masked]
Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04

Thanks, Paul

Replies are below.

Yes

>> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on
old versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler.

I believe this is a real problem:
In 3GPP a couple of operators raised general concerns about backward compatibility, and CRs to update references to the latest version of the drafts had to be postponed for this reason. This is why I believe something might already be rolled out or be very close to be rolled out.
The issue of only "upper case" characters was not yet specifically discussed, though. But from 3GPP and TISPAN specs it is currently absolutely clear that only upper case is allowed.

I agree with your robust implementation principle that a receiver should be tolerant. Unfortunately we cannot be sure that this is true with respect to "lower case" characters for rolled out receivers. (And the other half of the robust implementation principle is that the sender should accurately follow the standards. This is what I was aiming at.)

> But I won't fight if it is.

This is a very similar issue. Without backward compatibility considerations, I would also be fine with allowing both.

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Paul Kyzivat
Sent: Thursday, January 19, 2012 9:12 PM
To: [email-masked]
Subject: Re: [cuss] Definition of hex encoding in

> 1. This seems to be in a strange place within the draft to define the
hex encoding. I would rather suggest a dedicated subclause "4.x Hex encoding definition"

Seems reasonable.

> I believe it is rather the other way round: "Hex encoding of a series
of octets of binary data yields a series of hexadecimal digits, two hexadecimal digits for each octet of binary data.". Hexadecimal digits seem to be called "octets" throughout the text, which is highly confusing.

I agree.

> 3. "Hex encoded UUI data must have an even number of octets, and is
considered invalid if has an odd number." This is a similar problem, and the text is quite ambiguous: Does "octet" refer to the binary data to be encoded or the result of the encoding? The text only makes sense if "octet" is understood as the result of encoding. Speaking about "characters" or "hexadecimal digits" rather than "octets" would remove this ambiguity.

I agree.

> In ETSI TISPAN TS 183 036 and 3GPP TS 29.163, we base currently on old
versions of the predecessor draft-johnston and provide our own definition of hex encoding (in the lack of any definition within the draft). This 3GPP/TISPAN definition seems to be largely aligned, but allows only major characters. This has been in those specs already for some years and might be implemented; operators raised such concerns when we discussed updating our references. It would make life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler.

I just find this distinctly unfriendly.
Is this a real problem, or a theoretical one? What do the existing implementations of the above specs actually do?
(As an implementer I would always support both cases even if the spec didn't require it - unless I was writing a conformance test.)

        Thanks,
        Paul

*****  Disclaimer *****
http://www.belgacom.be/maildisclaimer/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2012 11:12:39 -0500

> At present we implemented the following encoding (as described in ETSI TISPAN TS 183 036) in a media gateway controller (interworking gateway between IMS and legacy ISDN):

Anybody who implements a *draft* before it becomes an RFC should be 
aware that things can change before it becomes an RFC. If we felt we 
couldn't change a draft once somebody has implemented it we would never 
get anything right. It is painful to be on the bleeding edge, but that 
is the way it is.

In this case, IIRC, the draft never specified defined the hex encoding 
at all, until the current definition was added. If ETSI TISPAN decided 
to define the encoding, it could have at least proposed it as a change 
to the draft - *before* implementing it. That would have provoked a 
discussion and probably confronted this issue at that time.

> Unfortunately not all implementers have your attitude of implementing of building robust implementations coping with unrequired stuff. In order to help them building interoperable and compatible pr…

The Postel maxim is often mentioned in ietf: be conservative in what you 
do, be liberal in what you accept from others.

I agree with this in principle, even though in practice it isn't as 
helpful as one might like. (It only works to the extent that everyone 
agrees on what the liberal interpretation is.) But in this case I don't 
think there is a lot of controversy over what the liberal interpretation 
might be.

So tell me - what will a liberal implementer do when decoding the value 
"3f"?
Will it reject the entire message? (I find that hard to believe.)
Will it treat the "f" as something other than 1111? (what?)
Will it ignore the "f"? (Maybe, but that would be stupid.)

> Therefore I would propose to include the text with the encoding example above in the draft so that it is very clear how it should be done.

I am fine with examples.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Fri, 20 Jan 2012 10:26:59 -0600

I have to agree with Paul, here.  Hex encoding in IETF standards
always seems to allow upper and lower, including RFC 3261.  In places
where case is significant, I think lowercase is more commonly
specified than uppercase.

I think we need to continue to allow upper and lower case a-f for hex encoding.

- Alan -

On Fri, Jan 20, 2012 at 10:12 AM, Paul Kyzivat <[email-masked]> wrote:
>> At present we implemented the following encoding (as described in ETSI
>> TISPAN TS 183 036) in a media gateway controller (interworking gateway
>> between IMS and legacy ISDN):
>
>
> Anybody who implements a *draft* before it becomes an RFC should be aware
> that things can change before it becomes an RFC. If we felt we couldn't
> change a draft once somebody has implemented it we would never get anything
> right. It is painful to be on the bleeding edge, but that is the way it is.
>
> In this case, IIRC, the draft never specified defined the hex encoding at
> all, until the current definition was added. If ETSI TISPAN decided to
> define the encoding, it could have at least proposed it as a change to the
> draft - *before* implementing it. That would have provoked a discussion and
> probably confronted this issue at that time.
>
>>         The format of the uuidata field shall be the hexadecimal
>> representation of binary data coded in ascii alphanumeric
>>         characters. For example, the 8- bit binary value 0011- 1111 is 3F
>> in hexadecimal. To code this in ascii, one 8- bit
>>         byte containing the ascii code for the character '3' (0011- 0011
>> or 033H) and one 8- bit byte containing the ascii
>>         code for the character 'F' (0100- 0110 or 046H) are required. For
>> each byte value, the high-order hexadecimal digit
>>         is always the first digit of the pair of hexadecimal digits. The
>> ascii letters used for the hex digits shall always be
>>         capital form.
>>
>> My understanding is that the latest draft-ietf-cuss-sip-uui-04 specifies
>> the encoding slightly different and also allows lower case.
>> In fact during our testing we experienced that an ISDN converter
>> implemented the encoding slightly different and the result is that the
>> If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state by
>> 3GPP and ETSI any MGCF or ISDN gateway implementing this version will be
>> incompatible with our existing implementation.
>>
>> Unfortunately not all implementers have your attitude of implementing of
>> building robust implementations coping with unrequired stuff. In order to
>> help them building interoperable and compatible products some backward
>> compatibility should be ensured.
>
>
> The Postel maxim is often mentioned in ietf: be conservative in what you do,
> be liberal in what you accept from others.
>
> I agree with this in principle, even though in practice it isn't as helpful
> as one might like. (It only works to the extent that everyone agrees on what
> the liberal interpretation is.) But in this case I don't think there is a
> lot of controversy over what the liberal interpretation might be.
>
>> Therefore I would propose to include the text with the encoding example
>> above in the draft so that it is very clear how it should be done.
>
>
> I am fine with examples.
>
>        Thanks,
>        Paul
>
>> Kind regards
>>
>> Jan Van Geel
>> Belling, Thomas (NSN - DE/Munich)
>> definition of hex encoding (in the lack of any definition within the draft).
>> This 3GPP/TISPAN definition seems to be largely aligned, but allows only
>> major characters. This has been in those specs already for some years and
>> might be implemented; operators raised such concerns when we discussed
>> updating our references. It would make life simpler for us if you also only
>> allow major characters. Besides, implementations would become slightly
>> simpler.
>>
>> drafts had to be postponed for this reason. This is why I believe something
>> might already be rolled out or be very close to be rolled out.
>> discussed, though. But from 3GPP and TISPAN specs it is currently absolutely
>> clear that only upper case is allowed.
>>
>> be tolerant. Unfortunately we cannot be sure that this is true with respect
>> to "lower case" characters for rolled out receivers. (And the other half of
>> the robust implementation principle is that the sender should accurately
>> follow the standards. This is what I was aiming at.)
>>
>>
>>> Checking draft-ietf-cuss-sip-uui-04, I found that the definition of
>>
>> hex encoding could be improved:
>>>
>>>
>>>     This specification defines only the value of "hex" for the
>>
>> "encoding"
>>>
>>>     parameter.  Hex encoding, as used for UUI data is defined to use
>>
>> only
>>>
>>>     the characters 0-9, A-F, or a-f.  Hex encoded UUI data must have
>>
>> an
>>>
>>>     number.  Hex encoding is normally done as a token, although
>>
>> quoted-
>>>
>>>     encoding yields a sequence of octets, one octet per two hex
>>
>> digits,
>>>
>>>     high order four bits of the octet and the second digit providing
>>
>> the
>>>
>>>     low order four bits.
>>> "
>>>
>>>
>>> 2. "Hex encoding yields a sequence of octets, one octet per two hex
>>
>> digits"
>>>
>> hexadecimal digits for each octet of binary data.". Hexadecimal digits seem
>> to be called "octets" throughout the text, which is highly confusing.
>>
>> I agree.
>>
>> encoded or the result of the encoding? The text only makes sense if "octet"
>> is understood as the result of encoding. Speaking about "characters" or
>> "hexadecimal digits" rather than "octets" would remove this ambiguity.
>>
>> I agree.
>>
>> versions of the predecessor draft-johnston and provide our own definition
>> of hex encoding (in the lack of any definition within the draft). This
>> 3GPP/TISPAN definition seems to be largely aligned, but allows only major
>> characters. This has been in those specs already for some years and might be
>> implemented; operators raised such concerns when we discussed updating our
>> references. It would make life simpler for us if you also only allow major
>> characters. Besides, implementations would become slightly simpler.
>>
>>>     This specification defines only the value of "hex" for the
>>
>> "encoding"
>>>
>>>     Each octet of binary data to be represented in the hex encoding
>>
>> MUST
>>>
>>>     be mapped to two hexadecimal digits (represented by ASCII
>>
>> characters
>>>
>>>     0-9 and A-F), each representing four bits within the octet. The
>>
>> four
>>>
>>>     most significant bits MUST be mapped to the first hexadecimal
>>
>> digit
>>>
>>>     hexadecimal digit. Thus, Hex encoded UUI data must have an even
>>
>> number
>>>
>>>     of hexadecimal digits, and MUST be considered invalid if has an
>>
>> odd
>>>

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 20 Jan 2012 17:37:44 +0100

Hi Paul,

I hoped that we could avoid making this a matter of principle:
Yes, you are right this encoding stuff should have been raised in IETF
and not simply included in 3GPP and TISPAN.
But a part of the problem is also that IETF required several years to
complete this one User-to-User SIP header. This is why implementations
are out by now. In 3GPP and TISPAN we have fixed time plans (in 3GPP
about one release a year), as demanded by our operator customers who
desire features to become available in a reasonable amount of time. (If
3GPP starts to expect that IETF requires significantly longer time
frames to stabilize work, this makes adoption of ongoing IETF work in
3GPP quite complicated.) For CUSS, in the worst case some companies in
TISPAN and 3GPP might object that 3GPP updates to your latest drafts,
leading to divergent usages of the User-to-User header.

Let us rather be pragmatic here and understand each other needs rather
than digging in the history to find who is to blame.
Obviously, things did not go as well as desirable, but luckily the fix
is quite simple and harmless:
The changes in the encoding I suggest are quite minor.

Thomas

-----Original Message-----
From: ext Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, January 20, 2012 5:13 PM
To: VAN GEEL Jan (SDV/PSE)
Cc: [email-masked]; Belling, Thomas (NSN - DE/Munich)
Subject: Re: [cuss] Definition of hex encoding in

>          characters. For example, the 8- bit binary value 0011- 1111
is 3F in hexadecimal. To code this in ascii, one 8- bit
>          byte containing the ascii code for the character '3' (0011-
0011 or 033H) and one 8- bit byte containing the ascii
>          code for the character 'F' (0100- 0110 or 046H) are required.
For each byte value, the high-order hexadecimal digit
>          is always the first digit of the pair of hexadecimal digits.
The ascii letters used for the hex digits shall always be
>          capital form.
>
> My understanding is that the latest draft-ietf-cuss-sip-uui-04
specifies the encoding slightly different and also allows lower case.
>
> If now the draft-ietf-cuss-sip-uui-04 is adopted in its current state
by 3GPP and ETSI any MGCF or ISDN gateway implementing this version will
be incompatible with our existing implementation.
>
> Unfortunately not all implementers have your attitude of implementing
of building robust implementations coping with unrequired stuff. In
order to help them building interoperable and compatible products some
backward compatibility should be ensured.

So tell me - what will a liberal implementer do when decoding the value
"3f"?
Will it reject the entire message? (I find that hard to believe.) Will
it treat the "f" as something other than 1111? (what?) Will it ignore
the "f"? (Maybe, but that would be stupid.)

> Therefore I would propose to include the text with the encoding
example above in the draft so that it is very clear how it should be
done.

I am fine with examples.

	Thanks,
	Paul

>
> I agree with your robust implementation principle that a receiver 
> should be tolerant. Unfortunately we cannot be sure that this is true 
> with respect to "lower case" characters for rolled out receivers. (And

> the other half of the robust implementation principle is that the 
> sender should accurately follow the standards. This is what I was 
> aiming at.)
>
>

encoding definition"
> considered invalid if has an odd number." This is a similar problem,
and the text is quite ambiguous: Does "octet" refer to the binary data
to be encoded or the result of the encoding? The text only makes sense
if "octet" is understood as the result of encoding. Speaking about
"characters" or "hexadecimal digits" rather than "octets" would remove
this ambiguity.
>> old

---

From: James Rafferty <[email-masked]>
Date: Fri, 20 Jan 2012 13:37:43 -0500

I also agree with Paul and Alan.  The earlier versions of UUI support in the IETF have been internet drafts, and the implementers always need to be aware that the standards track version may vary from earlier drafts, so the concept of needing backward compatibility to a non-standard internet draft does not apply.  

In the case of the ETSI implementation, if the IETF approach allows both lower and upper case hex, there is nothing to say that the ETSI implementation won't still work (i.e. the IETF UUI recipient could still decode it), just that this non-IETF implementation is not as flexible in its support for incoming UUI that includes lower case hex.   

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Friday, January 20, 2012 11:27 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [cuss] Definition of hex encoding in draft-ietf-cuss-sip-uui-04

I have to agree with Paul, here.  Hex encoding in IETF standards always seems to allow upper and lower, including RFC 3261.  In places where case is significant, I think lowercase is more commonly specified than uppercase.

- Alan -

On Fri, Jan 20, 2012 at 10:12 AM, Paul Kyzivat <[email-masked]> wrote:
>> At present we implemented the following encoding (as described in 
>> ETSI TISPAN TS 183 036) in a media gateway controller (interworking 
>> gateway between IMS and legacy ISDN):
>
>
> couldn't change a draft once somebody has implemented it we would 
> never get anything right. It is painful to be on the bleeding edge, but that is the way it is.
>
>> implemented the encoding slightly different and the result is that 
>> the UUS doesn't interwork with legacy ISDN.
>>
>> by 3GPP and ETSI any MGCF or ISDN gateway implementing this version 
>> will be incompatible with our existing implementation.
>>
>> order to help them building interoperable and compatible products 
>> some backward compatibility should be ensured.
>
>
> The Postel maxim is often mentioned in ietf: be conservative in what 
> you do, be liberal in what you accept from others.
>
> agrees on what the liberal interpretation is.) But in this case I 
> don't think there is a lot of controversy over what the liberal interpretation might be.
>
> So tell me - what will a liberal implementer do when decoding the 
> value "3f"?
>> example above in the draft so that it is very clear how it should be done.
>
>
> I am fine with examples.
>
>        Thanks,
>        Paul
>
>> Kind regards
>>
>> Jan Van Geel
>> This 3GPP/TISPAN definition seems to be largely aligned, but allows 
>> only major characters. This has been in those specs already for some 
>> years and might be implemented; operators raised such concerns when 
>> we discussed updating our references. It would make life simpler for 
>> us if you also only allow major characters. Besides, implementations 
>> would become slightly simpler.
>>
>> compatibility, and CRs to update references to the latest version of 
>> the drafts had to be postponed for this reason. This is why I believe 
>> with respect to "lower case" characters for rolled out receivers. 
>> (And the other half of the robust implementation principle is that 
>> the sender should accurately follow the standards. This is what I was 
>> aiming at.)
>>
>>
>>>> backward compatibility and slightly simplify implementations if 
>>>> only "token" is allowed for "hex" encoding. (It is fine to keep 
>> hexadecimal digits for each octet of binary data.". Hexadecimal 
>> digits seem to be called "octets" throughout the text, which is highly confusing.
>>
>> I agree.
>>
>> and the text is quite ambiguous: Does "octet" refer to the binary 
>> data to be encoded or the result of the encoding? The text only makes sense if "octet"
>> is understood as the result of encoding. Speaking about "characters" 
>> or "hexadecimal digits" rather than "octets" would remove this ambiguity.
>>
>> I agree.
>>
>> allows only major characters. This has been in those specs already 
>> for some years and might be implemented; operators raised such 
>> concerns when we discussed updating our references. It would make 
>> life simpler for us if you also only allow major characters. Besides, implementations would become slightly simpler.
>>