Subject: RE: [Simple] comments on rpids-01 - <info>

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 27 Jun 2003 23:25:52 -0400

> > I would remove <info> - if <note> from baseline PIDF doesn't suffice for
> > this, I'm really missing something here. <info> would provide an
alternative
> > that would not be compatible with baseline PIDF. I don't think the
advantage
> > that it offers a URL to a web page is, in itself, sufficient
justification
> > not to use <note> instead. Just put your URL in the <note>.
> 
> I dislike having to guess, email-reader-style, what are URLs and what's 
> plain text by do regular expression matching. With the info URL, a 
> watcher can automatically underline the presentity name as a link, for 
> example. Can't do that with <note>. 

Well, I meant this 'put the URL in the <note>' pretty off-handedly. I was
suggesting that if there were some rich content behind a URL, you could
still make the URL available to watchers in a backwards-compatible way. In
my experience, email readers don't exactly seem to struggle with this
capability today afaik - it's pretty easy to recognize what is or is not a
URL. But I guess this is really secondary to my point - my point is that
<note> and <info> share the same motivation given rpids-00 today, and that
thus it's hard to see why <info> isn't just a non-backwards-compatible
sidestep around <note>. Putting a URL in a <note> is just more backwards
compatible, since then at least baseline PIDF implementations will be able
to perceive the URL.

The example application behavior you suggest, underlining presentity names
and so on, doesn't seem entirely dissimilar to how I imagine <note> will be
implemented in some systems. 

> In general, I'm trying to have 
> semantically labeled information, so that watcher or other elements 
> don't have to do natural language processing. 

That is of course a laudible goal, but this is an instance where you want a
lump of general information about the tuple to appear. The fact that you
want to include it by reference, as opposed to by value, doesn't seem that
material to me, in so far as carrying it by value is more PIDF-compatible.

> This also makes filtering 
> a whole lot easier. I can much more readily remove information as a 
> watcher and as a presentity if it is labeled by category rather than 
> being all piled into one catch-all field. 

This is an argument for not including, say, <privacy> and <placetype> in
<note>, but I'm not sure it's as compelling as an argument for introducing
an alternative to <note> itself. What would you be filtering out, the <info>
element itself? Not for size reasons, I'd have to think.

> As an example, if my bandwidth 
> is such that I really don't care about anything but the bare basics, I 
> would strip the <card>, <info>, <activity>, etc. in my subscription 
> filter, but <note> seems like something that has to remain since it 
> likely conveys special information that I need to know.
> 

I'm not sure why <info> would be any different from <note> in that regard.
Why am I including this URL if it doesn't contain information relevant to
watchers about this tuple? But given the description in rpids-00, it does
provide info relevant to watchers about this tuple.

What I'm concerned about here is that there are two elements - <note> and
<info> - that do the same thing, according to their respective
specifications. As it's written, <info> provides "general information about
the tuple", and <note> in a tuple provides "a comment" "regarding the
particular tuple". So when you have some information about a tuple, do you
put it in a <note> or an <info>? 

If the answer is "both", that's bad because it's redundant, and <info> adds
no real value. If the answer is "some or all information appears only in an
<info>", that's bad because it's not backwards compatible. The only good
answer seems to be "only in a <note>".

The only semantic for this that doesn't seem bad as if <info> were to mean
something different that the current description in the draft. If it meant,
for example, "homepage of the presentity", that would be a different story -
but then I'd want it to be called <homepage>, not be scoped to <tuple>, etc
(and get back on my hobbyhorse about what is and is not presence
information, probably). As it stands, though, I don't see the justification
for it.

Jon Peterson
NeuStar, Inc. 

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

---

From: [email-masked]
Date: Mon, 30 Jun 2003 10:48:06 +0300

<info>, just like <icon>, can have a cid as a URI in a multipart/mixed body, something the <note> doesn't allow (I would assume).

/Hisham

> -----Original Message-----
> From: ext Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, June 28, 2003 7:28 PM
> To: Peterson, Jon
> Cc: Simpletons (E-mail)
> Subject: Re: [Simple] comments on rpids-01 - <info>
> 
> 
> Not really; <info> is information about the presentity, as a URI.
> 
> URIs in <notes> can mean many different things, as in
> 
> "See the nice place that I'm spending my vacation: 
> http://www.indo.com/geo/sunsets.html and 
> http://www.indo.com/hotels/puri_bambu/"
> 
> Apparently, putting cute or witty "away" messages in IM 
> systems is all 
> the rage on campuses. This has nothing to do with describing the 
> presentity itself.
> 
> > 
> In most interesting cases, this is not feasible.
> 
> 
> Think of this as "this is a link to information describing the tuple".
> 
> The reason for reference instead of value is simply efficiency.
> 
> 
> In some cases, an automated device may filter the <note> and keep the 
> <info>, for example.
> 
> 
> 
> 
>

---

From: [email-masked]
Date: Mon, 30 Jun 2003 10:48:06 +0300

/Hisham