W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

Notes on call from today ...

From: Cullen Jennings <fluffy@cisco.com>
Date: Wed, 23 Nov 2005 13:29:23 -0800
To: WebDav <w3c-dist-auth@w3.org>
Message-ID: <BFAA1F33.61ED4%fluffy@cisco.com>


Things I think agreed on

Where not clear, will use XML Namespace instead of Namespace

on bug 9 - explain allow vendor extension using URL that vendor owns
  token based strings are ok defined in RFC

on bug 39 - use DAV:foo

on bug 11 - need to tell server implementers there are problems with
recursive xml and DOS attacks and they need to consider what to do. MAY
return 400 class error with explanation with what is wrong. MAY just close
connection.

on bug 15 - Cullen need to send question to list

on bug 37 - add back in forward reference to 14 (and perhaps 15)

on bug 43 - Move to using "not wellformed"

on bug 10 - proposal

Go with text based on idea
> 1) On the property element itself: [possible namespace name], [local name],
> [children] of type element or character, plus [attributes] named
> "xml:lang" present on the element itself or it's closest ancestor
> 
> 2) On all children of the property element: [possible namespace name], [local
> name], [attributes] and [children] of type element or character.

add text that points out clients can not count on preservation o comments,
processing instruction

On the topic of namespace, we not going to require that you preserver them
today (because many servers done) but say that future version of spec
probably will require this and server SHOULD do it. Clients SHOULD NOT
assume that servers do it.

Bug 45 - Cache-ability is effected by what we choose here.
Go with.... The client SHOULD not send it unless an standards track
specification requires it. Any specification that requires it need to
carefully consider the cache ability issue if what it is suggesting.


Bug 46 - First sentence or two of 12.2 is unclear. Main point is implementer
knows what get a relative URL, and the answer is that it relative to request
URL. Perhaps ref the the draft on URI handling. Need to loose the term
"single scope". If destination header in the request, then MAY be better to
use absolute instead of any relative. Julian to propose text.

Bug 47 - Will add back in and Lisa will try to clarify. Clients don't have
to implement this. 
Received on Wednesday, 23 November 2005 21:29:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:11 GMT