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: [email-masked]
Date: Fri, 13 Jun 2003 02:56:24 +0300

Hi Krisztian,

Thanks for your comments, see my responses inline.

I think the main points about these comments are these:
- Do we need the notification policies at all?
- What information should it be possible to use for authorizing presence document, and do we operate on tuple-level or with higher granularity when deciding what to give.

Markus

> From: Kiss Krisztian (NRC/Tampere) 
> Sent: 02 May, 2003 20:51
> To: 'ext Ben Campbell'; Isomaki Markus (NRC/Helsinki)
> Cc: 'Simple WG'
> Subject: RE: [Simple] Comments on draft-ietf-simple-data-req-02.txt
> 
> 
> Jonathan et al,
> 
> Please find below some comments on draft-ietf-simple-data-req-02:
> 
> - REQ PC-9 defines that a user could query for a "set of 
> URIs" of a collection. I believe this kind of query should 
> return all information available for the presentity 
> collection in addition to the set of URIs. Additionally, the 
> REQ should also define those users who are authorized to make 
> this query. According to PC-10 and PC-11, there are already 
> two kind of authorized lists defined, one list is for the 
> users who are allowed to subscribe to the list, another list 
> is for the users who are allowed to manipulate the attributes 
> of the list. Probably the group of the users allowed to query 
> equals to the group who are allowed to subscribe. One 
> re-wording of the sentence could be as follows: "It MUST be 
> possible for the authorized users allowed to subscribe to the 
> list also to query for information of the particular 
> presentity collection by providing the URI for the presentity 
> collection."
> 

At least as a default authorization policy this would make sense, so if there are no objections, we could incorporate your proposal.

> -REQ PC-24: I am wondering about the justification for this 
> REQ. It sounds rather an implementation issue instead of a 
> requirement that would have effects on the final solution. It 
> might cause unnecessary and additional complexity for the 
> solution. To tell the truth, I am confused why the network 
> resident address book has some special role here, if this is 
> the case, we could also have REQs for other type of 
> "collection kind of resources", e.g. presence access list, 
> etc. Anyway, it'd good to have a more generic REQ instead, 
> with a strength SHOULD instead of MUST.
> 

Ben Campbell had similar comment. I think it would be useful to allow sharing of lists (or other data) among applications. I think SHOULD-level req is OK, with explanation that this kind of linking is the intended use here. 

> -REQ AP-7: I believe there is no need for this requirement. 
> In the requirement phase, the best would be to keep distinct 
> roles for the different lists, the buddy list is for the 
> presentity's own subscription purposes, the allowed and 
> blocked lists are for authorization purposes.
> 

I tend to agree. This req is generated by Jonathan. I believe he derived it from some existing IM/presence systems, which have this kind of feature. Jonathan (&others), do you see this as a necessary feature? 

On the other hand, if we allow links to be included, then I suppose the allowed-list would be just a link to presence list. Would this be an OK approach? 

> -REQ AP-8: would be good to have more exact wording in the 
> last sentence of the requirement. I guess the assumption here 
> is that the meaning behind the "add, remove, modify, read, 
> clear and create and delete" operations must be clear for the 
> reader based on the PC requirements, however here we are 
> talking about multiple lists, therefore it is unclear whether 
> the remove, delete and clear operations are meant for the 
> individual entries of a list, the list itself, or all the 
> lists handled by the authorization policy. 
> 

I think they are for individual entries. I'll try to make this more clear.

> -REQ N1-5: all the notification requirements listed in 
> chapter 5.2 are somehow "less important". If we can set 
> "when" type of requirements (criteria when notifications are 
> delivered to watchers) also to authorization, additionally to 
> filtering, throttling and local server policies, we may end 
> up having too complex rules about generating notifications.
> 

Yes, I think there hasn't been enough discussion on the necessity of these requirements. Personally I don't see them necessary. Jonathan? In any case I'll start a separate thread about this to see if anyone has any opinion.

> -REQ C1-3: These requirements seem too specific and rather 
> unclear. The first issue is why only the contact address and 
> status are chosen as presence attributes that the user can 
> set by authorization. Maybe a generic requirement would be 
> enough saying that the authorized content could be specified 
> by using any presence attribute. The second issue, which is 
> rather important, if these requirements mean that after 
> authorization the whole tuple including the attribute is 
> omitted, or only the chosen attribute from the tuple. More 
> clearly, is the aim to allow for the user to define which 
> presence attributes to authorize within a tuple or rather to 
> authorize tuples (i.e. what is the atomic element handled by 
> the content policy)?
> 

Well, nowadays it is hard to say even what a tuple is ;) I think this will need more list discussion as well.

> -REQ C-4: I guess it would be better to place this before 
> C1-3. Assuming that the previous requirements were meant for 
> selecting attributes within a tuple, this REQ seem to allow 
> to select a whole tuple. Does this requirement allow any 
> presence  attribute (e.g. one RPIDS extensions, tuple-id) to 
> be used as a criteria for selecting the tuples?
> 

To be handled within the same discussion.

> -REQ C-6: this REQ sounds like one covering the delivery of 
> default presence documents. I would prefer to mention here 
> explicitly that DM is used for publication of the default 
> presence document. Also, a strength of MUST would be better 
> instead of the SHOULD. A rewording could be: It MUST be 
> possible for the user to publish a presence document with 
> default presence attributes. 
> 

I think it would be OK to take away this requirement from this draft and collect the requirements for default presence doc publishing separately. Unless someone thinks this req is important for some other purpose.

> Additional requirements:
> 
> -REQ-PC-x: 
> A requirement about storing an XML document including 
> filtering information by using the data manipulation 
> mechanism. This could be useful for presentity collections 
> where different URIs of the collection could have either 
> common or individual filter definitions pre-defined, and the 
> watcher(s) would not need to include any filter information 
> within the subscription.
> 

OK, I suppose this could be an addition to the presence list requirements. Something that could be optionally supported by the server.

> -REQ AP-x: 
> A requirement might be justified for the expected behavior of 
> the acceptance policy when a watcher is part of several 
> lists, e.g. multiple allowed lists. The policy could define, 
> for example, an evaluation order for the lists, and the 
> policy would stop evaluating the lists when the particular 
> watcher is found. An alternative could be that the watcher 
> cannot belong to several lists, however this does not sound 
> feasible, especially if it is possible to use wildcards for 
> defining URIs.

Well, there are two models: either separate lists for different acceptance rule (allow, block etc.) or a single list with different rule for each entry. Maybe I need to reword the reqs so that this is not yet determined. What we want to achieve is to accept some users and block some others, and have some "pending". I don't think we need to actually even say how these rules are organized in this requirements draft.

> 
> -REQ C-x:
> A requirement, when the presentity authorizes different 
> values of the otherwise same "data segment" to different 
> watchers. One motivation here is the ability to give 
> different level of details of information (e.g. w.r.t. 
> location) to different watchers. Perhaps this is hidden 
> behind some of the requirements, but it would be rather good 
> to explicitly state it.

I think this is a valid case, so I'll try to include it somehow. I don't think this will actually add anything new for the solution, but probably it has some link to publishing as well.

> REQ C-5 covers this partly, however it makes a hint that new 
> values of attributes are to be modified from existing values. 
> By taking the geographical location information example, the 
> difference between the information to be delivered to 
> different watchers is only in the level of details. 
> Therefore, there could be another approach that tuples would 
> be assigned for the different level of details and 
> authorization would be done based on some kind of "level of 
> detail" attribute.
> 

OK, do you have some text to propose?

> -REQ ?-x: 
> Relation between the content requirements and the acceptance 
> policy requirements are somehow undefined. When the 
> acceptance policy results in accepting a watcher, then which 
> content/notification requirements shall be applied, how and 
> where this relation would be defined.
> 

OK, I'll try to clarify that. I guess acceptance is the first steps, and subsequent rules would cover the content to be given. 

> Thanks,
> Krisztian

Markus

---

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

Hi Krisztian,

Markus

Markus

---

From: [email-masked]
Date: Fri, 13 Jun 2003 13:50:45 +0300

For some reason this did not appear on SIMPLE list, so I'm resending:

> From: Isomaki Markus (NRC/Helsinki) 
> Sent: 13 June, 2003 02:27
> To: 'ext Ben Campbell'
> Cc: Simple WG
> Subject: RE: Comments on draft-ietf-simple-data-req-02.txt
> 
> 
> 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: 
> 
> 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.
> 
> 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. 
> 
> 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.
> 
> 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.
> 
> 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. 
> 
> Agreed. Change notification is needed since multiple clients 
> may be manipulating the same data, while they are on-line. 
> I'll reword the reqs.
> 
> > 
> 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. 
> 
> 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.
> 
> 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?
> 
> 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.
>

---

From: [email-masked]
Date: Fri, 13 Jun 2003 13:50:45 +0300

---

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

For some reason this did not appear on SIMPLE list, so I'm resending:

> Sent: 13 June, 2003 02:56
> To: Kiss Krisztian (NRC/Tampere); 'ext Ben Campbell'
> Cc: 'Simple WG'
> - What information should it be possible to use for 
> authorizing presence document, and do we operate on 
> tuple-level or with higher granularity when deciding what to give.
> 
> Markus
> 
> At least as a default authorization policy this would make 
> sense, so if there are no objections, we could incorporate 
> your proposal.
> 
> Ben Campbell had similar comment. I think it would be useful 
> to allow sharing of lists (or other data) among applications. 
> I think SHOULD-level req is OK, with explanation that this 
> kind of linking is the intended use here. 
> 
> I tend to agree. This req is generated by Jonathan. I believe 
> he derived it from some existing IM/presence systems, which 
> have this kind of feature. Jonathan (&others), do you see 
> this as a necessary feature? 
> 
> On the other hand, if we allow links to be included, then I 
> suppose the allowed-list would be just a link to presence 
> list. Would this be an OK approach? 
> 
> Yes, I think there hasn't been enough discussion on the 
> necessity of these requirements. Personally I don't see them 
> necessary. Jonathan? In any case I'll start a separate thread 
> about this to see if anyone has any opinion.
> 
> Well, nowadays it is hard to say even what a tuple is ;) I 
> think this will need more list discussion as well.
> 
> I think it would be OK to take away this requirement from 
> this draft and collect the requirements for default presence 
> doc publishing separately. Unless someone thinks this req is 
> important for some other purpose.
> 
> > Additional requirements:
> > 
> > -REQ-PC-x: 
> OK, I suppose this could be an addition to the presence list 
> requirements. Something that could be optionally supported by 
> the server.
> 
> > -REQ AP-x: 
> Well, there are two models: either separate lists for 
> different acceptance rule (allow, block etc.) or a single 
> list with different rule for each entry. Maybe I need to 
> reword the reqs so that this is not yet determined. What we 
> want to achieve is to accept some users and block some 
> others, and have some "pending". I don't think we need to 
> actually even say how these rules are organized in this 
> requirements draft.
> 
> > 
> > -REQ C-x:
> I think this is a valid case, so I'll try to include it 
> somehow. I don't think this will actually add anything new 
> for the solution, but probably it has some link to publishing as well.
> 
> OK, I'll try to clarify that. I guess acceptance is the first 
> steps, and subsequent rules would cover the content to be given. 
> 
> > Thanks,
> > Krisztian
> > 
> 
> Markus
>

---

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