Subject: [Simple] RE: Comments on draft-ietf-simple-data-req-02.txt

From: [email-masked]
Date: Fri, 13 Jun 2003 02:26:58 +0300

Hi,

I'll be working on a new version of the data manipulation requirements draft. During the WG last call there were basically only two comments to the -02 version of the draft, one from Ben Campbell and the other from Krisztian Kiss. I'll answer both separately to try to establish concensus on the points raised in them. (To my knowledge 3GPP CN1 WG is also reviewing their specific reqs to data manipulation, so if there is something specific, please send that to the list too.)

The main scoping issue is whether to inlude the default presence document publishing/upload reqs in this document, or should they be separated. My assumption would be to have a separate reqs draft for them, but I would be happy to incorporate them in this doc as well, if people prefer that.

Comments to Ben inline: 

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: 25 April, 2003 21:39
> To: Isomaki Markus (NRC/Helsinki)
> Cc: Simple WG
> Subject: Comments on draft-ietf-simple-data-req-02.txt
> 
> 
> 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.
> 

Personally I completely agree with you. However, I think the scoping of this initial SIMPLE data manipulation work was discussed a couple of times last year, and the conclusion was that for now we should focus on requirements for presence list and presence authorization policy management, as stated in the charter. So, the scope of this draft is that, not data manipulation in general. Having a protocol such as XCAP for doing these operations does allow flexibility, and I think separate requirements drafts for new XCAP application usages would be fine, such as for default presence state publishing.

> 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.)
> 

These are good points and I belive the concensus definitely is that default presence document uploading will be done with the same data manipulation solution (in practice XCAP). This is not in the scope of this requirements draft, however. I think we need separate reqs for that (that can be very short, and should be done quickly), and for other data manipulation usages in the future too. 

> 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.
> 

OK, I think that the scope of this draft should be presence, even though it is easy to see that the same reqs could apply to SIP events in general.

> 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.
> 

Yes, I think a user should be able to have multiple presentity collections.

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

In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both ways possible.

> 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.
> 

I think you are right. URI for a list is exactly similar to URI for a single presentity. So in all cases clearly this req can't be met. Unless someone has a good reason for keeping this req as it is, I'll reword it. I think a more relevant req is that a presence list can be hierarchically structured, as in XCAP presence list usage proposal. 

> 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.
> 

Agreed. I'll add that.

> 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.
> 

Agreed. Change notification is needed since multiple clients may be manipulating the same data, while they are on-line. I'll reword the reqs.

> 
> 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.
> 

OK.

> 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.
> 

True. Firewall traversal is probably one thing that would be beneficial, also I think something like compression and security association sharing (one client using multiple servers) on the first hop would be derirable features, that proxy allows, so at least for me it would be OK to enumerate the real needs separately. 

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

OK, will be moved.

> 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.
> 

Right. Even though I'm very much involved with wireless devices I'm not sure if this kind of requirement is really quantifiable. It might be best to speak about ability to compress and aiming at efficient encoding.

> 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. 
> 

I think this could be a SHOULD-level requirement. I think it makes sense that a user can share lists among multiple applications, so that the "master-copy" is in some kind of phonebook, but it is not completely clear to me how much this is just implementation issue. In practice I think this means that it MUST be possible to have links to data elsewhere within the presence list structure. Would that sound more reasonable?

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

OK.

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

True. However, I think we could limit the support to just that: allow everyone in some domain, and not make this completely generic, for simplicity, and just to support the real need.

> 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.
> 

I think you mean G-6. Agree, can be SHOULD.

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

OK.

Markus

> 
> On Thu, 2003-04-17 at 09:27, Robert Sparks wrote:
> > 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
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Ben Campbell <[email-masked]>
Date: 13 Jun 2003 10:25:35 -0500

On Thu, 2003-06-12 at 18:26, [email-masked] wrote:

[...]
> In some cases the (human) user might want to influence what the URI should be, in other cases the client would like to leave this completely up to the server. I don't see such harm in having both w…

Just so long as we think the value of having both approaches is greater
than the cost of additional protocol complexity to support both.

[...]

---

From: Ben Campbell <[email-masked]>
Date: 13 Jun 2003 10:25:35 -0500

[...]

[...]