Subject: [Geopriv] Common-policy: one MIME type, or MIME-type per using protocol

From: Aki Niemi <[email-masked]>
Date: Mon, 13 Feb 2006 11:29:18 +0200

All,

One bigger issue came to mind when reading common-policy. Currently, 
common-policy defines a MIME type of application/auth-policy+xml, and 
each using protocol that extends common policy, uses that same MIME type.

Would a better model be one where common-policy is an abstract class, 
and each using protocol is a non-abstract subclass that extends the 
common-policy abstract class?

This would mean, that there is no defined MIME type for common-policy 
itself, but each using protocol definition creates one, e.g., 
application/presence-auth-policy+xml and so on.

Since common-policy defines no actions/transformations, and as such 
application/auth-policy+xml alone is of no use, I think common-policy is 
really an abstract class, and following that model would be a better option.

THoughts?

Cheers,
Aki

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

---

From: Andrew Newton <[email-masked]>
Date: Mon, 13 Feb 2006 06:55:40 -0500

On Feb 13, 2006, at 4:29 AM, Aki Niemi wrote:
> One bigger issue came to mind when reading common-policy.  
> Currently, common-policy defines a MIME type of application/auth- 
> policy+xml, and each using protocol that extends common policy,  
> uses that same MIME type.
>
> Would a better model be one where common-policy is an abstract  
> class, and each using protocol is a non-abstract subclass that  
> extends the common-policy abstract class?
>
> This would mean, that there is no defined MIME type for common- 
> policy itself, but each using protocol definition creates one,  
> e.g., application/presence-auth-policy+xml and so on.
>
> application/auth-policy+xml alone is of no use, I think common- 
> policy is really an abstract class, and following that model would  
> be a better option.

Beyond the discussion of super and subclasses, how does this actually  
affect code?  Is there some processing decision you will make about a  
presence-auth-policy vs geopriv-auth-policy based on the MIME type?   
And if so, why can't you make the decision based on the XML namespace?

In my opinion, application/auth-policy+xml is already going too far  
so I don't see a need for applicaton/presence-auth-policy+xml or  
applicaton/geopriv-auth-policy+xml.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Fri, 17 Feb 2006 07:42:58 -0500

On Feb 17, 2006, at 3:30 AM, Jari Urpalainen wrote:

> If you really need to distinguish the "real" content-type from the doc
> (which may not be a problem in practice), looking at some qualified
> elements namespace declaration reference is imo not very nice.

I would hope that it is the things that happen in practice that we  
worry about the most.

If we plan on seeing multiple using protocol based policy documents  
delivered simultaneously, then I see your point.  Otherwise, I think  
this is mime type per using protocol scheme is unnecessary.  That  
being said, it is probably harmless as well.

-andy

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 17 Feb 2006 10:30:25 +0200

> > policy is really an abstract class, and following that model would  
Well I have also proposed this, because common-policy is imo clearly a
framework that needs some additional specs after it can be used with
practical implementations (btw. I have a plan to try to really implement
a proof-of-concept one). And I could go even further and drop the
targetNamespace from the schema and let namespace inheritance do the
trick that instance docs would use only one namespace (as I am not
thrilled with the usage of many namespaces). Also one could use those
dreaded susbstitutionGroups in the schema. 

If you really need to distinguish the "real" content-type from the doc
(which may not be a problem in practice), looking at some qualified
elements namespace declaration reference is imo not very nice. What's
also somewhat weird that schema validation can't tell you what is this
"real" content type, as e.g. a valid presence auth instance doc will be
validated with this base schema as well as with combinations of base
plus many extension schemas. This whole Postel model here is imo not so
simple from client pov (I'll use XCAP reference here as it seems to be
the one proposed practical model), you can put almost anything to the
server regardless whether the server "understands" it or not. Then you
can query the capabilities (at least two proposals) from the server to
see if the server supports your sent semantics. So imo from client pov,
it were far easier if the server just wouldn't approve this data. This
brings another XCAP possibility with the current Postel model, one could
send metadata in the put response so that it would tell the client that
"btw. you used this xxx directive but I (the server) don't support it".
This kind of semantics would probably make the client happier (including
myself ;-)). 

> applicaton/geopriv-auth-policy+xml.
Perhaps this has gone too far (although I may have misunderstood the
implications you refer to, Andy). Anyways other than this issue I think
common-policy looks good and understandable from implementers pov.
br,
Jari

---

From: Aki Niemi <[email-masked]>
Date: Tue, 21 Feb 2006 13:51:43 +0200

> And if so, why can't you make the decision based on the XML namespace?

IFF that identification is always straight forward with namespaces, then 
that will work just as well, in code.

> In my opinion, application/auth-policy+xml is already going too far  so 
> I don't see a need for applicaton/presence-auth-policy+xml or  

I was thinking more of use cases where advertising of specific using 
protocol policy document support using something like Accept in HTTP/SIP 
is needed. In those cases, having a MIME type per using protocol is 
beneficial.

Cheers,
Aki

---

From: Andrew Newton <[email-masked]>
Date: Tue, 21 Feb 2006 07:25:05 -0500

On Feb 21, 2006, at 6:51 AM, Aki Niemi wrote:

> I was thinking more of use cases where advertising of specific  
> using protocol policy document support using something like Accept  
> in HTTP/SIP is needed. In those cases, having a MIME type per using  
> protocol is beneficial.

Agreed.  I withdraw my objection to the additional MIME type.

-andy