Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt

From: [email-masked]
Date: Mon, 12 Mar 2012 14:50:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Call Control UUI Service for SIP Working Group of the IETF.

	Title           : A Mechanism for Transporting User to User Call Control Information in SIP
	Author(s)       : Alan Johnston
                          James Rafferty
	Filename        : draft-ietf-cuss-sip-uui-05.txt
	Pages           : 17
	Date            : 2012-03-12

   There is a class of applications which benefit from using SIP to
   exchange User to User Information (UUI) data during session
   establishment.  This information, known as call control UUI data, is
   a small piece of data inserted by an application initiating the
   session, and utilized by an application accepting the session.  The
   rules which apply for a certain application are defined by a UUI
   package.  This UUI data is opaque to SIP and its function is
   unrelated to any basic SIP function.  This document defines a new SIP
   header field, User-to-User, to transport UUI data, along with an
   extension mechanism.

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

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-05.txt

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 13 Mar 2012 12:23:34 +0100

Dear Alan,

unfortunately you forgot to improve the hex encoding definition. I paste
in relevant parts of an my old email proposal on the email list plus
Paul's replies. As nobody else replied on those points I were confident
that they were acceptable:

> 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"

Seems reasonable.

> 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.

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.

> 4. Lack of normative language ("MUST")
>

In the mean time I discovered some additional related issues:

5. "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."
This text says that the most significant four bytes always come first in
the binary data.
However, this depends on the nature of the binary data and cannot be
defined here.
It is enough to state that the first bits in the binary UUI data shall
be mapped to the first
Hex digit. This also makes an interworking box to ISUP much simpler.

6. It is unclear how 4 bits of binary data are mapped to a hex digit:
Shall the first or last bit
of the binary data be most significant for the purpose of that mapping?
I assume the first bit.

7. The text seems to assume that the binary data to be encoded have a
full octet length without stating so.
I added such a statement.
For discussion: if we also want to allow for other lengths of binary
data,
we may want to define some padding (e.g. with Zero bits) to the next
octet boundary. Unfortunately I could
imagine that this sometimes leads to ambiguities when decoding.

I understand that some other of my old related proposals (only
upper-case characters and token) were controversial,
so I do not include them in my text proposal below.

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 with a length that
    terminates at an octet boundary. 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, A-F and a-f), each
representing
    four bits within the octet. The four bits appearing first in the
binary UUI
    data MUST be mapped to the first hexadecimal digit and the four
subsequent
    bits in the binary UUI data MUST be mapped to the second
    hexadecimal digit. When mapping 4 bits to a hexadecimal digit, the
bit
    appearing first in the binary UUI data shall be most significant. 
    Thus, Hex encoded UUI data must have an even number
    of hexadecimal digits, and MUST be 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 MUST be ignored.  

As another issue, you now have much procedural text, in particular
related to redirection, in your "Syntax" clause 4.1. What about placing
this in a new subclause 4.x instead?

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext [email-masked]
Sent: Monday, March 12, 2012 10:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Call Control UUI Service
for SIP Working Group of the IETF.

	Title           : A Mechanism for Transporting User to User Call
Control Information in SIP
	Author(s)       : Alan Johnston
                          James Rafferty
	Filename        : draft-ietf-cuss-sip-uui-05.txt
	Pages           : 17
	Date            : 2012-03-12

_______________________________________________
cuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cuss

---

From: Alan Johnston <[email-masked]>
Date: Tue, 13 Mar 2012 12:44:44 -0500

Thomas,

Yes, you are right - I was concentrating on the reviews and forgot
about this thread.  I'll propose some text for hex coding so we can
discuss it on the list.

- Alan -

---

From: <[email-masked]>
Date: Mon, 26 Mar 2012 15:06:07 +0200

Hello,

I would have 2 comments (related to my 2 previous comments on the former version -04) on your updated draft-ietf-cuss-sip-uui-05:

- 1/ in section 4.1, it's indicated that "Multiple User-to-User header fields MAY be present in a request or response" but it doesn't clarify if it could be using the same or different packages. As you proposed before in your reply, would it be possible to indicate that "Multiple User-to-User header fields MAY be present in a request or response, containing uui-data for the same or for different packages"?

- 2/ in section 4.1, the example "User-to-User: 56a390f3d2b7310023a;encoding=hex;purpose=foo;content=bar" contains the "purpose" parameter in replacement of the "package" parameter. Would it be possible to extend the use of the "purpose" parameter to the rest of the document? Indeed, "purpose" is a relevant name if the parameter is defined as to indicate the purpose of the package mechanism used to convey the IUU data. Moreover it has the benefit to be backward compatible with historical draft-johnston-sipping-cc-uui-08 on which some implementations are based.
For that, it will be necessary to change the definition of the parameter in section 4 as follows:

The "package" parameter identifies the package which defines the generation and usage of the UUI data for a particular application.

==>

The "purpose" parameter identifies the purpose of the package which defines the generation and usage of the UUI data for a particular application. 

Thank you in advance.
Best Regards,

Celine serrut-valette
Orange Labs

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 12 mars 2012 22:50
À : [email-masked]
Cc : [email-masked]
Objet : [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt

---

From: Alan Johnston <[email-masked]>
Date: Wed, 28 Mar 2012 06:15:37 -0500

Celine,

On #1, I'm fine calling out that the multiple UUI data elements can be
for the same or different packages.

On #2, it was a cut-and-paste error that left the "purpose" parameter.
 The next version will change this to "package", so we will not be
using "purpose" going forward.

- Alan -

---

From: Alan Johnston <[email-masked]>
Date: Wed, 28 Mar 2012 06:16:29 -0500

Thomas,

My apologies for missing the proposed text at the end of your mail.
Your text looks fine - we will include it in the next version.

- Alan -

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 11:50:04 +0200

Hello,

Thank you for your answer and your future modifications in next version of the draft.

Regarding the name of the parameter, we do not understand what the issue is to come back to the previous parameter name "purpose" because this does not invalidate the concept of package mechanism which is still valid with this change and, at the same time, this allows to avoid a backward compatibility issue with draft-johnston-sipping-cc-uui-08 on which several implementations are based. 

For that, the definition of the parameter needs to be modified in section 4 as follows:
The "package" parameter identifies the package which defines the generation and usage of the UUI data for a particular application.
==>
The "purpose" parameter identifies the purpose of the package which defines the generation and usage of the UUI data for a particular application.

Thank you in advance.
Best Regards.

Celine serrut-valette
Orange Labs

-----Message d'origine-----
De : Alan Johnston [mailto:[email-masked]] 
Envoyé : mercredi 28 mars 2012 13:16
À : SERRUT-VALETTE Celine RD-CORE-ISS
Cc : [email-masked]; [email-masked]
Objet : Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-05.txt

Celine,

- Alan -