RE: broken turtle

can I assume now folks have lost their fear of the evil ASN.1,  that we can add 2 more properties from the implied vocab of certs? just as SubjectAlternativeName  is a multi-value property, of type&format URI, so AuthorityInfoAccess and CRLDistributionPoints are compound types (with trivial URI primitive types/formats), no more complicated than the model Henry wrote up for cert:key. I'm sure there must be a way in RDF-land not to describe something, but just say: its opaque (but distinguished opaque). In 1980s ASN.1 legacy, its called a tagged ANY. Typically its locally tagged, but you can declare it with a global tag, if you must (oid:x.y.z#1).  NSA/DoD's first attempt at a secure messaging spec in ASN.1 was done really poorly and laughably poorly (since the guy knew nothing about proper style). he just took a bunch of legacy bit string formats, and stuffed an ASN.1 global tag on the front of each, describing each thereby as a opaque bit string! Fortunately, folks learned quick to model and describe properly. Engineering duly followed.    AuthorityInfoAccess [
[accessMethod: 
caIssuersaccessLocation: URIName: 
http://rapstr1.blob.core.windows.net/ods/ca.cer
]] SubjectAlternativeName 
[
URIName: 
http://rapstr1.blob.core.windows.net/ods/user.ttl#me  CRLDistributionPoints 
[
[DistributionPoint:
[URIName: 
http://rapstr1.blob.core.windows.net/ods/certcrl.crl]
]]Date: Thu, 22 Dec 2011 21:10:53 -0500
From: kidehen@openlinksw.com
To: public-xg-webid@w3.org
Subject: Re: broken turtle


  


    
  
  
    On 12/22/11 8:56 PM, Peter Williams wrote:
    
      
      
        

        my new cert (old key) with turtle on azure cloud blob service:
        site reports ok. REport 1 URI, correctly.

         

        
          my old cert (old key) with RDFa
            on blogger page : site reports ok. Only reports 1 URI.
           
          ODS cert/key/proxyURI with proxied page (for an original
            twitter account): site reports fail
           
           
        
      
    
    Ah! There are some issues with the Proxy URIs. Myself and Henry had
    a quick one on one session and found two issues. One relates to
    across the wire serialization which we have to fix. The other is a
    niggling issue re. cache invalidation, but you can work around it by
    adding the following to the ProxyURI: ?@Lookup@=&refresh=clean 
    after you place the ProxyURI in your browser's address bar. 

    

    The simple test is this, if you don't see the cert. fingerprints in
    the page that is returned to your browser you know that the
    validation will fail due to incomplete graph. 

    

    

    Example:

    

    One of my ProxyURIs:
    http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen .

    

    Document URL to which the Name above resolves:
http://id.myopenlink.net/about/html/http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen
    .

    

    Forced refresh:
    http://id.myopenlink.net/about/html/http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen?@Lookup@=&refresh=clean
    .

    

    Then retest and it will work, as long as you can see the fingerprint
    in the page (human readable descriptor) returned to the browser. 

    

    

    -- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen