Subject: [cuss] Review of draft-ietf-cuss-sip-uui

From: Shida Schubert <[email-masked]>
Date: Tue, 29 Nov 2011 10:32:02 +0900

I was asked by chairs of this WG to review 
draft-ietf-cuss-sip-uui. 

Below are my comments 

** OVERALL ***

The draft talks a lot about escaping the header. 
We used the same terminology in rfc4244bis, but 
after some discussion decided with "including/include".

I think the reason was due to the fact that 3261 doesn't 
use "escape" in that context. 

I didn't see any issue with how the rfc4244bis is used.

** TECHNICAL ***

1. Will the behavior of the device be affected if the 
source of UUI data is different from the assumed entity?
I am assuming it doesn't as the inserterthere is an a priori understanding ... of the UUI 
data doesn't seem too be so important from the draft. 

2. I think there is little or no text about the behavior 
of entity receiving UUI data, encoding or package 
that it doesn't understand. I am assuming it simply  
ignores it but, I think this should be explicitly 
stated somewhere in normative language. 

3. Section 3 talks about UUI header being removed 
by proxy/intermediary. But it is mute about intermediary 
adding UUI header, leaving room for them to add it. 
So what would happen if intermediary adds UUI header? 
Who is the inserter? What does that mean? If we don't 
see any use for intermediary adding the header, I think 
we should say MUST NOT for intermediary. 

4. I think normative text surrounding redirecting entity 
adding user-to-user info be added. 

5. When UAS redirects the request with 
User-to-User: foo;package=1;encoding=hex to a 
contact with a User-to-User:bar;package=1;encoding=hex. 

I am assuming that you will end up with 

User-to-User: foo;package=1;encoding=hex, bar;package=1,encoding=hex

You end up with two uui data from two different entity. 
Is this going to pose problem? 

I guess if 4244bis was supported, this would be 
logged and one can see that the latter was added by 
an UAS which redirected the request.. Do we need to 
add some text regarding this? Are the last value more 
important than the one added by the originator of the 
request?

** NITS ***
Section 1

OLD :  there is an a priori understanding ...
NEW : there is a priori understanding ...

Section 5

OLD : SIP UUI mechanism must publish a standard track.
NEW : SIP UUI mechanism MUST publish a standard tack.

OLD : some use case example examples.
NEW : some use case examples. 

OLD : Hex encoded UUI data must have an even...
NEW : Hex encoded UUI data MUST have an even..

OLD : New "encoding" values must reference...
NEW : New "encoding" values MUST reference..

OLD : New "content" values must describe...
NEW : New "content" values MUST describe..

I hope this helps. 

Regards
 Shida