Re: [Simple] Updated RPID

[Henning Schulzrinne <hgs at cs.columbia.edu>]

> We discussed this extensively on the design team.

Probably in a somewhat different context, at least from my recollection 
of the discussion.

> It was concluded that we could support the reporting of conflicting
> information downstream, in later extensions, by inclusion of multipel
> values for a particular element along with its source. That meant that
> the baseline mode of operation was kept simple. Given the confusion
> we've had all along about interpretation of data in multiple places, the
> tradeoff seemed appropriate.

This is different. It simply includes the data with the source tuple 
that generated it. This is no more complicated than the alternative 
approach, and in the absence of a defined composition operation, almost 
unavoidable. In practice, with all existing and plausible near-term 
composition operations (which will be effectively some form of union or 
concatenation), this will occur whether we allow for this or not. It is 
fairly straightforward, for the policy rules, to define algorithms that 
take these cases into account, and work for the desirable case of no 
conflict. (For example, the "matches if all instances match" is a 
privacy-safe example of such a rule.)

This does not mean that any element type can or should contain any RPID 
element.

Indeed, if we don't allow for this now, even without the source 
identification, we may not be able to do this later, due to the policy 
rule issues, in particular.






_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple