Re: [Sipping] Re:draft-johnston-sipping-cc-uui-00.txt

[Paul Kyzivat <[e-mail]>]

Alan Johnston wrote:
> Paul,
> 
> Thanks for the comments on the draft.
> 
> I will add text to better describe the applications that could benefit 
> from this mechanism. 

Does that mean explaining what UUI means? Your existing examples all 
show the value being an opaque string. Is this because it is an 
encoding? If so, is it widely understood, or is that an agreement 
between source and destination?

Because there is only *one* string, I am left assuming that there might 
be several data elements hiding inside the encoding. If that is the 
intended usage it would be helpful for that to be clear. Maybe an 
example could show the real data, an then how that data is conveyed in 
encoded form. Unless there is a good reason for encoding then it might 
be better to pass multiple parameters that are not encoded.

> It is true that not all UAs handle escaped header 
> fields in URIs, although the use of this in common applications such as 
> transfer is spreading.

I'm also curious about the security issues of passing the data via the 
UAC. Could you address that in some way? Maybe there is no concern, and 
it is ok for the UAC to read and update the values. Or maybe the 
assumption is that the data is encrypted so that the UAC cannot 
understand or change it, and that the recipient will be able to know if 
it has been removed entirely. But whatever it is, would be helpful to 
have explanation.

	Thx,
	Paul

> I'll fix the syntax issues so the header can be repeated.
> 
> Thanks,
> Alan
> 
> Paul Kyzivat wrote:
>> Hi Alan,
>>
>> It would be helpful if this draft defined what is meant by User to 
>> User Information.
>>
>> I infer from the examples that it is information gathered by the ACD, 
>> or perhaps info the ACD derives based on what it can gather during its 
>> early dialog, that it wants to convey to the Terminator. So in this 
>> case the first user is the ACD and the 2nd user is the Terminator.
>>
>> The use of header parameters in the Contact or Refer-To, while it 
>> might work in theory, seems questionable in practice. The passing of 
>> such parameters is optional, and likely not to be honored in many 
>> cases. At least that isn't needed when the ACD acts as a proxy.
>>
>> I would think another issue about the cases where the information is 
>> relayed via the Originator is that it then gives the originator an 
>> opportunity to examine and modify it - which may not be desirable.
>>
>> The syntax of the proposed header seems pretty restrictive. I'd be 
>> inclined to at least include standard comma syntax so that the header 
>> can be repeated to allow multiple tokens. And since there really isn't 
>> any way to negotiate between the sender and the recipient, it might be 
>> useful to have a way to denote the namespace of the value so that 
>> there isn't a question about how they it is interpreted. For this 
>> application I would expect that unambiguous namespace identifiers 
>> should be easily minted by those deploying the system. Perhaps URNs 
>> would fill the bill for that.
>>
>>     Paul
>>
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments of core SIP
>>
>>
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP