Subject: [Simple] comments on draft-ietf-simple-cipid

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Feb 2004 16:58:36 -0500

Some comments on the draft:

1. Its unclear where these attributes are intended to live within a pidf 
document. Is the assumption that there would be a tuple representing the 
presentity, and that these attributes would live there? Can they be part 
of a tuple representing an IM service or a cell phone?

2. I recall having a discussion about whether vcards should be in-band 
or fetched via a reference; it seems to me that it would not be so bad 
to allow them to appaer within the presence document rather than via a 
reference.

3. For the icon, I think you need to say a bit more about size 
constraints, allowed formats, etc. Here, the image is likely to be 
processed by an automata (for example, by including as a specific part 
of a user interface), and therefore we need to be careful about defining 
details.

4. I'm not a vcard expert - cant homepage be part of a vcard also?

Thanks,
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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2004 18:59:20 -0500

> of a tuple representing an IM service or a cell phone?

I suppose this is part of the 'what's-a-tuple' discussion, although I 
tend to think that we don't really need to know what exactly a tuple is 
to answer your question, just that there will be some tuples where this 
information is likely to be not particularly useful. I don't think it 
has to be presentity, as associating vCard information with a device 
could be nominally useful in some circumstances.

There seem to be two approaches:
(1) try to nail down what type of tuples can take this information;

(2) allow users to make that choice, under the assumption that it's 
usually pretty obvious in a specific case what information makes sense 
(and it's harmless if somebody attaches it to some entity where its 
utility or meaning is dubious).

Unless somebody has a crisp formulation for a rule for (1) that is 
machine-testable, I'd be happy with (2).

One possible rule is to build in a dependency on RPID: CIPID information 
can appear if the contact-type is in-person, presentity or service (?), 
but not for 'device'.

> to allow them to appaer within the presence document rather than via a 

This is always possible using one of two mechanisms: data URLs (RFC 
2397) or attachments (cid/mid, RFC 2392). Is there sufficient value to 
allow literal inclusion as an XML string? (Since this is much simpler to 
deal with than mid/cid and probably significantly more efficient than 
data URL due to the encoding needed for those, this might be a good idea.)

One argument for favoring reference is that in many cases, the recipient 
already has this information, so sending it again and again for each 
subscription or notification is inefficient.

> of a user interface), and therefore we need to be careful about defining 

We can mandate support for PNG, JPEG and GIF, if that's acceptable. I'm 
not sure if mandating a maximum size makes as much sense since the 
receiver can always scale it down; an icon that looks tiny on an 
1600x1200 display is probably too large for a 320x240 PDA screen.

> 4. I'm not a vcard expert - cant homepage be part of a vcard also?

Yes, http://www.ietf.org/rfc/rfc2426.txt has that in Section 3.6.8.

If vCards are by reference only, it gets rather awkward to define a 
simple URI. This is less of problem if we allow direct textual inclusion.

I'm happy to omit this if we can find a solution that doesn't require using

data:text/directory,BEGIN:vCard%0AVERSION:3.0%0AURL:http://www.example.com/%0aEND:vCard

(I probably missed some escaping here...)

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2004 18:59:20 -0500