List Info

Thread: Preconditions and the responsedescription element




Preconditions and the responsedescription element
user name
2006-08-10 14:37:13
Hi,

Section 1.6 of RFC 3253 states that in case of a
multi-status
response, the error element, in which the precondition
elements
are placed, appears in the responsedescription element. The
content model of the latter, however, is (#PCDATA).

Regards,

Werner.
-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

Preconditions and the responsedescription element
user name
2006-08-10 15:06:10
Werner Donné schrieb:
> Hi,
> 
> Section 1.6 of RFC 3253 states that in case of a
multi-status
> response, the error element, in which the precondition
elements
> are placed, appears in the responsedescription element.
The
> content model of the latter, however, is (#PCDATA).

Yes, and there's really no problem with that, because
RFC2518 also says 
that elements can be extended.

Now, when discussing RFC2518bis a few WG members claimed
that extending 
elements with PCDATA model with new child elements is not a
good idea, 
and thus RFC2518bis has changed the embedding of
<error> elements. This 
may be less intrusive, but it *is* an incompatible change to
RFC3253, 
thus, feedback appreciated (see, for instance, 
<http://greenbytes.de/
tech/webdav/draft-ietf-webdav-rfc2518bis-15.html#rfc.section
.14.24>).

Best regards, Julian

Preconditions and the responsedescription element
user name
2006-08-10 15:43:50
Adding the error element to the response element is indeed
nicer, but it would have been safer to add it after all
"old" elements in the content model, as it was
done for the
location element. Current clients which don't ignore
unknown
elements that intervene in an existing content model
different
from "ANY", will break. It is likely that such
clients simply
consume the elements they know in the known order and then
stop.

Regards,

Werner.

Julian Reschke wrote:
> Werner Donné schrieb:
>> Hi,
>>
>> Section 1.6 of RFC 3253 states that in case of a
multi-status
>> response, the error element, in which the
precondition elements
>> are placed, appears in the responsedescription
element. The
>> content model of the latter, however, is (#PCDATA).
> 
> Yes, and there's really no problem with that, because
RFC2518 also says
> that elements can be extended.
> 
> Now, when discussing RFC2518bis a few WG members
claimed that extending
> elements with PCDATA model with new child elements is
not a good idea,
> and thus RFC2518bis has changed the embedding of
<error> elements. This
> may be less intrusive, but it *is* an incompatible
change to RFC3253,
> thus, feedback appreciated (see, for instance,
> <http://greenbytes.de/
tech/webdav/draft-ietf-webdav-rfc2518bis-15.html#rfc.section
.14.24>).
> 
> 
> Best regards, Julian
> 
> 

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

Preconditions and the responsedescription element
user name
2006-08-10 15:57:31
Werner Donné schrieb:
> Adding the error element to the response element is
indeed
> nicer, but it would have been safer to add it after all
> "old" elements in the content model, as it
was done for the
> location element. Current clients which don't ignore
unknown
> elements that intervene in an existing content model
different
> from "ANY", will break. It is likely that
such clients simply
> consume the elements they know in the known order and
then stop.

Well, those clients are broken anyway. I don't see any
point in adapting 
  to them.

Are you aware of clients with that problem?

Best regards, Julian

Preconditions and the responsedescription element
user name
2006-08-10 16:03:43
No, I'm not. It is just a remark about a defensive way
to extend a content model.

Regards,

Werner.

Julian Reschke wrote:
> Werner Donné schrieb:
>> Adding the error element to the response element is
indeed
>> nicer, but it would have been safer to add it after
all
>> "old" elements in the content model, as
it was done for the
>> location element. Current clients which don't
ignore unknown
>> elements that intervene in an existing content
model different
>> from "ANY", will break. It is likely
that such clients simply
>> consume the elements they know in the known order
and then stop.
> 
> Well, those clients are broken anyway. I don't see any
point in adapting
>  to them.
> 
> Are you aware of clients with that problem?
> 
> Best regards, Julian
> 
> 

-- 
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803	e-mail: werner.donnere.be

[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )