Subject: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-01.txt

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 19 Jan 2010 14:22:04 +0200

Folks,

Karl Heinz indicated that the current version of the ServiceListBoundary
draft is ready for a WGLC. Here is the latest draft:
http://www.ietf.org/id/draft-ietf-ecrit-lost-servicelistboundary-01.txt

So, please, have a look at this version and provide your feedback.

This WGLC will end on the 2nd Feb. 2010.

Ciao
Hannes & Marc

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 21 Jan 2010 07:52:59 +0800

This document needs a little more attention to the XML, particularly the RelaxNG schema, which I believe has some errors.  The text is clear and readable and the examples convey the intent well, but accurate schema is an important part of these specifications.

I see no reason for the document to stay in the WG once this problem is resolved.

Section 3 (general): 
  Is it intentional to use the same elements for the request and response - they have dramatically different content models.  While possible, this can be confusing, not to mention inconvenient for schema design.  Perhaps the request could be identified differently.

Section 3.1:
 - s/ist/is/
 - I assume that the example civic address boundary is in English? xml:lang="en"

Section 5.1:
  My RelaxNG-fu is not as good as my XML Schema-fu, especially since I prefer the compact syntax, but I think that this isn't right.   Unexplained ellipses are a dead giveaway.

I would have expected something like what I've sketched out below, with the note that the entire <include> section isn't really needed (though this changes where the elements are included - the draft tacks them on the end, as is natural, but the actual extension point is above the locationUsed in the response).

I'll note also that the start element also needs to be redefined.  It's a real nuisance that LoST didn't make this easy by defining a start-group, or by adding notLost to the default start group.  Oh well.

<grammar ...>

  <include href="???lost schema???">
    <!-- redefinition of LoST elements -->

           <start>
       <choice>
         <ref name="findService"/>
         <ref name="listServices"/>
         <ref name="listServicesByLocation"/>
         <ref name="getServiceBoundary"/>
         <ref name="findServiceResponse"/>
         <ref name="listServicesResponse"/>
         <ref name="listServicesByLocationResponse"/>
         <ref name="getServiceBoundaryResponse"/>
         <ref name="errors"/>
         <ref name="redirect"/>
         <ref name="slb:getServiceListBoundary "/>
         <ref name="slb:getServiceListBoundaryResponse"/>
       </choice>
           </start>

       <define name="listServices">
         <element name="listServices">
           <ref name="commonRequestPattern"/>
	     <ref name="slb:serviceListBoundaryRequest"/>
         </element>
       </define>

       <define name="listServicesByLocationResponse">
         <element name="listServicesByLocationResponse">
           <ref name="serviceList"/>
           <ref name="commonResponsePattern"/>
           <ref name="locationUsed"/>
           <choice>
	       <ref name="slb:serviceListBoundaryResponse"/>
	 	 <ref name="slb:serviceListBoundaryReference"/>
           </choice>
         </element>
       </define>

  </include>

         <define name="serviceListBoundaryRequest">
           <element name="serviceListBoundary">
             <ref name="slb:serviceListBoundary"/>
               <choice>
                <value>value</value>
                <value>reference</value>
             </choice>
           </element>
         </define>

         <define name="serviceListBoundaryResponse">
           <element name="serviceListBoundary">
             <ref name="slb:serviceListBoundary"/>
               <attribute name="profile"/>
               <ref name="ls:locationInformation"/>
           </element>
         </define>

         <define name="serviceListBoundaryReference">
           <element name="serviceListBoundaryReference">
             <ref name="slb:serviceListBoundaryReference"/>
               <attribute name="source"/>
               <attribute name="serviceListKey"/>
           </element>
         </define>

<!-- then the get service list boundary stuff, which looks OK -->

</grammar>

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Tuesday, 19 January 2010 11:22 PM
> To: [email-masked]
> Subject: [Ecrit] WGLC for draft-ietf-ecrit-lost-servicelistboundary-
> 01.txt
> 
> Folks,
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Jan 2010 00:05:55 -0500

I generally agree with Martin's comments regarding changes to the XML  
structure, especially having different elements for requesting and  
returning service list boundaries.

I would also like to see a little more explanation in the Security  
Considerations, e.g.:
"
This document extends the LoST protocol [RFC5222] to allow it to carry  
service list boundaries (and requests for them).  While this  
information cannot be directly derived from information in the current  
protocol, it is generally considered to have the same level of  
sensitivity -- namely, it is generally public information -- and thus  
the same access control and confidentiality requirements as the base  
LoST protocol.  As a result, the security measures incorporated in the  
base LoST specification provide sufficient protection for LoST  
messages that use the service list boundary extension.
"

Other than that, I think this document is ready to go.

--Richard

On Jan 20, 2010, at 6:52 PM, Thomson, Martin wrote:

> This document needs a little more attention to the XML, particularly  
> the RelaxNG schema, which I believe has some errors.  The text is  
> clear and readable and the examples convey the intent well, but  
> accurate schema is an important part of these specifications.
>
>  Is it intentional to use the same elements for the request and  
> response - they have dramatically different content models.  While  
> possible, this can be confusing, not to mention inconvenient for  
> schema design.  Perhaps the request could be identified differently.
>
> Section 3.1:
> - s/ist/is/
>  My RelaxNG-fu is not as good as my XML Schema-fu, especially since  
> I prefer the compact syntax, but I think that this isn't right.    
> Unexplained ellipses are a dead giveaway.
>
> I would have expected something like what I've sketched out below,  
> with the note that the entire <include> section isn't really needed  
> (though this changes where the elements are included - the draft  
> tacks them on the end, as is natural, but the actual extension point  
> is above the locationUsed in the response).
>
> I'll note also that the start element also needs to be redefined.   
> It's a real nuisance that LoST didn't make this easy by defining a  
> start-group, or by adding notLost to the default start group.  Oh  
> well.
>
> <grammar ...>
>
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit