Subject: [Simple] WG Last Call : draft-ietf-simple-data-req-02.txt

From: Robert Sparks <[email-masked]>
Date: 17 Apr 2003 09:27:47 -0500

This is a SIMPLE working group Last Call for comments on
http://www.ietf.org/internet-drafts/draft-ietf-simple-data-req-02.txt

Please review the draft and provide comments by May 5

RjS.

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

---

From: "Thanos Diacakis" <[email-masked]>
Date: Wed, 23 Apr 2003 18:48:52 -0600

A few comments on this:

Nit: 5.1 REQ AP8.  "by by" should be just "by"
Nit: 5.2 REQ N3.  I think "e.g." would be more appropriate than "i.e."

5.2 Additional requirement: "It should be possible for the user to specify a
limitation on the rate of notifications sent to a particular user"

5.3.  Additional requirement: "It should be possible for the user to specify
that a particular tuple be added, removed or modified from the notifications
depending on the values of other tuples.".

Thanos
---
Thanos Diacakis
Openwave Systems
[email-masked]
+1-303 385 6705

----- Original Message -----
From: "Robert Sparks" <[email-masked]>
To: <[email-masked]>
Cc: "Jon Peterson" <[email-masked]>; <[email-masked]>;
"Markus Isomaki" <[email-masked]>
Sent: Thursday, April 17, 2003 8:27 AM
Subject: [Simple] WG Last Call : draft-ietf-simple-data-req-02.txt

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Apr 2003 01:53:30 -0400

Thanos,

Thanks for the comments. Responses inline.

> Nit: 5.1 REQ AP8.  "by by" should be just "by"

Fixed.

> Nit: 5.2 REQ N3.  I think "e.g." would be more appropriate than "i.e."

Right.

> limitation on the rate of notifications sent to a particular user"

While I agree with this as a goal, its something we really dont know how 
to do right now. Work on rate limiting is just beginning, and its really 
not clear how it will work. Rate limiting fundamentally means some kind 
of information loss, so that specifying a rate limit alone is not 
sufficient. You will also need to specify what information is discarded. 
Since the authorization stuff is extensible by design, I would rather 
handle this later, and not in the initial specifications.

> depending on the values of other tuples.".

Can you motivate the need for that? I am trying to keep the initial set 
minimal.

Thanks,
Jonathan R.

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

---

From: "Thanos Diacakis" <[email-masked]>
Date: Thu, 24 Apr 2003 16:58:06 -0600

Thoughts inline.

> handle this later, and not in the initial specifications.

Can you elaborate a bit on the information loss part?  I can see a scenario
where I have a piece of information (a tuple) that changes with an average
period of x, say, seconds.  Wouldn't it be pretty easy to specify a rate
limitation (i.e. a lengthier period of y seconds) which would work as
follows:  if there is a change in the tuple a notification is sent, but only
if the last notification was sent at least y seconds ago.  If the
notification was sent less than y seconds ago, the next notification will
wait until the time is such that the notifications will be y seconds apart.
If an additional tuple is received before such time, the resulting
notification would replace the one that was queued.

> Can you motivate the need for that? I am trying to keep the initial set

I was thinking of something along those lines: If my location tuple shows
"home" then add my home phone tuple to the presence doc, whereas if I'm at
work add my email tuple.  Or if I am available by IM, stop publishing my SMS
tuple.

Thanos
---
Thanos Diacakis
Openwave Systems

---

From: Ben Campbell <[email-masked]>
Date: 25 Apr 2003 13:38:47 -0500

General: Although there are a couple of extensibility requirements, I am
a litte concerned that this document is too focused on current concrete
data requirements, and not enough focused on abstracting these data in a
more extensible way. I cannot imagine that we can predict the data needs
of every deployed system in advance, but I would expect the data
_mechanism_ to be extensible to types of data we have not yet thought
about.

For example, there was considerable discussion about default presence
documents on a different thread, where several people suggested that
configuration of these defaults should be a data manipulation mechanism
requirement. But that is not listed in this doc, nor do I see any
extensibility requirement that leads me to expect that the mechanism
must be extensible to handle this class of data. (There is a requirement
about choosing the presence doc a user sees in the authorization
section, but it is not clear to me if that was intended to meet this
requirement.)

I think this document could use some more explicit scoping language.
There are some requirements that are to be applied to events other than
presence, and others that appear to be presence specific. This should be
stated explicitly.

PC-1 - The wording can be interpreted to imply a single presentity
collection. I think it must be possible to create multiple collections
with distinct URIs. Later requirements seem to support this, but it
should be explicit.

PC-2 and 3: These seems like mechanism rather than requirement. Why is
necessary for the protocol to allow both approaches?

PC-5: There is nothing inherent in a URI that tells you if it represents
a list or a single presentity. The only way to implement this would be
to actually attempt a subscription, which I doubt is your intent. Do you
mean this as a way to control where the supported header for lists is
used? If this is a real requirement, it may force new requirements on
the list draft.

PC-10: May need to break this up into read and write access, etc. You
may want to have users who can read the collection contents, but not
change it.

PC-12: I don't believe cached lists necessarily imply a requirement for
change notification. The real thing that forces this requirement is the
ability for the list to be changed by some other actor than the client
while the client is running. If this is the intent, then we need a
requirement for it.

PC-15: Unless there is an assumption that the protocol cannot offer any
feature not listed as a requirement, then MAY requirements are not
useful in a requirements document. If this is important enough to
mention, it probably should be a SHOULD.

PC-21. I think this requirement needs more justification. In fact, we
should probably back up and look for root requirements behind it. What
is it you want to accomplish with a proxy? For example, if it is for
firewall traversal, then the requirements should be about firewall
traversal--and proxies might be a mechanism to accomplish that.

PC-22: (nit) this seems out of place--it should be grouped with the
other manipulation requirements.

PC-23: I think we should separate intermittent and low bandwidth into
two requirements. Also, it might be useful to define what sort of
bandwidth is considered low--newer wireless devices are every bit as
fast as an average dial up connection.

PC-24: This looks suspiciously like one of those "you can't make us
implement multiple protocols in a client" requirements, which are
generally looked upon with skepticism in the IETF. Do we want this to be
a general directory interface? Also, this requirement would seem to
imply we need to be able to create entries to which we do not intend to
subscribe. 

PC-25: (nit) out of place. (see comment on 22)

5.1: I think we need a requirement allowing for wildcards in blocked and
allow lists. For example, allow everyone in my domain...

g-5 (and previous similar) I really think this should be a SHOULD, not a
must. That is, I would really hate to reject some existing protocol for
the sole reason of it using a different authentication scheme than SIP.

7: To Do items need to be closed before progressing the draft.