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

From: Alan Johnston <[email-masked]>
Date: Mon, 12 Mar 2012 16:50:28 -0500

Shida,

Thanks very much for the review.  I believe I have addressed your issues in the -05 version.  See a few comments below.

- Alan -

On Nov 28, 2011, at 7:10 PM, Shida Schubert wrote:

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

Done.

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

Great!

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

Not really, although I did put in some text in the security considerations saying a UA can apply policy to the processing of UUI data based on who inserted it.

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

I added a statement saying unknown packages and encodings should be ignored.

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

Well, this would be tricky to write in a way that doesn't confuse.  The spec is clear that UUI is between UAs, not between anyone else.  However, UUI data included in a 3xx could be inserted by a proxy that recurses on the 3xx, but it isn't really the proxy that is inserting it.  I

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

I added a SHOULD level statement.

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

This is a very good point.  I don't think the mechanism itself should be definitive on this.  But packages must say how to handle this.  I even think that the same content with multiple encodings seems like a good idea, except for the ISDN service where it isn't backwards compatible.   There is new text in Section 5 about this.

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

I don't think so.  Having History-Info to sort it out is about the best we can do.

> 
> ** NITS ***
> Section 1
> 
> OLD :  there is an a priori understanding ...
> NEW : there is a priori understanding ...

I kept the old text as I think it is right - the RFC editor will have the final say, of course.

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

Very much - thanks!

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

---

From: Alan Johnston <[email-masked]>
Date: Mon, 12 Mar 2012 16:50:32 -0500

Martin,

Thanks very much for the review.  I think I have addressed your comments in the -05 version.  See a few comments below.

- Alan -

On Jan 10, 2012, at 9:32 AM, DOLLY, MARTIN C wrote:

> Greetings,
> Below are my comments, build on Shida's comments posted on 11/29/2011
> 
> The concept of "escaping" needs to be added to Section 4 Normative Definition, and an illustrative example would be helpful.

There was an example in an earlier version of the draft (-00) but I disappeared.  I have added it back in.

> 
> UUI can be communicated between an UE and an Application Server acting as a B2BUA, as meets the UAC-UAS requirement, so I believe a statement explicitly stating that should be added to the overview.

Well, in SIP terms, a B2BUA is just a UA, so I don't think it needs to be explicitly stated.  Do you have a particular place in the document where you think this would be best included?

> 
> Complex call center communications can have multiple (3-4) redirections/referrals, so a multiple redirection/referral example would be helpful.

I don't currently have any call flows in this document - I just refer to the ones in the requirements document.  I did add a note saying that multiple redirections are quite possible.

> 
> Is it possible to have multiple UUI headers, either with the same data content encoded differently or with different data content?
> 

Yes, I put in text saying that each package must define rules for this situation.

> What is an intermediary, if it is not a proxy?

It is a proxy, or a border element ( a proxy that sometimes doesn't behave as a proxy).  I think I use the terms the same as they were used in the requirements draft.

> 
> Terminology: the document has UUIs being communicated between UACs and UASs and between endpoints, which is it?

Good catch:  I now just say UAs.

> 
> Considering the same data content could be encoded differently, does this result in multiple UUI packages? And if so, could they be defined in the same RFC?

Yes, I put in a note indicating this.

> 
> Regards,
> 
> Martin Dolly
> Lead Member Technical Staff
> Core & Government/Regulatory Standards
> AT&T Services, Inc.
> [email-masked]
> +1-609-903-3360
> 
>

---

From: Shida Schubert <[email-masked]>
Date: Wed, 14 Mar 2012 19:42:11 +0900

Alan;

 I checked the updates and your comments. 

 I have no more comments. 

 It looks good to me. 

 Thanks & Regards
  Shida