Subject: RE: [Simple] Tuple design team discussion summary

From: Adam Roach <[email-masked]>
Date: Mon, 14 Jul 2003 08:47:10 -0500

Jonathan Rosenberg [mailto:[email-masked]] writes:

> So, I think there is value in having an RPIDS attribute which conveys 
> some kind of information about what the tuple represents. We 
> can start 
> with a basic set of types:
> 
> "cell phone"
> "PDA"
> "wireline phone"
> "IM service"

It's not clear that tuples can always be classified as
something this concrete, though. What if I want to publish
a single tuple that represents an amalgamation of my presence
status, for example? Two tuples, with one representing my
"work" devices, and one representing my "personal" devices?

I think one of the important drivers behind not mandating
a particular binding of a tuple to something like a device
is that doing so provides infinite flexibility in publishing
information. It seems that having a canonical (even if
expandable) set of blessed "types" of tuples will restrict
this flexibility unnecessarily.

/a

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:51:13 -0400

inline.

> "work" devices, and one representing my "personal" devices?

We can either add that to the list of labels now, or it gets added 
through a registry.

> this flexibility unnecessarily.

Unlimited flexibility can also lead to interoperability problems, and 
this is the essence of what Brian has been complaining about, I think. 
Its not all or nothing. There is a reasonable point of compromise 
where we allow some flexibility but introduce some constraints. 
Finding that right point is what engineering is all about.

I think that we can standardize a bunch of labels which cover a lot of 
common cases. If someone wants to send a presence document with a 
tuple outside of one of those categories - fine. Don't use the label. 
But, it may not be handled well on a device that can't display 
anything to the user except an iconic representation of that label.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 20:51:13 -0400

inline.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 03:25:42 -0500

On Mon, 2003-07-14 at 19:51, Jonathan Rosenberg wrote:
[...]
> anything to the user except an iconic representation of that label.

I think even that can be handled cleanly. Such a device just displays 
some default icon that indicates it does not know what type of tuple it
has. That is no different from common usage in many other applications.
For example, email attachments when your browser does not recognize the
mime type, or gets something completely generic like
application/octet-stream without any other qualifiers.

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 03:25:42 -0500

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 04:38:21 -0400

Almost none of the labels in RPIDS are exhaustive or claim to be, so a 
list is better than nothing. To make progress, I would like to call for 
nominations for such labels. The obvious ones are device-oriented ones
   cell phone
   PC
   landline phone
   text device (BlackBerry, SMS, TTY, ...)
other suggestions?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 04:38:21 -0400

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 03:53:55 -0500

Hopefully we can generalize these a bit. For example:

voice device
Mobile voice device
Fixed voice device
Workstation (or some sort of rich media device)
text device
short text device (i.e. don't send me big stuff)

This list seems to me to break down to a few dimensions:

Mobility
Media
stream/message orientation
Size limits

Which sound a lot like capabilities to me.

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 03:53:55 -0500

voice device
Mobile voice device
Fixed voice device

Mobility
Media

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 04:16:28 -0500

(Replying to self) 

Ah, I see Henning already mentioned this in a previous note. Apologies
for creating meme loops by reading out of order.

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 04:16:28 -0500

(Replying to self)

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 05:22:06 -0400

As I noted earlier, I see no point in having a label that is simply the 
combinations of existing RPIDS fields that the receiver can also combine 
into a label.

> Hopefully we can generalize these a bit. For example:

capability = audio, mobility undefined

> Mobile voice device

mobile, audio

> Fixed voice device

fixed, audio

> Workstation (or some sort of rich media device)

fixed, audio, video, text

> text device

*, text

> short text device (i.e. don't send me big stuff)

shouldn't that be a capability addition? (I'm not sure if this should be 
a qualitative or quantitive capability.)

> Which sound a lot like capabilities to me.

I'm not sure if you're agreeing that the proposed labels are merely 
re-stating information that's already available or if they are useful.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Jul 2003 05:22:06 -0400

mobile, audio

fixed, audio

*, text

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 04:27:17 -0500

> combinations of existing RPIDS fields that the receiver can also combine 

Yes. I was badly attempting to agree with that point.

> re-stating information that's already available or if they are useful.

I am agreeing with the former.

---

From: Ben Campbell <[email-masked]>
Date: 15 Jul 2003 04:27:17 -0500

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 10:48:25 -0400

I find it attractive to expect client devices to synthesize icons (if 
they want them at all) from combinations of capabilities that they find 
interesting. Devices with limited capabilities will only be interested 
in a few capabilities of the tuple, and can probably synthesize them 
into a unique icon that fits the geometry of the device. More powerful 
devices (e.g. pc) may be interested in a wider variety of capabilities 
of the tuple. This makes it problematic to combine all into a single 
useful tuple. But in that case there is probably room to render multiple 
icons, for individual capabilities, or for interesting subsets of 
capabilities.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jul 2003 10:48:25 -0400

Paul

---

From: Michael Hammer <[email-masked]>
Date: Wed, 16 Jul 2003 09:57:38 -0400

Ben,

I am unclear whether this line of thought was abandoned or not.
If not, then I have some questions:

Mobile v. fixed:  Do you anticipate that what is today called "fixed 
wireless", i.e. 802.11 will fall into the mobile category, when they figure 
out how to do roaming, then handoff?  Would not Wireless, Roam-capable, and 
Handoff-capable be better descriptors?  Is that what is important?

Or, is mobility really just a short-hand way of indicating that there are 
BW constraints (which may or may not occur depending on whether it is truly 
broadband or not)?  Is this really, just a size limit question.

Text:  Given that deaf folks think IM and TTY are very different, does that 
need to be discriminated?  Do you need to discriminate between different 
degrees of immediacy:  TTY v. IM v. slower SMS v. email?  Is it the size 
(BW) that is of concern or is it the expectation of interactivity?  Is that 
what stream/message intended to convey?

Mike

---

From: Michael Hammer <[email-masked]>
Date: Wed, 16 Jul 2003 09:57:38 -0400

Ben,

Mike