I think the question was actually around the schema in
draft-ietf-simple-xcap-list-usage, not rfc4662.
To answer your question for list-usage, it is permitted that
the
embedded <list> within <rls-services> can be
hierarchical (containing
other <list> elements), though I see no value in doing
so. The text in
4.4.5 is in error, and should include <list> as
permitted. I will
correct that in auth48 (which has just started - yay!)
-Jonathan R.
Adam Roach wrote:
> Nested lists are certainly allowed, but this isn't how
they would be
> represented. The schema of RFC 4662 does not allow for
a <list> element
> to appear as a child of a <list> element.
>
> RFC 4662 contains a number of examples that demonstrate
exactly the
> "nested list" concept. The diagram at the end
of section 5.5 gives a
> high-level overview of the MIME structure of a list
(Top level document)
> that contains another list (part B) and an element
(part C).
>
> More concretely, if you look at the NOTIFY that starts
on page 28,
> you'll see that the top-most list (Content ID
> <2BEI83 pres.vancouver.example.com>) contains
another list
> (sip:adam-friendsstockolm.example.org). The contents of
this second
> list are expanded in a *different* MIME part (Content
ID
> <1KQhyEpres.vancouver.example.com>), *not*
within the XML for the
> top-most list.
>
> This approach has the very important property that each
list may be
> signed (using an S/MIME signature) by their respective
authorities to
> guarantee that they have not been modified in transit.
It also allows
> such content to be S/MIME encrypted, thus preventing
unauthorized
> disclosure to intermediaries.
>
> /a
>
> Gustav E wrote:
>
>> Hi all,
>>
>> Concider the following example RLS document:
>>
>> <?xml version="1.0"
encoding="UTF-8"?>
>> <rls-services xmlns="urn:ietf:params ml:ns
:rls-services"
>> xmlns:rl="urn:ietf:paramsml:ns
:resource-lists">
>> <service uri="sip:marketingexample.com">
>> <list name="marketing">
>> <rl:list name="europe">
>> <rl:entry uri="sip:svenexample.com">
>>
<rl:display-name>Sven</rl:display-name>
>> </rl:entry>
>> </rl:list>
>> <rl:entry uri="sip:joeexample.com"/>
>> <rl:entry uri="sip:sudhirexample.com"/>
>> </list>
>> <packages>
>> <package>presence</package>
>> </packages>
>> </service>
>> </rls-services>
>>
>> My basic question here is if it is allowed to have
a list-based
>> service containg yet another level of list(s). I'm
not sure of why one
>> would need such a construction, but rather
interested in finding out
>> if it can ever occur.
>>
>>> From my understanding this should not break the
rls-services schema in
>>
>> list-usage-05. Do you agree?
>>
>> I'm a bit confused of the text (4.4.5 Additional
constraints):
>> ----
>> o In addition, an RLS services document can
contain a <list>
>> element, which in turn can contain
<entry>, <entry-ref> and
>> <external> elements. The constraints
defined for these elements
>> in Section 3.4.7 MUST be enforced.
>> ----
>>
>> Should this be interpreted as additional
<list> sub-elements are not
>> allowed?
>>
>> BR,
>> /Gustav E
>>
>>
____________________________________________________________
_____
>> Express yourself instantly with MSN Messenger!
Download today it's
>> FREE! http://messenger.msn.click-url.com/go/onm00200471
ave/direct/01/
>>
>>
>> _______________________________________________
>> Simple mailing list
>> Simpleietf.org
>> https:/
/www1.ietf.org/mailman/listinfo/simple
>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https:/
/www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex
Plaza
Cisco Fellow Parsippany,
NJ 07054-2711
Cisco Systems
jdrosencisco.com FAX: (973)
952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
