Forklar regelen som mislyktes
A BIMI SVG-validatoren bør identifisere kandidataktivaen, regelsettet det gjelder og det eksakte mislykkede kravet. En melding som ugyldig logo er ikke nok til at en designer eller operatør kan korrigere eiendelen på en sikker måte. Validatoren bør skille mellom misformet XML, ikke-støttet SVG-struktur, profilspesifikke begrensninger, mottakeranbefalinger og visuelle bekymringer. Disse kategoriene kan overlappe, men de er ikke utskiftbare og bør ikke presenteres som én udifferensiert feil.
BIMI Groups SVG-veiledning beskriver SVG Portable/Secure som en strengere profil av SVG Tiny 1.2. Den beholdte siden dateres til 2020 og ble tatt for dette manuskriptets kildesamling 8. november 2026. Dette er praktisk gruppeveiledning, ikke en påstand om at det refererte BIMI profilutkastet er en Internett-standard. Ingen validator ble utført her.
Identifiser de nøyaktige bytene som vurderes
Registrer kandidatfilnavn, bytelengde, innholds-hash, kilde- eller eksportmetode og observasjonstid. Hvis ressursen kom fra en URL, bevar de hentede bytene i stedet for å anta at de samsvarer med en lokal designfil med samme navn. En senere opplasting eller bufferendring kan bety at den vertsbaserte ressursen skiller seg fra filen en designer har vurdert. Rapporten bør synliggjøre dette skillet før funn presenteres.
Ikke utfør skript eller følg eksterne referanser bare for å inspisere en uklarert SVG. En defensiv validator bør analysere og analysere eiendelen innenfor dets godkjente trygge miljø. Denne artikkelen foreskriver ikke en bestemt parserimplementering eller hevder at et navngitt verktøy gir den beskyttelsen. Den definerer et krav som skal verifiseres før validatoren blir klarert med faktiske eiendeler.
Skill grunnleggende syntaks fra BIMI profilen
En fil kan være gyldig XML og gyldig under en bred SVG-modell mens den fortsatt svikter den tiltenkte BIMI profilen. Gruppeveiledningen identifiserer nødvendige verdier som versjon 1.2 og baseProfile tiny-ps, og krever et tittelelement. Den forklarer også restriksjoner på eksterne referanser, skript, animasjoner og x- eller y-attributter på rotnivå. En validator bør rapportere det eksakte elementet eller attributtet som er involvert og kilderegelen, ikke bare merke seg at en nettleser kan gjengi filen.
Å endre filnavnet til svg eller pakke inn en punktgrafikk i en SVG-beholder etablerer ikke profiloverholdelse. BIMI Groups SVG feilsøkingsveiledning diskuterer innebygde rasterbilder og andre vanlige problemer. Rapporten bør forklare det strukturelle problemet og lede designeren mot en godkjent vektorkilde eller eksportkorreksjon uten å hevde at enhver automatisert konvertering bevarer det tiltenkte merkekunstverket.
Bevar kravstyrke og mottakeromfang
Gruppeveiledningen anbefaler å holde eiendelen liten og ikke overstige 32 kilobyte; den anbefaler også et beskrivelseselement for tilgjengelighet i stedet for å gjøre dette elementet universelt nødvendig i den siterte veiledningen. En validator bør skille nødvendige feil fra anbefalinger. Å gjøre enhver anbefaling til en fatal feil kan villede brukere like mye som å akseptere et forbudt element i det stille.
Googles BIMI -oppsettdokumentasjon legger til mottakerspesifikke krav og anbefalinger, inkludert en minimumshøyde og -bredde på 96 piksler i sin dokumenterte logoveiledning. Dette er regler med Google-omfang. Validatoren bør identifisere om den sjekker gruppeprofilen, Googles kvalifiseringsveiledning eller begge deler, og bør ikke merke alle mottakerspesifikke tilstander som et universelt SVG-krav.
Gjør funn handlingsdyktige uten å endre betydning i det stille
For hvert funn registrerer du regelidentifikatoren eller kildedelen, alvorlighetsgrad, plassering i eiendelen, observert verdi, forventet tilstand og en foreslått utbedring. En utbedring bør forklare den tiltenkte endringen i stedet for å redigere filen i stillhet og kalle den fikset. Å fjerne en referanse, konvertere tekst til baner eller endre geometri kan endre visuell betydning og trenger en passende designgjennomgang.
Hvis verktøyet tilbyr automatisk reparasjon, behandle den reparerte ressursen som en ny kandidat med sin egen hash og funn. Behold originalen og vis de nøyaktige endringene. Reparasjonen skal ikke legge til et juridisk krav om logoeierskap eller sertifikatkvalifisering. Ingen automatisk reparasjon, bildegenerering eller aktivumtransformasjon ble utført for dette manuskriptet, og ingen påstått ren validator-utgang er levert.
Behold utseende og tilgjengelighet som separate anmeldelser
En strukturelt gyldig fil kan fortsatt være vanskelig å gjenkjenne i en liten avatar, ha dårlig kontrast eller inkludere en unyttig tittel. En visuell gjennomgang bør vurdere den tiltenkte visningskonteksten, mens en tilgjengelighetsgjennomgang bør undersøke den relevante tekstbeskrivelsen og presentasjonen. Ingen av dem kan utledes utelukkende fra et skjema eller profilpassering. Verktøyrapporten bør merke disse vurderingene åpne inntil faktiske bevis eksisterer.
Ikke lov at en bestemt mottaker vil gjengi filen nøyaktig som en lokal forhåndsvisning. Mottakerens visningsadferd, beskjæring og kvalifisering kan variere. En forhåndsvisning er kun bevis for det forhåndsvisningsmiljøet. Den endelige akseptoppføringen bør identifisere hvilken gjengiver eller klient som ble observert og unngå å utvide resultatet til alle postboksleverandører uten støtte.
Bekreft den vertsbaserte ressursen separat
Katalogen krever en offentlig HTTPS-henting med innhold og sertifikatbevis i tillegg til kandidat- og validatorfunnene. Hentingen skal identifisere det forespurte endepunktet, responsstatus, observert innhold, byte eller hash, tidsstempel og TLS valideringsresultat. Det bør fastslå om de vertsbytene er den vurderte ressursen, ikke bare om en nettleser viste noe visuelt lignende.
HTTPS-transportvalidering er forskjellig fra en VMC eller CMC knyttet til logoen. Googles oppsettsveiledning krever HTTPS-hosting og beskriver støttede mark-bevisfiler, men et gyldig vertssertifikat beviser ikke utstederens godkjenning av logoen. Ta vare på begge grensene i akseptprotokollen. Det ble ikke hentet noe offentlig endepunkt for en ressurs her, og ingen TLS forbindelsesbevis er hevdet.
Et regneark for valideringsfunn
Lag et regneark med kandidat-hash, regelsett kilde og versjon, parser- eller validatorversjon, hvert funn, utbedringseier og vurderingsstatus. Legg til separate rader for strukturell gyldighet, profilkrav, mottakerspesifikke forhold, anbefalinger, visuell gjennomgang og tilgjengelighet. Den vertsbaserte aktivadelen skal koble sammen hentebeviset og angi om hashen samsvarer med den godkjente kandidaten.
Bruk kontrollerte inventar for en ren kandidat og utvalgte feil, men ikke fabriker resultatene deres. En test skal vise det forventede funnet og det faktiske beholdte resultatet, inkludert tilfeller validatoren ikke kan vurdere. Hvis et krav trenger menneskelig dømmekraft, merk det som sådan i stedet for å tildele et automatisk pass. Regnearket som foreslås her forblir ubefolket med originale eiendelbevis.
Fiktiv diagnose: en nettleservennlig rasteromslag
En fiktiv designer eksporterer en fil som åpnes riktig i en nettleser, men som inneholder innebygde punktgrafikkdata. Teamet antar at den vellykkede forhåndsvisningen betyr at logoen er klar for BIMI . Den foreslåtte valideringsgjennomgangen identifiserer at den relevante profilveiledningen ikke godtar den strukturen og forklarer det mislykkede kravet i stedet for å skylde på et uspesifisert visningsproblem.
Designeren ville gå tilbake til en godkjent vektorkilde og sende inn en ny kandidat for strukturell og visuell gjennomgang. Teamet vil deretter verifisere de vertsbyte og HTTPS-bevis separat. Dette scenariet er fiktivt: ingen aktiva ble opprettet, konvertert, lastet opp eller validert. Den illustrerer hvordan et nyttig funn kobler en teknisk begrensning til et trygt neste trinn uten å love mottakervisning.
Slipp kun med originalbeviset
Katalogen krever kandidatressurs, validatorfunn og en offentlig HTTPS-henting med innhold og sertifikatbevis. Alle tre forblir åpne. Gjennomgang av menneskelig spesialist, kildeanvendbarhet, produksjonsruter, tilgjengelighet og eierfrigivelse forblir også åpne. Dette utkastet beskriver foreslått validatoratferd og en fiktiv diagnose, ikke et fungerende verktøy eller testet EmailAuth funksjon.