Subject: [Sipping] Pre pub-request feedback on draft-ietf-sipping-uri-list-message-05

From: Dean Willis <[email-masked]>
Date: Wed, 25 Jan 2006 15:22:20 -0600

One of the joys of being a chair these days is the new "shepherding"  
process. Under this process, I get to do a nifty writeup for the IESG  
for every document that we are sending to the IESG for IETF review  
and publication as an RFC. Among other things, this writeup requires  
me to do a final review of the document and declare it ready for  
publication. This is intended to reduce the work load on the AD, who  
shouldn't have to deal with stuff like checking syntax and grammar.

I started doing a pub request for draft-ietf-sipping-list- 
messages-05, and found there were a couple of points that might make  
it not quite ready for publication. Sure, I should have caught them a  
few weeks ago. I didn't.  I'm sorry. That's why we have the new  
procedure.

-------

Nit: Use of "entering the burden" in the Introduction is a bit  
clumsy. Also the "want" should have a "s" after it. Perhaps deleting  
"entering" would help, thus the sentence might be:

Old:

    While this option seems to be reasonable in many cases, in
    other situations the sending user just want to send a small page- 
mode
    instant message to an ad-hoc group, without entering the burden of
    setting up a session.

New:
    While this option seems to be reasonable in many cases, in other
    situations the sending user just wants to send a small page-mode
    instant message to an ad-hoc group without  the burden of setting
    up a session.

Also in Intro:

Old:

    To meet this requirement, we provide a mechanism whereby the MESSAGE
    URI-list service can include the received URI-list along the instant
    message payload in each of the instant messages sent to the
    recipients.

The above seems to be missing a "with"

New:

    To meet this requirement, we provide a mechanism whereby the MESSAGE
    URI-list service can include the received URI-list along with the  
instant
    message payload in each of the instant messages sent to the
    recipients.

In Section 3, Overview

What does "to" or "from" have to do with "capacity"? Most people  
think of capacity as "how much will it hold", like 5 liters or 200  
kilograms or 37 recipients. The term is first used in the overview,  
section 3, paragraph 3. Perhaps a breakout defining capacity in thus  
usage would help. There are also some "s" missing on the end of  
words, like "contains". We also don't say what happens if the  
"capacity" is unspecified.

Old:

    The MESSAGE
    URI-list service can include a resource list in the outgoing MESSAGE
    request that contain those resources tagged with a To or Cc
    capacities (and not Bcc capacities). This allows the creator of the
    incoming MESSAGE request to identify if a resource should be
    receiving a copy of the MESSAGE request as a capacity of recipient
    (to), carbon copy (cc) or blind carbon copy (bcc).  It also allows
    some the intended recipients to reply to the initial sender and all
    the visible recipients of the MESSAGE request.

New:

The MESSAGE URI-list mechanism allows a sender to specify multiple  
targets for a MESSAGE request by including a resource list in the  
body of the MESSAGE request. This resource list includes the URIs of  
the targets. Each target URI may also be marked to indicate in what  
capacity (or role) the URI-list service will place the target. The  
available capacities include "to", "cc", and "bcc".  When the MESSAGE  
URI-list server expands the request for each recipient, it includes a  
new URI-list that contains only the targets originally listed in "to"  
and "cc" capacities, and excludes those listed in the "bcc" capacity.  
This allows recipients to both see and reply to the "to" and "cc"  
targets, but not to the "bcc" targets. The default capacity assumed  
if one is not specified by the sender is "to". This is discussed in  
greater detail in section 4.1 of this document.

Note: Section 4.1 says the capacity tag should be included, but  
doesn't say what happens if it isn't. It needs to a say this (I  
presume an unspecified recipient is "to").

Question: Did anybody formally validate the schema and XML doc in the  
example? I'm not an XML guy. Somebody please tell me you've validated  
it.

The procedures text in Section 6 uses 2119 language inappropriately,  
I think.  This is somewhat subjective, but I prefer not to use  
requirements language to describe what something just does. It should  
be reserved for places where we're actually discussing requirements,  
quoting requirements imposed by other specifications, and  giving  
specific guidance on what might otherwise seem reasonable behavior  
but will break compatibility with other systems or elements.

For example:

Section 6: Procedures  at the User Agent Client

Old:
    A UAC that wants to create a multiple-recipient MESSAGE request MUST
    create a MESSAGE request according to RFC 3428 [8] Section 4.  The
    UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
    MESSAGE URI-list service.  In addition to the regular instant  
message
    body, the UAC SHOULD add a URI-list body whose Content-Disposition
    type is 'recipient-list', specifed in the Framework and Security
    Considerations for SIP URI-list Services [11].  This body contains a
    URI-list with the recipients of the MESSAGE.  The URI-list body MAY
    also include the 'capacity' extension to the URI-list specified in
    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field.

I would suggest writing as:

New:

    A UAC that wants to create a multiple-recipient MESSAGE request
    creates a MESSAGE request according to RFC 3428 [8] Section 4.  The
    UAC populates the Request-URI with the SIP or SIPS URI of the
    MESSAGE URI-list service.  In addition to the regular instant  
message
    body, the UAC adds a URI-list body whose Content-Disposition
    type is 'recipient-list', specifed in the Framework and Security
    Considerations for SIP URI-list Services [11].  This body contains a
    URI-list with the recipients of the MESSAGE.  The URI-list body may
    also include the 'capacity' extension to the URI-list specified in
    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field.

Not every "does" is a "MUST", and not every "might do" is a MAY.   
We're just talking about how something works, not defining  
requirements or calling out critical interop characteristics. The  
final MUST is there because if the UA doesn't do this, it violates  
the feature negotiation rules of SIP.

A subsequent paragraph raises similar concerns:

Old:

    Typically, the MESSAGE URI-list service will copy all the  
significant
    header fields in the outgoing MESSAGE request.  However, there might
    be cases where the SIP UA wants the MESSAGE URI-list service to  
add a
    particular header field with a particular value, even if the header
    field wasn't present in the MESSAGE request sent by the UAC.  In  
this
    case, the UAC MAY use the "?" mechanism described in Section 19.1.1
    of RFC 3261 [5] to encode extra information in any URI in the list.
    However, the UAC MUST NOT use the special "body" hname (see Section
    19.1.1 of RFC 3261 [5]) to encode a body, since the body is present
    in the MESSAGE request itself.

New:

    Typically, the MESSAGE URI-list service will copy all the  
significant
    header fields in the outgoing MESSAGE request.  However, there might
    be cases where the SIP UA wants the MESSAGE URI-list service to  
add a
    particular header field with a particular value, even if the header
    field wasn't present in the MESSAGE request sent by the UAC.  In  
this
    case, the UAC may use the "?" mechanism described in Section 19.1.1
    of RFC 3261 [5] to encode extra information in any URI in the list.
    However, the UAC MUST NOT use the special "body" hname (see Section
    19.1.1 of RFC 3261 [5]) to encode a body, since the body is present
    in the MESSAGE request itself.

Similarly in 7.1 Determining the Intended Recipient:

Old:

    On reception of a MESSAGE request with a URI-list, a MESSAGE URI- 
list
    service SHOULD determine the list of intended recipients, by
    inspecting the URI-list contained in the body.  In case two of those
    URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines
    equivalent URIs), the MESSAGE URI-list SHOULD consider a single
    intended recipient.

New:

    On reception of a MESSAGE request with a URI-list, a MESSAGE URI- 
list
    service determines the list of intended recipients, by
    inspecting the URI-list contained in the body.  In case two of those
    URIs are equivalent (section 19.1.4 of RFC 3261 [5] defines
    equivalent URIs), the MESSAGE URI-list SHOULD consider this to
    represent a single intended recipient rather than sending multiple
    copies of the MESSAGE to the same destination.

In 7.2 Creating an Outgoing Message Request

Old;
    o  A MESSAGE URI-list service MUST include a From header field whose
       value is the same as the From header field included in the
       incoming MESSAGE request, subject to the privacy requirements  
(see
       RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming MESSAGE
       request.  Note that this does not apply to the "tag" parameter.
    o  A MESSAGE URI-list service SHOULD generate a new To header field
       value set to the intended recipient URI.  According to the
       procedures of RFC 3261 Section 8.1.1.1, this value should also be
       equal to the Request-URI of the outgoing MESSAGE request.
    o  A MESSAGE URI-list service SHOULD create a new Call-ID header
       field value.

New:
    o  A MESSAGE URI-list service includes a From header field whose
       value is the same as the From header field included in the
       incoming MESSAGE request, subject to the privacy requirements  
(see
       RFC 3323 [6] and RFC 3325 [7]) expressed in the incoming MESSAGE
       request.  Note that this does not apply to the "tag" parameter.
    o  A MESSAGE URI-list service generates a new To header field
       value set to the intended recipient's URI.  According to the
       procedures of RFC 3261 Section 8.1.1.1, this value SHOULD also be
       equal to the Request-URI of the outgoing MESSAGE request.
    o  A MESSAGE URI-list service MUST create a new Call-ID header
       field value, as per the procedures of RFC 3261 section 8.1.1.4.

A note for final publication readiness readiness: Section 13 contains  
series of "Changes since"  paragraphs that need to be deleted. We  
should delete these before sending the final doc to the IESG. The  
only exception to this might be a document that is obsoleting another  
RFC, and that contains a discussion of changes relative to the RFC  
being obsoleted.

--
Dean

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 26 Jan 2006 18:38:57 +0200

Hi Dean:

Thanks for the review. I agree with most of your issues, thus, I don't 
reproduce them here. But some of them require a bit more of discussion. 
Please take a look at those issues below:

Dean Willis wrote:

> In Section 3, Overview
> 
> What does "to" or "from" have to do with "capacity"? Most people think 
> of capacity as "how much will it hold", like 5 liters or 200 kilograms 
> or 37 recipients. The term is first used in the overview, section 3, 
> paragraph 3. Perhaps a breakout defining capacity in thus usage would 
> help. There are also some "s" missing on the end of words, like 
> "contains". We also don't say what happens if the "capacity" is 
> unspecified.
> 

Ok, I agree with the proposed new text. We need to evaluate if we can 
introduce the "capacity" attribute concept earlier in the document.

One point of disagreement is the default capacity attribute, which set 
to be "bcc". That is already described in Section 4.1. I agree we need 
to indicate this also in Section 3, but it is to be set to "bcc".

> targets for a MESSAGE request by including a resource list in the body 
> of the MESSAGE request. This resource list includes the URIs of the 
> targets. Each target URI may also be marked to indicate in what capacity 
> (or role) the URI-list service will place the target. The available 
> capacities include "to", "cc", and "bcc".  When the MESSAGE URI-list 
> server expands the request for each recipient, it includes a new 
> URI-list that contains only the targets originally listed in "to" and 
> "cc" capacities, and excludes those listed in the "bcc" capacity. This 
> allows recipients to both see and reply to the "to" and "cc" targets, 
> but not to the "bcc" targets. The default capacity assumed if one is not 
> specified by the sender is "to". This is discussed in greater detail in 
> section 4.1 of this document.
> 
> 
> Note: Section 4.1 says the capacity tag should be included, but doesn't 
> say what happens if it isn't. It needs to a say this (I presume an 
> unspecified recipient is "to").
> 

As indicated before, Section 4.1 says:

The default 'capacity' value is "bcc", that is, the absence of a 
'capacity' attribute MUST be treated as if the 'capacity' was set to "bcc".
> example? I'm not an XML guy. Somebody please tell me you've validated it.
>

Yes, I validated the schema with XMLSpy and it is valid.

However, I also validated with the validator at 
http://validate.openlaboratory.net/ and it complains about the Unique 
Particle Attribution rule of the resource-list XML Schema (not about the 
MESSAGE exploder draft itself).  The issue has been discussed in the 
SIMPLE mailing list, see 
http://www.ietf.org/mail-archive/web/simple/current/msg05954.html
Unfortunately, there is nothing I can do to solve this problem, since 
there is nothing wrong in the XML Schema or the example in this draft.

> 
> The procedures text in Section 6 uses 2119 language inappropriately, I 
> think.  This is somewhat subjective, but I prefer not to use 
> requirements language to describe what something just does. It should be 
> reserved for places where we're actually discussing requirements, 
> specific guidance on what might otherwise seem reasonable behavior but 
> will break compatibility with other systems or elements.
> 

Careful here, some of the suggestions make sense, others not. Remember 
that this are Sections 6, and 7, which are the main normative text of 
the specification. So this is not an overview or general description.

>    MESSAGE URI-list service.  In addition to the regular instant message
>    MESSAGE URI-list service.  In addition to the regular instant message
> Not every "does" is a "MUST", and not every "might do" is a MAY.  We're 
> just talking about how something works, not defining requirements or 
> calling out critical interop characteristics. The final MUST is there 
> because if the UA doesn't do this, it violates the feature negotiation 
> rules of SIP.

I disagree. I think it is essential for the protocol to work that the 
sender MUST follow the procedures of RFC 3824 Section 4. It is a MUST, 
otherwise, this does not work.

I also think the MESSAGE request SHOULD contain a URI-list (it could 
contain any other format if "you really know what you are doing"). The 
URI list MAY contain a capacity attribute. This is something that we see 
in the wire, and it MAY be present at the sender's discretion.

>    Typically, the MESSAGE URI-list service will copy all the significant
>    be cases where the SIP UA wants the MESSAGE URI-list service to add a
>    field wasn't present in the MESSAGE request sent by the UAC.  In this
>    Typically, the MESSAGE URI-list service will copy all the significant
>    be cases where the SIP UA wants the MESSAGE URI-list service to add a
>    field wasn't present in the MESSAGE request sent by the UAC.  In this

I think I disagree: the UAC MAY use the "?" mechanism, it is an option 
for the UAC to either use it or not. At least, according to my reading, 
it falls into Section 5 of RFC 2119.

>    On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list
>    On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list

OK, I agree with the above change.

>       incoming MESSAGE request, subject to the privacy requirements (see
>       incoming MESSAGE request, subject to the privacy requirements (see

I can't agree with the above. This is the normative part that indicates 
how the MESSAGE URI-list service must populate the From, To, and 
Call-ID. Without this normative specification we will not have a 
deterministic way of populating these headers.

> series of "Changes since"  paragraphs that need to be deleted. We should 
> delete these before sending the final doc to the IESG. The only 
> exception to this might be a document that is obsoleting another RFC, 
> and that contains a discussion of changes relative to the RFC being 
> obsoleted.
> 

OK.

Thanks for the review.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Jan 2006 16:12:30 -0600

On Jan 26, 2006, at 10:38 AM, Miguel Garcia wrote:

> Hi Dean:
>
> Thanks for the review. I agree with most of your issues, thus, I  
> don't reproduce them here. But some of them require a bit more of  
> discussion. Please take a look at those issues below:
>
>
> Dean Willis wrote:
>
>> In Section 3, Overview
>> kilograms or 37 recipients. The term is first used in the  
>> overview, section 3, paragraph 3. Perhaps a breakout defining  
>> capacity in thus usage would help. There are also some "s" missing  
>> on the end of words, like "contains". We also don't say what  
>> happens if the "capacity" is unspecified.
>
> Ok, I agree with the proposed new text. We need to evaluate if we  
> can introduce the "capacity" attribute concept earlier in the  
> document.
>
> One point of disagreement is the default capacity attribute, which  
> set to be "bcc". That is already described in Section 4.1. I agree  
> we need to indicate this also in Section 3, but it is to be set to  
> "bcc".
>

Setting to bcc is fine with me, as long as the default gets mentioned  
where the concept is introduced. I clearly missed it later in the  
text, so the average reader (I'm flattering myself by claiming to be  
average) is likely to suffer the confusion.

> 'capacity' attribute MUST be treated as if the 'capacity' was set  

Spiffy.

>> Question: Did anybody formally validate the schema and XML doc in  
>> the example? I'm not an XML guy. Somebody please tell me you've  
>> validated it.
>>
>
> However, I also validated with the validator at http:// 
> validate.openlaboratory.net/ and it complains about the Unique  
> Particle Attribution rule of the resource-list XML Schema (not  
> about the MESSAGE exploder draft itself).  The issue has been  
> discussed in the SIMPLE mailing list, see http://www.ietf.org/mail- 
> archive/web/simple/current/msg05954.html
> Unfortunately, there is nothing I can do to solve this problem,  
> since there is nothing wrong in the XML Schema or the example in  
> this draft.

Hmm. That's supposedly the validator we'll be tested against. Jari  
should know about it . . .

in fact, he said:

"Good catch, yes this schema violates the infamous Unique Particle
Attribution (UPA) constraint (well yet another example that we should
switch using RELAX NG ;-)). It is not about recursion it is about
overlapping wildcards. So the first definition should be removed. Also
there are some processContents="lax" definitions that seem to be
missing, 48hours ?"

so perhaps Jari can now help us figure out what needs to be done.

HELP! Please?

>
>
>> The procedures text in Section 6 uses 2119 language  
>> inappropriately, I think.  This is somewhat subjective, but I  
>> prefer not to use requirements language to describe what something  
>> just does. It should be reserved for places where we're actually  
>> discussing requirements, quoting requirements imposed by other  
>> specifications, and  giving specific guidance on what might  
>> otherwise seem reasonable behavior but will break compatibility  
>> with other systems or elements.
>
>
> Careful here, some of the suggestions make sense, others not.  
> Remember that this are Sections 6, and 7, which are the main  
> normative text of the specification. So this is not an overview or  
> general description.
>

I'd like to point out Section 6 of 2119, which says:

    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability

We have historically habitually overused this language to describe  
basic operating methodology, which I believe conflicts with the  
specifics of the above-quoted section.

>> MUST
> I disagree. I think it is essential for the protocol to work that  
> the sender MUST follow the procedures of RFC 3824 Section 4. It is  
> a MUST, otherwise, this does not work.

Well, there are different theories about 2119-language usage. Clearly  
if the UAC does not create a MESSAGE request, it doesn't create a  
MESSAGE request intended for multiple recipients. But describing what  
something does is not the same thing as requiring what it MUST do.  
For example, the implications of a MUST are that we need to explain  
why it is a MUST and what the consequences of not doing it are, or  
refer to another document that contains that elucidation.

> I also think the MESSAGE request SHOULD contain a URI-list (it  
> could contain any other format if "you really know what you are  
> doing"). The URI list MAY contain a capacity attribute. This is  
> something that we see in the wire, and it MAY be present at the  
> sender's discretion.

But all we're documenting here is a URI-list. So it MIGHT do  
anything, and what we're really saying here is that an implementation  
that supports this specification contains a URI-list. If it contains  
something else, we have nothing here to say about what happens. Why  
SHOULD this request contain a URI-list? If we don't discuss this,  
we're simply saying what it does, not raising a critical point of  
operation worthy of 2119 language.

> I think I disagree: the UAC MAY use the "?" mechanism, it is an  
> option for the UAC to either use it or not. At least, according to  
> my reading, it falls into Section 5 of RFC 2119.

That's possibly supportable. Clearly the MUST NOT above is good, as  
it raises a critical point of interop, and explains WHY that MUST NOT  
applies. But the MAY is in a "Typically" section, so again, we're  
talking a description of how something works, which is not the same  
thing as operational requirements.

> I can't agree with the above. This is the normative part that  
> indicates how the MESSAGE URI-list service must populate the From,  
> To, and Call-ID. Without this normative specification we will not  
> have a deterministic way of populating these headers.
>

I'm willing to agree in principle, but suggest that we should follow  
up by explaining the normativity. Why, for example, is a message  
exploder that is also an anonymizer or reattributor in violation of  
this specification? What does that do to prevent the possibility of  
interoperability?

--
Dean

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 27 Jan 2006 11:43:26 +0200

ext Dean Willis wrote:

>> Particle Attribution rule of the resource-list XML Schema (not  about 
>> the MESSAGE exploder draft itself).  The issue has been  discussed in 
>> the SIMPLE mailing list, see http://www.ietf.org/mail- 
in order to be concrete I'll include a proposal to fix xcap-list schema, 
which can be fixed within author's 48 hours, I'll hope ?

xcap-list spec has an UPA bug, the listType has two overlapping 
wildcards (<xs:any>) and e.g the second one can be removed without 
loosing extensibility:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
    xmlns="urn:ietf:params:xml:ns:resource-lists"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <xs:complexType name="listType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" 
minOccurs="0"/>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:choice>
        <xs:element name="list">
         <xs:complexType>
          <xs:complexContent>
           <xs:extension base="listType"/>
          </xs:complexContent>
         </xs:complexType>
        </xs:element>
        <xs:element name="external" type="externalType"/>
        <xs:element name="entry" type="entryType"/>
        <xs:element name="entry-ref" type="entry-refType"/>
        <xs:any namespace="##other" processContents="lax" minOccurs="0"
                maxOccurs="unbounded"/>
       </xs:choice>
      </xs:sequence>

<!--      <xs:any namespace="##other" minOccurs="0" 
maxOccurs="unbounded"/> -->
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="optional"/>
     <xs:anyAttribute namespace="##other"/>
    </xs:complexType>
...

However,  processContents="strict" is the default value. Attributes do 
not have UPA constraint and they are hardly ever namespace qualified, so 
my preference would be:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
    xmlns="urn:ietf:params:xml:ns:resource-lists"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
     schemaLocation="http://www.w3.org/2001/xml.xsd"/>

    <xs:complexType name="listType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" 
minOccurs="0"/>
      <xs:sequence minOccurs="0" maxOccurs="unbounded">
       <xs:choice>
        <xs:element name="list">
         <xs:complexType>
          <xs:complexContent>
           <xs:extension base="listType"/>
          </xs:complexContent>
         </xs:complexType>
        </xs:element>
        <xs:element name="external" type="externalType"/>
        <xs:element name="entry" type="entryType"/>
        <xs:element name="entry-ref" type="entry-refType"/>
        <xs:any namespace="##other" processContents="lax" minOccurs="0"
                maxOccurs="unbounded"/>
       </xs:choice>
      </xs:sequence>
     </xs:sequence>
     <xs:attribute name="name" type="xs:string" use="optional"/>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <xs:complexType name="entryType">
     <xs:sequence>
      <xs:element name="display-name" minOccurs="0">
       <xs:complexType>
        <xs:simpleContent>
         <xs:extension base="display-nameType"/>
        </xs:simpleContent>
       </xs:complexType>
      </xs:element>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="uri" type="xs:anyURI" use="required"/>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <xs:complexType name="entry-refType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" 
minOccurs="0"/>
      <xs:any namespace="##other"processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="ref" type="xs:anyURI" use="required"/>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <xs:complexType name="externalType">
     <xs:sequence>
      <xs:element name="display-name" type="display-nameType" 
minOccurs="0"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0" 
maxOccurs="unbounded"/>
     </xs:sequence>
     <xs:attribute name="anchor" type="xs:anyURI"/>
     <xs:anyAttribute namespace="##any" processContents="lax"/>
    </xs:complexType>

    <xs:element name="resource-lists">
     <xs:complexType>
      <xs:sequence maxOccurs="unbounded">
       <xs:element name="list" type="listType"/>
      </xs:sequence>
     </xs:complexType>
    </xs:element>

    <xs:complexType name="display-nameType">
     <xs:simpleContent>
      <xs:extension base="xs:string">
       <xs:attribute ref="xml:lang"/>
      </xs:extension>
     </xs:simpleContent>
    </xs:complexType>
</xs:schema>

Then the services schema should import the list schema. However, I'd 
much prefer that the services and list schema would share the same 
targetNamespace (include reference then to services). 

These kind of bugs easily occur as this favorite tool does not (or want 
to) check UPA violations (at least versions that I am aware of). That 
was one reason for setting up the on-line tool 
<http://validate.openlaboratory.net/> which is based on Xerces which 
supports UPA checking.

br,
Jari