Subject: RE: [Simple] comments on rpids-01 (general, vCard, predictive)

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 26 Jun 2003 18:01:12 -0500

> 
> Also, as a minor issue, splitting the document into many namespaces 
> increases the presence (not I-D) document size, since each namespace 
> needs to be referenced. The namespace length could easily exceed the 
> 'payload' length. I doubt that compression would help much here.
> 

Well, yes, it's one line of XML per import. We're not talking about hundreds
of lines here I think, and especially given that at least some transitive
importing would undoubtedly take place.

> I also fail to see the value of dividing the presence information into 
> numerous tiny bits since senders and receivers can ignore information 
> that they do not have, do not want to reveal or do not want to present. 
> All information in RPIDS (or any of its sub-cousins) is optional and 
> complementary.
> 

True - but at some point I imagine there will be an injection of normative
behavior into these schema descriptions.

> The only valid reason that I can see for splitting the document is if 
> there are vastly different levels of maturity, i.e., where one element 
> is very well understood, while others are considered worthwhile, but the 
> general feeling is that their representation would change drastically 
> given another year of thinktime.
> 

We have already consumed a year or so of thinktime about this. Amazing how
time flies...

[snip]
[on calendaring]:
> 
> I also strongly disagree with Jon here. These were discussed extensively 
> among the authors as being useful and easily derivable. I believe they 
> pass the "well understood" test.
> 

Well, we discussed issues with predictive presence in some detail in Ottawa
- I don't know if you were on the line then or not. There are some minutes
from the discussion here, starting in about a page or so:

http://www.softarmor.com/simple/meets/interim2003/notes/campbell-0530pm.txt

[Note that softarmor hasn't been feeling well, and may be down for
maintenance at the time you receive this]

The key issues seemed to be deciding which presence took priority when
calendar information conflicted with other information, deciding what 'human
authorization' of the "correct" presence information meant, sequencing
presence information when predictive presence is available (i.e. when does a
calendar start publishing information), how to handle these cases with
aggregate presentities, handling dueling automata and/or calendars, and so
on.

Personally, I saw a lot of complexity here, and the resolution to these
issues was unclear. I did not get the sense that this was well understood.

> 
> RPIDS does not include the vCard, it includes a reference to it.
> 

As does Call-Info.

> 
> > On this one, I'm going to agree, somewhat reluctantly.  These are
> > not presence, they are really user identification (more detail
> > than "display name").  My reluctance is that we need icon for
> > a real IM system, and we have needed vCards for some time in SIP,
> > and there isn't any other place they are being standardized.
> 
> Since not all systems will use SIP, I don't see how there is an existing 
> mechanism for these. 

I thought the 'S' in 'RPIDS' stood for SIP. The point being that as we
define these extensions, I totally agree that we should define them to be
useful outside the scope of SIP whenever possible. But, I don't think that
means that we should build systems that are redundant with existing SIP
functionality. Our current job is provide a set of tools suitable for
constructing a specific commercial application, which is a SIP application.

In other words, the Call-Info method of delivering vCards and icons
shouldn't be ruled out on the grounds that some protocol other than SIP
can't available itself of it.

> Among the mechanisms, the icon is probably the most 
> useful, since it can change fairly frequently and belongs to the 
> application (while vCards are more generic and indeed may well be 
> deferable). One motivation is that this allows an easy mapping from SIP 
> information to presence document information. With merging of multiple 
> tuples, the information can't be included directly in the SIP NOTIFY 
> request.
> 

Yes, I had considered this case. It is meaningful especially in cases of
'aggregate' presentities, where one or more persons publish presence
information under a single AoR. Personally, I remain uncomfortable with
those cases (as well as with merging tuples overall) largely for reasons of
managing e2e security and compositor authorization behavior, but I recognize
that the approach I suggest wouldn't accommodate that model.

But as I suggested earlier, for existing applications, in my experience
icons are more commonly associated with messaging channels than with
presence. When you open a messaging channel to any contact in a presence
document, your INVITE could carry Call-Info with an icon. So the question
becomes, is an icon a requirement for the overall application, or a
requirement for presence documents? I don't see why presence has to be the
carrier of this reference.

- J

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 19:17:30 -0400

> behavior into these schema descriptions.

I don't think it is realistic to assume that any of these elements will 
ever be mandatory, simply because it's very clear that there will always 
be circumstances where any one of the elements is either unknown or the 
presentity has good reasons not to want to disclose that element. I 
would agree that any RPIDS element that is mandatory should indeed be in 
its own namespace (and probably document). I don't see any here, but 
maybe you can provide an example?

Thus, I don't understand how this 'injection' should happen, given that 
there are no 'MUSTs' or even 'SHOULDs' in the RPIDS document, as far as 
content goes.

> We have already consumed a year or so of thinktime about this. Amazing how

Indeed, that's another reason not to delay further unless there are 
content concerns.

> aggregate presentities, handling dueling automata and/or calendars, and so

This is a generic issue, as soon as you have *any* automatically 
generated data. I think these are either policy issues or configuration 
issues. In other word, not requiring standardization. For example, the 
'lookahead' can be easily configured and is matter of choice for the 
presentity. Interoperation is not endangered by whether I choose to 
advertise my whereabouts for the next month or the next ten minutes.

Similarly, as Brian and other have pointed out, any automatic 
information will occasionally be wrong (but they believe, if I interpret 
them correctly) that the probability of correctness is higher. In 
general, I tend to favor "automatic with override" on all elements, but 
that's again a policy issue. Others might want "automatic with mandatory 
approval" or "hey, it's a guess anyway".

>>RPIDS does not include the vCard, it includes a reference to it.

There are several reasons that Call-Info is not appropriate in all 
cases. I mention one below, but my goal is still, despite its current 
home, to make RPIDS useful in non-SIP context.

> can't available itself of it.

Agreed; as I noted, with composition, Call-Info won't do the trick, so 
this is just another reason.

This is an element where I agree this can be considered borderline.

> carrier of this reference.

Particularly for complicated presence documents, a presentity-supplied 
icon may well be the best short-hand for a tuple since it can capture 
information that is hard to express otherwise. (Well, beyond the "beach 
with sunset" rubbing in that the presentity is on vacation and the 
watcher is not...) Existing presence systems don't have multiple tuples 
for each presentity, so this less of an issue. I don't see how a 
message-based icon in messaging helps with rendering presence status in 
a quick-to-grasp form.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 26 Jun 2003 19:17:30 -0400