[Geopriv] review comments on draft-thomson-geopriv-held-beep-00.txt

http://www.ietf.org/internet-drafts/draft-thomson-geopriv-held- 
beep-00.txt

Overall impression: As of today, too little is likely known about  
these systems to warrant a hammer solution such as a BEEP binding.   
Take it from a guy who has an RFC about another application that has  
a BEEP binding.  This is definitely something that could be done at a  
later date when such an optimization is known to be needed, because  
getting BEEP right is not easy.

1) Since the H in HELD stands for HTTP, I guess the HELD name will  
need changing.  :)

2) The introduction does not completely frame the usage scenario, as  
it uses the word "requester" as the actor making multiple requests.   
It should say "client LIS" or "client LS", as LIS-to-LIS  
communications is where a BEEP binding would be used.  This binding  
makes no sense in Target-as-LR to LIS communications.

3) The justification for using BEEP is that multiple HTTP connections  
are bad.  Why?  Many, many multi-tier servers work this way, with the  
app server maintaining a pool of persistent TCP connections to its  
back-end database.  I remain unconvinced that this BEEP binding is  
anymore efficient for the purpose outlined than multiple HTTP  
connections.

4) The BEEP profile stated does not use the standard BEEP convention,  
and instead overloads the XML NS URN.  That's two sins in one  
registration.

5) There is no discussion of how the serverName attribute gets  
populated, or what happens when the attribute is absent.

6) At least we can agree on Section 6.  :)

-andy

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv