Subject: DAV:principal-URL

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Fri, 9 May 2008 15:11:46 -0700

Is is a requirement that DAV:principal-URL be an http(s) scheme  
URL?  I read the RFC that way (section 1 seems to imply it), but I  
can't really pin it down.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 May 2008 17:12:17 +0200

Wilfredo Sánchez Vega wrote:
> 
>   Is is a requirement that DAV:principal-URL be an http(s) scheme URL?  
> I read the RFC that way (section 1 seems to imply it), but I can't 
> really pin it down.

I really don't see how it can be a non-http URL... I also don't recall 
whether we left this fuzzy intentionally, or if this was an oversight 
(Geoff, do you recall...?).

BR, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 10 May 2008 17:06:49 -0400

It is certainly desireable for it to be an http url, but I don't see that 
it has to be one ... you could imagine using a mailto: url ...

Cheers,
Geoff

---

From: "Konstantin Breu" <[email-masked]>
Date: Sat, 10 May 2008 23:37:44 +0200

But RFC 3744 says

"However, servers implementing this specification MUST expose principal
resources at an http(s) URL"

Doesn't this mean, that the D:href for the principal cannot use another
scheme? I thought that the D:href has to point to the principal resource -
which the server MUST expose...

Cheers,
Konstantin

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Geoffrey M Clemm
Gesendet: Samstag, 10. Mai 2008 23:07
An: Julian Reschke
Cc: [email-masked]; WebDAV; [email-masked]; Wilfredo Sánchez
Vega
Betreff: Re: DAV:principal-URL

It is certainly desireable for it to be an http url, but I don't see that it
has to be one ... you could imagine using a mailto: url ... 

Cheers, 
Geoff

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sat, 10 May 2008 18:00:38 -0400

So here's the problem:  The primary purpose of the DAV:principal-URL is to 
specify the "identity" of a principal (so you can use it to check for 
equality).  But you might not have an HTTP URI that can be used as the 
"identity" (you might need to use some URN URI, for example).  So you 
might be forced to use a non-HTTP URL in the DAV:principal-URL property.

So the spec says that there must be an HTTP URL for a principal, but it 
does not require that the HTTP URL be the one that appears in the 
DAV:principal-URL property.

At least that's how I remember it ... I could of course be wrong (it's 
been a while :-).

Cheers,
Geoff

"Konstantin Breu" <[email-masked]> wrote on 05/10/2008 05:37:44 

> > >   Is is a requirement that DAV:principal-URL be an http(s) scheme 
URL?

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Sun, 11 May 2008 11:18:47 -0700

OK, this sounds right, though it's not the answer I was hoping  
for.  :-)

	Thanks,
	-wsv

On May 10, 2008, at 3:00 PM, Geoffrey M Clemm wrote:

> So here's the problem:  The primary purpose of the DAV:principal-URL  
> is to specify the "identity" of a principal (so you can use it to  
> check for equality).  But you might not have an HTTP URI that can be  
> used as the "identity" (you might need to use some URN URI, for  
> example).  So you might be forced to use a non-HTTP URL in the  
> So the spec says that there must be an HTTP URL for a principal, but  
> it does not require that the HTTP URL be the one that appears in the  
> At least that's how I remember it ... I could of course be wrong  
> (it's been a while :-).
>
> Cheers,
> Geoff

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 May 2008 21:16:01 +0200

Geoffrey M Clemm wrote:
> 
> So here's the problem:  The primary purpose of the DAV:principal-URL is 
> to specify the "identity" of a principal (so you can use it to check for 

Not totally convinced. If you can make a URN work, you can probably make 
an HTTP URI work as well. Maybe not a pretty one, though. But anyway...

> At least that's how I remember it ... I could of course be wrong (it's 

OK, let's start with the assumption that you are right, usually a safe 
position :-).

The spec say that the principal-URL must be used in ACL requests. Does 
this also mean it will be the one that will be used in the Access 
Control Properties, such as DAV:acl? I would think so, otherwise 
roundtripping will be messy...

If this is the case, the only way to actually get to the HTTP principal 
URL the spec requires in to use one of the reports, such as 
DAV:principal-property-search? If yes, I'd argue we probably write down 
an example showing how to do that, and add that to RFC3744bis...

BR, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Wed, 14 May 2008 15:31:01 -0400

If we believe that it is reasonable to require that the DAV:principal-URL 
be an HTTP URL, then I'm fine with just requiring this in RFC3774bis.
If we don't require that, then I don't think we can require that there be 
a way to "find" that principal, since as you say, if you can find it using 
the information in the DAV:principal-URL, you should have been able to 
format that information as an HTTP URL.

Cheers,
Geoff

> > So here's the problem:  The primary purpose of the DAV:principal-URL 
is 

> > So the spec says that there must be an HTTP URL for a principal, but 
it

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 May 2008 16:17:16 -0400

Hi Geoffrey,

--On May 14, 2008 3:31:01 PM -0400 Geoffrey M Clemm 
<[email-masked]> wrote:

> a way to "find" that principal, since as you say, if you can find it
> using the information in the DAV:principal-URL, you should have been able
> to format that information as an HTTP URL.

Actually I think the requirement is that the principal-URL property MUST 
contain an HTTP URL to a principal resource valid on the server. i.e. an 
HTTP URL to some random resource on another server is just as useless as a 
urn:uuid, if you need to resolve back to an actual principal resource.

-- 
Cyrus Daboo

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 20 May 2008 10:45:31 -0700

The reason I brought this up was that is affects draft-sanchez- 
webdav-current-principal-00 which I submitted.

   I had hoped to require that the principal URL returned in the  
current-user-principal-resource property MUST be the same as the  
principal-url property on the resource at that URL.  That would avoid  
requiring a client from having to fetch the current-user-principal- 
resource property on a DAV resource, then fetch the principal-url from  
there in order to know what to use in ACEs.  That's only feasible if  
the principal-url property must also be an http(s) URL.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 May 2008 15:59:09 +0200

Wilfredo Sánchez Vega wrote:
> 
>   The reason I brought this up was that is affects 
> draft-sanchez-webdav-current-principal-00 which I submitted.
> 
> requiring a client from having to fetch the 
> current-user-principal-resource property on a DAV resource, then fetch 
> the principal-url from there in order to know what to use in ACEs.  
> That's only feasible if the principal-url property must also be an 
> http(s) URL.

Let's assume that the principal URL can be something like a mailto: URL.

As far as I understand, RFC 3744 requires to use the principal URL in 
the ACL request, and it would be very strange if it didn't come back in 
the DAV:acl property.

So assuming we'd have a mailto URL in all these places, how can a client 
- in general - find the associated HTTP URL? The 
DAV:principal-property-search report *could* do that, as long as the 
server supports searching on the DAV:principal-URL property.

Geoff said:

GC>  If we believe that it is reasonable to require that the 
DAV:principal-URL be an HTTP URL, then I'm fine with just requiring this 
in RFC3774bis.
GC> If we don't require that, then I don't think we can require that 
there be a way to "find" that principal, since as you say, if you can 
find it using the information in the DAV:principal-URL, you should have 
been able to format that information as an HTTP URL.

...so I'm really tempted to state that, after all, the principal URL 
needs to be an HTTP URL.

However, Section 2 states:

"A URI of any scheme MAY be used to identify a principal resource. 
However, servers implementing this specification MUST expose principal 
resources at an http(s) URL, which is a privileged scheme that points to 
resources that have additional properties, as described in Section 4. 
So, a principal resource can have multiple URIs, one of which has to be 
an http(s) scheme URL. Although an implementation SHOULD support 
PROPFIND and MAY support PROPPATCH to access and modify information 
about a principal, it is not required to do so."

So if a server chooses not to fulfill "SHOULD support PROPFIND", what 
would that buy us?

Is anybody aware of a server that exposes principals as non-HTTP 
resources, or as HTTP resources not supporting PROPFIND?

Going back to Wilfredo's mail...:

 > requiring a client from having to fetch the
 > current-user-principal-resource property on a DAV resource, then fetch
 > the principal-url from there in order to know what to use in ACEs.
 > That's only feasible if the principal-url property must also be an
 > http(s) URL.

Why wouldn't that work for servers that in fact do not have any WebDAV 
enabled principal resources?

BR, Julian

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Thu, 22 May 2008 10:26:06 -0700

On May 21, 2008, at 6:59 AM, Julian Reschke wrote:

> So assuming we'd have a mailto URL in all these places, how can a  
> client - in general - find the associated HTTP URL? The  

   Right, and having to do that query, which may not be supported  
anyway, doesn't seem like a good solution.

> DAV:principal-URL be an HTTP URL, then I'm fine with just requiring  
> this in RFC3774bis.
> there be a way to "find" that principal, since as you say, if you  
> can find it using the information in the DAV:principal-URL, you  
> should have been able to format that information as an HTTP URL.
>

   Agreed.

> However, servers implementing this specification MUST expose  
> principal resources at an http(s) URL, which is a privileged scheme  
> that points to resources that have additional properties, as  
> described in Section 4. So, a principal resource can have multiple  
> URIs, one of which has to be an http(s) scheme URL. Although an  
> implementation SHOULD support PROPFIND and MAY support PROPPATCH to  
> access and modify information about a principal, it is not required  
> to do so."
>
> So if a server chooses not to fulfill "SHOULD support PROPFIND",  
> what would that buy us?

   I guess I can only be concerned about those who do, since there is  
little point in getting a principal URI if you can't query it for  
information, other than to use it in ACEs, but I think such use is  
limited unless you have some way to map principal URLs to something  
you know about.

> Why wouldn't that work for servers that in fact do not have any  
> WebDAV enabled principal resources?

   I agree with your comments, but don't understand this question.   
There's no point in trying to discover the URL to your principal  
resource if the server doesn't support them, since it wouldn't  
implement the extension I proposed.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 May 2008 13:10:41 +0200

Wilfredo Sánchez Vega wrote:
> resource if the server doesn't support them, since it wouldn't implement 
> the extension I proposed.

Hm.

OK, let's assume a server that has only one URI per principal, and that 
URI is a mailto URI.

Obviously, you wouldn't able to PROPFIND the DAV:principal-URL property.

The mailto URIs would be exposed in ACLs.

DAV:current-user-principal-resource (*) would show expose the mailto URI.

So, what would be the problem here with respect to your extension

BR, Julian

PS: I don't think that would be a terrible useful impl, I'm just trying 
to understand your previous statement about needing HTTP URIs for your 
extension.

(*) Shouldn't that be "DAV:current-user-principal-URL", by the way?

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 23 May 2008 07:15:38 -0700

Hi Julian,

> (*) Shouldn't that be "DAV:current-user-principal-URL", by the way?

Actually this is the key point. The use case for clients is to get to the 
principal "resource" not get the principal "URI". The interesting 
properties that clients need are on the principal resource 
(CALDAV:calendar-home-set for example), and indeed the DAV:principal-URL 
property is also there. So from a principal resource you can directly get 
DAV:principal-URL - always. From a principal-URL value, you are not 
guaranteed to directly get the principal resource (e.g. if mailto: or ldap: 
is used). If principal-URL does not point to a principal resource then the 
client has to fall back to principal-property-search reports on all valid 
principal collections in order to search for a principal resource with that 
principal-URL. Clients shouldn't have to do that.

Now, WebDAV ACL makes it clear (first paragraph of Section 2) that one of 
DAV:principal-URL or DAV:alternate-URI-set MUST contain a URL to a 
principal resource (http/https). So DAV:current-user-principal-resource is 
just that value. DAV:principal-URL can therefore be any URI scheme without 
affecting that.

-- 
Cyrus Daboo

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Fri, 23 May 2008 07:45:02 -0700

On May 23, 2008, at 4:10 AM, Julian Reschke wrote:
> OK, let's assume a server that has only one URI per principal, and  
> that URI is a mailto URI.\

   ...but that's not allowed; a server is required to expose at least  
one http(s) scheme URL for each principal.  It's just not required (we  
think) that this be the one in the DAV:principal-URL property; it  
might one of the alternate URIs.

> So, what would be the problem here with respect to your extension

   That makes the extension useful only if you want to know what your  
URI is in ACEs.  I can see that being somewhat useful, but it's highly  
limiting.

   The reason we want the extension for CalDAV clients is to query  
other properties of the principal, such as the calendar home set, the  
display name, etc.  That is, given some credentials, we want to know  
"who the hell am I?".

> PS: I don't think that would be a terrible useful impl, I'm just  
> trying to understand your previous statement about needing HTTP URIs  
> for your extension.
>

   I think it should be if we can require that it be the same as the  
DAV:principal-URL property on the principal resource, but Cyrus argued  
that the name should emphasize that it provides access to a resource  
that can yield further information about the current principal.

	-wsv

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 May 2008 18:20:45 +0200

Cyrus Daboo wrote:
> 
> Hi Julian,
> 
> --On May 23, 2008 1:10:41 PM +0200 Julian Reschke 
> <[email-masked]> wrote:
> 
> Actually this is the key point. The use case for clients is to get to 
> the principal "resource" not get the principal "URI". The interesting 
> property is also there. So from a principal resource you can directly 
> get DAV:principal-URL - always. From a principal-URL value, you are not 
> guaranteed to directly get the principal resource (e.g. if mailto: or 
> ldap: is used). If principal-URL does not point to a principal resource 
> then the client has to fall back to principal-property-search reports on 
> all valid principal collections in order to search for a principal 
> resource with that principal-URL. Clients shouldn't have to do that.

Yes.

I was just pointing out that we usually say "URL" in the XML elements 
when we're talking about URLs.

> Now, WebDAV ACL makes it clear (first paragraph of Section 2) that one 
> of DAV:principal-URL or DAV:alternate-URI-set MUST contain a URL to a 
> principal resource (http/https). So DAV:current-user-principal-resource 
> is just that value. DAV:principal-URL can therefore be any URI scheme 
> without affecting that.

OK, so the proposal for DAV:current-user-principal-URL^H^H^Hresource 
would work independently of the other issue, right?

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 23 May 2008 09:30:11 -0700

Hi Julian,

--On May 23, 2008 6:22:53 PM +0200 Julian Reschke <[email-masked]> 
wrote:

> Hm, whether we say "resource" or "URL" should not depend on that, but
> what is in the value of the property. And it is a URL, after all.

Well then, we could use:

DAV:current-user-principal-resource-URL

Which could hold the record for the longest property name :-)

-- 
Cyrus Daboo

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 May 2008 18:22:53 +0200

Wilfredo Sánchez Vega wrote:
>   ...but that's not allowed; a server is required to expose at least one 
> http(s) scheme URL for each principal.  It's just not required (we 
> think) that this be the one in the DAV:principal-URL property; it might 
> one of the alternate URIs.

Yes. It was just a thought experiment.

BR, Julian

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 23 May 2008 09:31:23 -0700

Hi Julian,

> would work independently of the other issue, right?

Yes. Whether or not DAV:principal-URL has to be http or can be something 
else would be irrelevant.

-- 
Cyrus Daboo

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Fri, 23 May 2008 09:54:50 -0700

On May 23, 2008, at 9:20 AM, Julian Reschke wrote:

>> Now, WebDAV ACL makes it clear (first paragraph of Section 2) that  
>> one of DAV:principal-URL or DAV:alternate-URI-set MUST contain a  
>> URL to a principal resource (http/https). So DAV:current-user- 
>> principal-resource is just that value. DAV:principal-URL can  
>> therefore be any URI scheme without affecting that.
>

   Ah, yes.  Though if you want to use the DAV:current-user-principal- 
URL^H^H^Hresource property to fine the URL you can use for yourself in  
ACEs, if we require that it matched DAV:principal-URL on the principal  
resources, you can get that info in one request instead of two.

   I also get the feeling that having servers always vend the  
"canonical" DAV:principal-URL URI for the principal rather than being  
allowed to vend any of the alternates will avoid problems down the  
road, for the same reason that it is necessary that there be a  
canonical URL in the first place.  But that's arguably a best- 
practices thing, not a necessity.  But it's not possible to rely on if  
specs don't require it...

	-wsv

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Fri, 23 May 2008 09:57:13 -0700

> DAV:current-user-principal-resource-URL

   URL implies resource (it's the "R"), so I'd just go with  
DAV:current-user-principal-URL, as Julian suggested.  XML is chatty  
enough without being redundant in names.

	-wsv