Subject: [Simple] Comments on xcap-list-usage

From: [email-masked]
Date: Tue, 4 Nov 2003 16:24:30 +0200

- Subscribeable: by whom? Who is authorised to subscribe to this list, besides the creator of the list? How that indicated?

- If the "uri" attribute is absent in a document, but the "subscribeable" flag is set to true. the XCAP server must allocate a URI. But what if the URI is present but conflicts with an already existing URI? How does the server react? Does it reject the request or does it just rewrite the URI?

- Why does the URI need to be globally unique? Can it be unique per user (i.e. a user can't create 2 lists with the same URI)? we all have [email-masked]. I guess the answer to this depends on the answer to the first question: If only the creator can subscribe to the list, then the URIs can be unique to that user only. The server asserts the user and then know that he is subscribing to his [email-masked]. This would not work if multiple users can subscribe to my list.

Regards,
Hisham

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 04:14:13 -0500

Hisham,

Thanks for your comments. Responses inline.

[email-masked] wrote:

> - Subscribeable: by whom? Who is authorised to subscribe to this
> list, besides the creator of the list? How that indicated?

Good question. There is nothing in this application usage that defines
authorization policies for list subscriptions. I think we should add
text to the xcap-list spec that says that. In such a case, the
provider's authorization policies would apply. I expect in many cases
these policies only allow the owner of the list to subscribe to it.

I also think it makes sense as a follow on activity to write an xcap
usage for authorization policies for list subscriptions.

> 
> - If the "uri" attribute is absent in a document, but the
> "subscribeable" flag is set to true. the XCAP server must allocate
> a URI. But what if the URI is present but conflicts with an already
> existing URI? How does the server react? Does it reject the request
> or does it just rewrite the URI?

Great question.

I think it should return an error. The reason is that the document 
would be in violation of one of the non-schema data constraints.

The real question is, how does the client know that it should retry 
with a different URI?

I see no obvious answer. There are a few possibilities:

   * disallow clients from setting the URI
   * invent a new error resposne code
   * add a body to the 409 that describes the condition

> 
> - Why does the URI need to be globally unique? Can it be unique per
> user (i.e. a user can't create 2 lists with the same URI)? we all
> have [email-masked]. I guess the answer to this depends on the
> answer to the first question: If only the creator can subscribe to
> the list, then the URIs can be unique to that user only. The server
> asserts the user and then know that he is subscribing to his
> [email-masked]. This would not work if multiple users can
> subscribe to my list.

Which I think we ultimately want. I think its a risky venture to make 
the actual resource definition depend on both the URI *and* the user 
that is asking. The fact that the URI may be ugly has no relevance to 
how its rendered to users. Its perfectly fine if all they ever see is 
"Friends".

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 04:14:13 -0500

Hisham,

Great question.

Thanks,
Jonathan R.