AW: [Simple] Expressing XML support for common-policy and extensions

["Tschofenig, Hannes" <[e-mail]>]

hi martin, 
 
> Hi Hannes,
> 
> Thanks for reading the draft and giving me some feedback.
> 
> I can't help but feel that you have missed my point.  Yes 
> those documents are meant to do the same thing, but I think 
> it far preferable to have that thing done once, in a way that 
> can be repetitively applied.  This problem exists, not only 
> for IETF extensions, but also to extensions introduced by 
> other bodies and private vendors.  Simply saying that the 
> work could be included in another document dodges the issue.  

my comment regarding including the content into another document was
meant to address the aspect of having one additional document per
authorization policy document. 
we could also move the "capability" stuff into the respective document. 

to me it seems that the approach suggested by jonathan was simple enough
to deal with this extensibility functionality. my goal is to try to keep
things as simple as possible. with
<draft-ietf-simple-common-policy-caps-00.txt> the approach was exercised
once and can be used with additional extensions. so far there aren't too
many extensions. hence, there is no problem of dealing with extensions
of other organizations and private vendors. the authorization policies
developed in geopriv are not meant to offer a generic policy mechanism,
such as xacml, to keep it as simple as possible. 


> 
> With regards to complexity, I believe that you have a valid 
> concern, but that is limited in a few ways.
> 
>  - Because the level of abstraction I chose is quite general, 
> this specification is written in a way that addresses a very 
> large problem space.  For that reason, it has to cover a 
> large amount of corner cases.  This is the case with many 
> generalized specifications.  However, when these 
> specifications are applied, the complexity is often 
> invisible.  For instance, based on my experience with the 
> WSDL 2.0 spec, at first read is daunting, but its application 
> is quite simple and elegant.
>    This document is a base-level specification that requires 
> other specifications to define how it is used.  The using 
> specification can limit the functionality in any way 
> necessary to determine the level of complexity that is deemed 
> necessary.  The XPath profile I defined is included for this reason.
>    If this was applied to common-policy, I could see that 
> much of the complexity could be removed, since the 
> requirements aren't very great.


> 
>  - This document enables a "write once" software module - you 
> should not underestimate the advantages of not having to 
> update software.  In my experience, many software development 
> houses are willing to accept a small cost of complexity when 
> other factors are favorable: features, reuse, code size, 
> performance, and available third party implementations.
i don't see that the other approach requires a complex implementation
instead./ 

ciao
hannes
> 
> Ta,
> Martin
> 
> > -----Original Message-----
> > From: Tschofenig, Hannes [mailto:[e-mail]]
> > Sent: Thursday, 5 January 2006 8:31 PM
> > To: Thomson, Martin; [e-mail]
> > Subject: AW: [Simple] Expressing XML support for common-policy and
> > extensions
> > 
> > hi martin,
> > 
> > > After reading Jonathan's common-policy-caps draft [1] and the
> > > related pres-policy-caps [2] and geopriv-policy-caps [3], I
> > > came to the realization that the subsequent documents all do
> > > exactly the same thing.
> > 
> > they are meant todo the same thing.
> > they just indicate capabilities with respect to the common policy,
> > presence authorization policies and the geopriv policies.
> > 
> > >
> > > Once the protocol components related to XCAP have been dealt
> > > with, the specification of a document format and schema is
> > > largely a copy-and-paste job.  This is nice in one respect -
> > > these documents are very simple and elegant - but a long time
> > > spent with code triggers the refactoring neurons.  Where a
> > > pattern exists, there is redundant code.
> > >
> > > In order to use capabilities, every common-policy extension
> > > requires a matching capabilities specification.  That extra
> > > specification contains little, or no, additional value.
> > 
> > each new document could just put these capabilities in the main
> > document.
> > we could do the same.
> > 
> > >
> > > With this thought in mind I have taken the problem and
> > > applied an additional layer of abstraction to create a
> > > document format that should address all extensions.  In some
> > > way, this is inspired by the elegant simplicity of Schematron
> > > [4].  I hope that this one draft will suffice where many
> > > would have been before:
> > >
> > > http://www.ietf.org/internet-drafts/draft-thomson-simple-expre
> > > ssing-xml-support-00.txt
> > >
> > > I think that the solution retains much of the simplicity of
> > > the original offering, while providing enough flexibility to
> > > accommodate future extensions.  I also suspect that it could
> > > be easier to implement, and it will certainly be easier 
> to maintain.
> > >
> > > So, I'd like some feedback, if you have time to read the
> > > draft.  Is this an acceptable tradeoff between the various
> > > factors (simplicity, specification work, etc...)?  I have
> > > some ideas on how this could be integrated with the existing
> > > capabilities work, is that a good idea?
> > 
> > i am not sure i like the idea. to me it seems like another way to
> > complicate things. they are certainly many different ways 
> to accomplish
> > the same thing but why do we need to search for a more complicated
> > solution when we have a simple one?
> > 
> > ciao
> > hannes
> > 
> > > Cheers,
> > > Martin
> > >
> > > [1]
> > > http://www.ietf.org/internet-drafts/draft-ietf-simple-common-p
> > > olicy-caps-00.txt
> > > [2]
> > > http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-pol
> > > icy-caps-00.txt
> > > [3]
> > > http://www.ietf.org/internet-drafts/draft-guenther-geopriv-pol
> > > 	
> > > [4] http://www.schematron.com/overview.html
> 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may
> contain privileged, proprietary, or otherwise private information.  
> If you have received it in error, please notify the sender
> immediately and delete the original.  Any unauthorized use of
> this email is prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]
> 

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