Re: RE: [Geopriv] Consensus on changes to location-conveyance

> So are saying there will be a likely scenario where a ruleset-reference 
> in a PIDF-LO encoded into a data: URI and inserted by a proxy will 
> reference a MIME part that already exists?

We may be talking past each other. Currently, RFC 4119 has

  <xs:complexType name="locPolicyType">
    <xs:sequence>
      <xs:element name="retransmission-allowed" type="xs:boolean"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="retention-expiry" type="xs:dateTime"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="external-ruleset" type="xs:anyURI"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="note-well" type="tns:notewell"
         minOccurs="0" maxOccurs="1"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
    </xs:sequence>
   </xs:complexType>

I assume you're talking about the external-ruleset element. Regardless 
of how the rest of the GEOPRIV object is carried, this can point 
anywhere, including some static web object, a cid, or even be another 
data URL if you want to carry the policy along with the actual location 
information.

Clearly, a cid would be rather implausible if the URL was inserted by 
the proxy.

If this is location by reference, the options for the URL would be the 
same, except for cid.

If this is a location object carried in the body, it could be any of the 
  things I mentioned above. The same is true for the Location-by-value 
option.

As you can probably tell, I'm a bit confused as to why this is an issue, 
so I'm probably belaboring what's obvious to you.

> 
> -andy

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