Subject: [Simple] Registration for SIPit 20 is open

From: Robert Sparks <[email-masked]>
Date: Mon, 12 Feb 2007 10:01:45 -0600

SIPit 20 will be hosted by Alcatel-Lucent in Antwerp, Belgium April  
16-20,2007.

Registration is now open - see http://www.sipit.net for more  
information.

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Gustav E" <[email-masked]>
Date: Tue, 13 Feb 2007 14:58:54 +0100

Hi all,

Concider the following example RLS document:

<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
    xmlns:rl="urn:ietf:params:xml:ns:resource-lists">
  <service uri="sip:[email-masked]">
    <list name="marketing">
      <rl:list name="europe">
        <rl:entry uri="sip:[email-masked]">
          <rl:display-name>Sven</rl:display-name>
        </rl:entry>
      </rl:list>
      <rl:entry uri="sip:[email-masked]"/>
      <rl:entry uri="sip:[email-masked]"/>
    </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/onm00200471ave/direct/01/

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Feb 2007 12:02:23 -0600

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 
<[email-masked]>) contains another list 
(sip:[email-masked]). The contents of this second 
list are expanded in a *different* MIME part (Content ID 
<[email-masked]>), *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:
> 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.
> Express yourself instantly with MSN Messenger! Download today it's 
> FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Feb 2007 15:24:04 -0500

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.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com