Subject: RE: Using DAV namespace for proprietary properties

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 22 Feb 2002 21:14:01 -0500

I agree that this is a problem, and suggest that it be solved
by adding the wording from DeltaV to 2518.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:30 PM
To: [email-masked]
Subject: Re: Using DAV namespace for proprietary properties

Do we feel there is a change in the 2518 spec needed in regard to the
following posting by Julian...

> currently RFC2518 is silent on this issue.
>
> However, deltaV says 1.5 [1]: "Although WebDAV request and response
bodies
> can be extended by arbitrary XML elements, which can be ignored by the
> message recipient, an XML element in the DAV namespace MUST NOT be used
in
> the request or response body of a versioning method unless that XML
element
> is explicitly defined in an IETF RFC."
>
> I think something similar needs to be added to the revision to RFC2518.

------------------------------------------
Phone: 914-784-7569,   [email-masked]

---

From: "Babich, Alan" <[email-masked]>
Date: Sun, 24 Feb 2002 14:19:15 -0800

Sorry, I misunderstood. I agree with you. Proprietary 
properites MUST NOT use the DAV: namespace.

Alan Babich

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Friday, February 22, 2002 12:49 AM
To: Babich, Alan; [email-masked]
Subject: RE: Using DAV namespace for proprietary properties

Alan,

that's fine.

My position is that proprietary properties MUST not use the DAV: namespace.
If my server can rely on this, it can report all DAV: properties it doesn't
know as "not found" without even bothering to ask the persistence layer.

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Babich, Alan
> Sent: Wednesday, February 20, 2002 12:47 AM
> Subject: RE: Using DAV namespace for proprietary properties
>
>
> I don't think it is or should be a requirement that all
> proprietary properties be live properties.
>
> Alan
>
> From: Julian Reschke [mailto:[email-masked]]
> Sent: Monday, February 18, 2002 11:47 PM
> To: Babich, Alan; [email-masked]
> Subject: RE: Using DAV namespace for proprietary properties
>
>
> I see.
>
> Could you please explain this position?
>
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Babich, Alan
> > Sent: Monday, February 18, 2002 9:25 PM
> > Subject: RE: Using DAV namespace for proprietary properties
> >
> >
> > "Would it be permissible to assume that properties in the DAV: namespace
> > *never* are dead properties, allowing to skip this step?"
> >
> > I don't think so.
> >
> > Alan Babich
> >
> > From: Julian Reschke [mailto:[email-masked]]
> > Sent: Monday, February 18, 2002 6:29 AM
> > Subject: Using DAV namespace for proprietary properties
> >
> >
> > Hi,
> >
> > However, deltaV says 1.5 [1]: "Although WebDAV request and
> response bodies
> > message recipient, an XML element in the DAV namespace MUST NOT
> be used in
> > the request or response body of a versioning method unless that
> > XML element
> > Looking at current implementations I notice that the Microsoft Webfolder
> > client (sigh!) does a PROPFIND on no less than then 10 proprietary
> > properties placed into the DAV: namespace ([2]), of which it
> only seems to
> > *use* one (DAV:ishidden). Without wiring special knowledge about these
> > attributes into a server, it will usually have to consult the resource's
> > dead properties (just to find out that these don't exist). Would it be
> > permissible to assume that properties in the DAV: namespace
> > *never* are dead
> > properties, allowing to skip this step?
> >
> > Julian
> >
> >
> > [1]
> > <http://www.webdav.org/deltav/protocol/draft-ietf-deltav-versionin
> g-20.1.htm
> #_Toc524830510>
> [2]
> <http://www.greenbytes.de/tech/webdav/webdavfaq.html#ANSWER-mswebf
older-prop
rietary-properties>

---

From: "Jason Crawford" <[email-masked]>
Date: Wed, 27 Feb 2002 17:57:49 -0500

I've created an issue DAV_XML_NAMESPACE_IS_RESERVED.  It says we have
consensus on this issue.