Subject: RE: [Simple] modeling dispatchers in the data model: a proposal formoving forward

From: [email-masked]
Date: Mon, 10 Jan 2005 12:59:00 +0200

Hi,

I think that the proposal looks quite promising. However, I would like to clarify some points.

As I understood the proposal, the use of <contact> wrt. tuple identification and composing would remain as it currently is in the data model. This means that each tuple in the presence document must have a unique <contact>, and if the compositor gets multiple tuples with equal <contact>, it will forward only of them, by default the latest, i.e. an explicit override operation would be possible. Is this correct? How about the URI comparison issues beyond SIP that Henning has brought up?

<i-belong-to> would be a new attribute that could be used instead of <contact> in case it is not possible to generate unique contacts. So, for instance in Rel 6 IMS, where GRUU is not supported, service tuples would typically contain only <i-belong-to> with an AoR, but no <contact>. The default composer policy would be to just union those tuples, i.e. forward everything.

Jonathan Rosenberg wrote:
> > A dumb composer can always union. A smarter composer can 
> use the service 
> > URIs in the <contact> if present, in combination with the 
> <i-belong-to> 
> > information to correlate the services together. It could 
> then produce a 
> > tuple with the AOR in the <contact> and no <i-belong-to>.

I suppose this means a case where the contacts are unique? I don't quite understand WHY the composer should ever do this kind of combination. If the tuples really represent different applications or different preferences, doesn't the combination loose this important information? It seems smarter to forward all the information to the watcher. In case some contacts are equal, the composer overrides the older tuples with the latest ones, right?

I suppose the case where there would be two tuples with equal <contact> but a different <i-belong-to> is quite peculiar (but is it an error?). In that case the composer would by default still look only at the <contact> and would choose the latest tuple?

Jonathan Rosenberg wrote:
> > I would be amenable to defining some kind of additional ID 
> that serves 
> > to identify a tuple uniquely when the <contact> is not 
> present. This 
> > would allow override even for tuples with no contact (as 
> those published 
> > from a PUA not supporting gruu).

Yes, I support this too. In case that both <contact> and this additional ID are present (would that even be allowed?), I suppose <contact> would take presedence in the composer policy?

Henning Schulzrinne wrote:
> - Since existing non-RPID system won't know about <i-belong-to>, 
> composers MAY do simple union (keeping tuples with identical 
> Contact and 
> maybe a different <note> element to avoid information loss) 
> or MAY apply 
> a smart composition policy that somehow merges the two 
> same-contact tuples.

This would bring back some ambiguity. Could we just put a note in the draft/RFC which says that there are some pre-standard systems that are likely to do this, but this would still not be even MAY in _this_ spec? 

Markus

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Henning Schulzrinne
> Sent: 09 January, 2005 01:20
> To: Jonathan Rosenberg
> Cc: Simple WG
> Subject: Re: [Simple] modeling dispatchers in the data model: 
> a proposal
> formoving forward
> 
> 
> I'm generally happy with that proposal as a way to move forward. More 
> information for the watcher allowing correlation is always a 
> good thing.
> 
> I think this means in more detail:
> 
> - Use of <i-belong-to> is RECOMMENDED.
> 
> - PUA SHOULD publish distinct contacts, which MAY share the same 
> <i-belong-to> element value.
> 
> - Since existing non-RPID system won't know about <i-belong-to>, 
> composers MAY do simple union (keeping tuples with identical 
> Contact and 
> maybe a different <note> element to avoid information loss) 
> or MAY apply 
> a smart composition policy that somehow merges the two 
> same-contact tuples.
> 
> The content-selection HTTP URIs I mentioned earlier may not 
> have contact 
> URIs as such (they sometimes do, typically in file-based systems), so 
> this is a bit SIP-specific.
> 
> Jonathan Rosenberg wrote:
> 
> > Let me make another proposal, which is a variation on the 
> dispatcher 
> > model I suggested, modified by an idea Henning proposed.
> > 
> > When a PUA publishes a tuple about itself, the <contact>, 
> if present, 
> > still needs to route to itself. However, we also define an 
> additional 
> > presence attribute called <i-belong-to> (suggested by 
> Henning), which 
> > contains a URI which routes to a dispatcher through which 
> that service 
> > might be reachable. In the SIP case, this could contain the AOR.
> > 
> > Thus, one could build a PUA which publishes about itself. It has no 
> > GRUU, so it omits the <contact> URI and includes <i-belong-to> 
> > containing the AOR.
> > 
> > Another smarter PUA would include the GRUU in the 
> <contact>, possibly in 
> > addition to <i-belong-to> with the AOR.
> > 
> > A dumb composer can always union. A smarter composer can 
> use the service 
> > URIs in the <contact> if present, in combination with the 
> <i-belong-to> 
> > information to correlate the services together. It could 
> then produce a 
> > tuple with the AOR in the <contact> and no <i-belong-to>.
> > 
> > The current contract and meaning of the <tuple> as a 
> service remains as 
> > it is in the PDM. However, we now have the case where there 
> is a tuple 
> > describing a service that is not directly reachable. The 
> watcher knows a 
> > URI through which it might be reached, and can render or 
> combine those 
> > together in whatever way it sees fit.
> > 
> > In the future, we could define this dispatcher service so 
> that a watcher 
> > could even learn the policy governing how the dispatch is done.
> > 
> > I think this is simpler than my original proposal, has the 
> benefit of 
> > maintaining the union operation as the default composition policy, 
> > retains the semantics of the service tuple as currently in the PDM.
> > 
> > I would be amenable to defining some kind of additional ID 
> that serves 
> > to identify a tuple uniquely when the <contact> is not 
> present. This 
> > would allow override even for tuples with no contact (as 
> those published 
> > from a PUA not supporting gruu).
> > 
> > Is that more palatable?
> > 
> > Thanks,
> > Jonathan R.
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 10 Jan 2005 17:54:00 -0500

> latest, i.e. an explicit override operation would be possible. Is
> this correct? How about the URI comparison issues beyond SIP that
> Henning has brought up?

While I think that the <i-belong-to> makes it easier to avoid contact 
duplication, I don't think we should (nor need to) rely on contact 
uniqueness. The behavior of the client is clearly defined even if an 
(accidental) duplication occurs. As far as I can tell, there is 
"ambiguity" in the sense that the client is confused as to the true 
state of the world. The client may not actually get to pick among the 
possible choices, but no presence system can prevent that unless you 
assign a unique URI to each mutually-exclusive set of capabilities, 
including codec exclusions. (For example, while it may be possible in 
theory to get both audio and video for a tuple indicating such 
capability, with my particular combination of available codecs, only 
audio may be possible. Presence isn't going to fix that.)

> I suppose this means a case where the contacts are unique? I don't
> quite understand WHY the composer should ever do this kind of
> combination. If the tuples really represent different applications or
> different preferences, doesn't the combination loose this important
> information? It seems smarter to forward all the information to the
> watcher. In case some contacts are equal, the composer overrides the
> older tuples with the latest ones, right?

Maybe one general guideline is that composers shouldn't try to be 
smarter than watchers unless they really know they are and are the only 
ones that can prevent providing wrong (rather than just uncertain) 
information.

The flip-flopping behavior that mechanical last-wins composition by URL 
induces seems far worse and more confusing than showing the watcher that 
he might get one or the other. Something like

18:01  sip:[email-masked]  audio
replaced by
18:02  sip:[email-masked]  video+audio
replaced by
18:03  sip:[email-masked]  text
as the PUAs battle it out

seems rather confusing to the watcher, compared to

[constant] (sip:[email-masked]  audio +
             sip:[email-masked]  video+audio
             sip:[email-masked]  text)

>> Contact and maybe a different <note> element to avoid information
>> loss) or MAY apply a smart composition policy that somehow merges
>> the two same-contact tuples.
> 
> 
> This would bring back some ambiguity. Could we just put a note in the
> draft/RFC which says that there are some pre-standard systems that
> are likely to do this, but this would still not be even MAY in _this_
> spec?
> 
See above.