Dear all
I think that the mapping of standard names plus other CF metadata to other
metadata conventions such as PCMDI and GRIB is an important task and a valuable
resource. At the start of the CF convention, we put the correspondences into
the standard name table to make standard names more
Dear @larsbarring
Yes, I take the point, which is also partly what I replied to @jonathanlilly.
I'd prefer to say something more general than just referring to `cell_methods`.
Would this be OK:
> For **many** applications it **is** desirable to have a more definitive
> description of the
Thanks, David. Yes, I will write a pull request with this text if no-one
objects soon.
--
Reply to this email directly or view it on GitHub:
In
https://urldefense.us/v3/__https://github.com/cf-convention/discuss/issues/155__;!!G2kpM7uM-TzIFchu!mfJaB4CUzVG70gMwLsn4NCDOHB_EztOTEMDN2iHwJ1ozSQQSyUZf2ptPvesV5t40hwcl518oMxw$
@jonathanlilly has pointed out that the current text of section 3.3 might
appear to mean that a given
@JonathanGregory approved this pull request.
Thanks. That looks fine to me.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/365*pullrequestreview-960286146__;Iw!!G2kpM7uM-TzIFchu
I suggest that we change the `GitHubProblem` label to `GitHubUsage`, which is
how we describe this kind of issue. It's not necessarily a problem with GitHub.
(Note: this is a self-referential issue - I hope that won't cause GitHub to get
caught up in an infinite loop.)
--
Reply to this email
Thanks, Daniel @erget. That's fine. Sorry for my stupidly long title, caused by
my submitting the comment prematurely.
--
Reply to this email directly or view it on GitHub:
Dear all
For standard names, we have a [list of
contributors](https://urldefense.us/v3/__http://cfconventions.org/Data/cf-standard-names/docs/standard-name-contributors.html__;!!G2kpM7uM-TzIFchu!niIjD3kreMRHY9v0W7C7kf4w00GEGeKFjk3qn9mrigSleDVUasU9aEszSF3JGW9qixj8SPygUdc$
), with a preamble
Also, where is "the nice change of moderators announcing the merge date and
then merging on that date" written down? The answer to this may be the same as
the last one! Thanks.
--
Reply to this email directly or view it on GitHub:
Reopened #275.
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/275*event-6464162232__;Iw!!G2kpM7uM-TzIFchu!k1UOiY9QtDNbL91UkG_GgTimusYyxRr_EkH_QquoRAbEGsqyxwgsMzm77NQFNT-gXxUW2svjA9U$
You are receiving this
To record David’s suggestion of making a comment in the issue when the summary
is updated, in order that everyone will be notified, and also because the
moderator’s summary is part of the discussion and needs to be recorded therein
for the discussion to make sense when read subsequently
--
Dear Daniel @erget and @sadielbartholomew
This looks fine to me as well. Thanks
Jonathan
--
Reply to this email directly or view it on GitHub:
This is a defect and no-one has objected, so the [pull
request](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/350__;!!G2kpM7uM-TzIFchu!lBUahs6WGshdybBiWzFkByrfOTHZ-y29SK_9Afjvr5-vvB1dGxQ1_h-w1oJLK6BGqDq-26oWOl8$
) could be merged today. Please could someone
Those changes look fine to me, thanks, David. The clarification is useful.
--
Reply to this email directly or view it on GitHub:
Dear @davidhassell
Thanks for summarising the discussion up to now and writing the pull requests.
As far as I know, this covers everything. The proposed changes look fine to me
from a CF point of view. I noticed three small things:
* In Appendix I (the data model), you describe the new
Dear @zklaus
I've done a [pull
request](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/350__;!!G2kpM7uM-TzIFchu!h_4-L8njdnQuYrvIVsBWFfZZyiaEw7GB2tpt1NklqxCHzaGqwx_s6szUJC6W_hRzXiEzSDkGdyU$
) to delete the `Conventions` attribute in the two examples, [as
See issue 349 for discussion of these changes.
# Release checklist
- [NA] Authors updated in `cf-conventions.adoc`?
- [NA] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
Dear @zklaus
I don't think there are any "full examples" in the document. (This [new
issue](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/348__;!!G2kpM7uM-TzIFchu!lZI1e-2iPbokQ-LIbAFuEADT9eEzUL6k3p_RYXQdo1Ee5Nx1UkSEuM8EXIqqHr3JsxfhxSZhQl8$
) is relevant to
Dear @atmodatcode
Thanks for your proposal. In fact the [rules for changing the
conventions](https://urldefense.us/v3/__http://cfconventions.org/rules.html__;!!G2kpM7uM-TzIFchu!gylT2XXC8WSaHPC0A1ZMshzVxtz2GadZcG5Fz59sWJO_IdgIryZzsIaHo6OzakimUdXLFw9fPks$
) require a test file to be produced for
Dear @zklaus
As @adigitoleo says, there are no examples in the document which contain the
`Conventions` attribute except in sect 7.5 (examples 7.15 and 7.16). Therefore
I'd suggest you _delete_ the `Conventions` attribute in those two examples,
instead of correcting it. It's not necessary
Dear @davidhassell
Thanks for explaining about milestones. As a test I have just attributed the
[closed issue about lossy compression by coordinate
That's clever, @zklaus. Thanks. I agree with @erget, and I am not an expert on
the build workflow.
--
Reply to this email directly or view it on GitHub:
> @JonathanGregory I agree that a per-release entry in History would make sense.
OK. If others agree, this is something we could introduce in 1.10, and it might
not be too hard to insert those headings for all the previous versions.
> What you propose regarding labels would work, al
Thanks
--
Reply to this email directly or view it on GitHub:
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/129*issuecomment-1006663320__;Iw!!G2kpM7uM-TzIFchu!inhZSwNqcSngidTPij8gVZ1YpNxYhO5xE3JBYPtrTLoXrxpCrW89S7d3dLzvQakqCJ5qOTWe5FY$
You are receiving this
The PR is
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/346__;!!G2kpM7uM-TzIFchu!l4h76Wxxnb3d7vg0CfHEc_Q6ifhKedEAAGxCk42s6xr2QZgkgpdY8Q1s7upJsWX9bde5KuXOMKE$
--
Reply to this email directly or view it on GitHub:
See issue #129 for discussion of these changes.
- [N/A] Authors updated in `cf-conventions.adoc`?
- [N/A] Next version in `cf-conventions.adoc` up to date? Versioning inspired
by
I agree with putting `draft` in the current-version. I think it would be a
positive advantage if it turns up e.g. in `Conventions` (in the text of the
draft document), because that makes the status obvious. In fact maybe we could
be more explicit and say e.g. `:current-version: 1.10 draft (not
Discussion in review comments of
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344__;!!G2kpM7uM-TzIFchu!lLnLFd19gThcoMUaRLU_pBH4VxrLNZCKKoySzJQnQfoNQoRM5jsViIxya-aghDFqq-QhUmVjGFI$
reproduced here for the record. (May I politely and respectfully remind
Separately, I would like to suggest that when we close issues in this
repository which have been agreed to be implemented in the next release, we
should add another label that indicates this e.g. "1.9" for all the ones added
to the present version. Those new labels can all be the same colour,
We could put headings in the history section (in `history.adoc`), starting a
new one in each new release. Thus, the history section in the present draft
would begin with a title something like "Differences between 1.9 and 1.10", and
there would be nothing there. Just to be clear, we could write
Aha! Quite right. I did only half the job. :-) I will write the PR.
--
Reply to this email directly or view it on GitHub:
Please could someone merge this pull request, which qualifies for acceptance
today. Thanks.
--
Reply to this email directly or view it on GitHub:
Dear @zlaus, @erget, @davidhassell et al.
Thanks for the
[PR](https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/344__;!!G2kpM7uM-TzIFchu!nCorpr1w3xsiQ29-ZyQWgmXIFudxCW5wd2GqSaOFhrXPhujPZREoH3m0_nr7RyAKYpj6ZWWJJgg$
), Klaus. I agree that you've provided a neat
Dear all
Two points were made in this issue at the outset, but I believe that only one
remains, so I have changed the title accordingly. The proposal is to change the
standard name schema to permit an `alias` to have more than one `entry_id`,
given that there is one use-case for this. Have
Dear @castelao
Do you have time to put forward your suggestion of 4th October 2021 again,
updated if required given the following comments, as a definite proposal? It
would be good to bring this issue to a successful conclusion, given that it's
been running for four years. Thanks to everyone
Dear all
Thanks for pointing it out, Leon @adigitoleo. I think @zklaus is right that we
could add a "replacement" i.e. a sort of macro in AsciiDoc for the current
version number, so that only one occurrence needed to be changed. I am not
familiar with the build process so I won't volunteer to
Dear Dave @dblodgett-usgs
This issue is an old one (from two years ago) that has gone dormant, it
appears. I have now labelled it as a defect issue because it's a problem with
the conventions document being unclear. Since this issue is in the conventions
repo, we should make a definite
I don't see this proposal in the [status
list](https://urldefense.us/v3/__http://cfeditor.ceda.ac.uk/proposals/1?status=active===*and*display=filter__;Kys!!G2kpM7uM-TzIFchu!lECeYBYi10zaYFEin_M2ILIgcWncH5SSqlbgcPKsJ0JyXdh-OveuEYB0DFxyjOFKG4sK6NmqtmQ$
). I wonder whether it has been overlooked. I
I think that it would be OK to require the same data type as well the same
value. In fact I slightly prefer identity of both type and value, because to me
it seems that providing something which is _exactly_ redundant is more like
providing nothing at all, which is what we want.
--
You are
Dear @zklaus
There is an [open
issue](https://urldefense.us/v3/__https://github.com/cf-convention/cf-convention.github.io/issues/182__;!!G2kpM7uM-TzIFchu!iEjodabCgXX7UCEgD4k7fCnGM1gdzbMeMaLri_x_3tY0RmwDL8v8aErkAkx4GpLMuhQgNNVGX2w$
) in the website/governance repo about the licence which the
PS and if it contains neither `random` nor `systematic` it must be the combined
or total uncertainty.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear @kenkehoe
I suggested the keyword `standard_error` as the cell method for the uncertainty
because, if I understand correctly, the number which is provided will be used
mathematically as if it were a standard deviation quantifying the uncertainty
distribution. For example, 2.3.1 of the GUM
Dear @kenkehoe
You write
> Requiring the data producer to explain the full process in a `cell_methods`
> attribute that the data user will only glance at is an excessive requirement
> on the data producer, if even possible
and I agree that that. I didn't suggest such a requirement myself. In
It is possible that this proposal hasn't been noticed by the managers of
standard names because this is an issue in the cf-conventions repository.
Proposals for standard names should be made in the [`discuss`
Sorry to be unclear. Let me try again. The default cell methods (`point` for
intensive quantities, `sum` for extensive) are for a quantity which in
principle has a single value within the gridcell, either exactly at the
coordinate (for `point`) or being a property of the entire cell (for
Congratulations and thanks to all who contributed to this successful piece of
work.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear Ken
Yes, the `standard_error` modifier is not in `cell_methods` because it doesn't
relate to a particular dimension. But considering (as I said above) that the
statistical standard error of a quantity is 1/sqrt(N) times the standard
deviation over an imaginary `realization` dimension
Dear @AndersMS @erget et al.
I would be pleased to merge the pull request and close this issue, but I see
that the PR has conflicts which have to be resolved. I expect there is some
GitHub incantation which you can pronounce to resolve them.
Best wishes
Jonathan
--
You are receiving this
Dear @kenkehoe
I would encourage you to read
https://urldefense.us/v3/__http://mailman.cgd.ucar.edu/pipermail/cf-metadata/2013/006106.html__;!!G2kpM7uM-TzIFchu!lZZH8Apa50IIV-ZHQPUXbsCoA3pgLyGBPuCd3BHyiQUobcDr2sUpqlPxLfwBqp77DRLKswA8O4g$
if you haven't, because there's a lot of a discussion
Correction to what I wrote yesterday:
> You would also like to be able to provide intervals when not symmetrical.
> That could be done by adding a size-one dimension for probability or
> percentile, with bounds to specify the interval e.g.
> `air_temperature(time,lat,lon,probability)`, where
Dear Ken
I have had time at last to study and think a bit about your detailed proposal.
Thank you for preparing and presenting it. I appreciate it's frustrating for
you that this issue is going slowly. Speaking for myself and from David's
comments too, I believe this is because it is a large
Thank you very much for working on this, Sean @lesserwhirls and
@sadielbartholomew. Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear @AndersMS
Thanks for the clarification. That's fine. The proposal will be approved this
Friday 24th if no further concern is raised.
Best wishes
Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Thanks, @davidhassell and @erget. Would this be related to
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/297__;!!G2kpM7uM-TzIFchu!ldCjcATTRzYiHzENIBJdcrxtyG3aodAE-e6df-ZC1Nhb8ehnrobaOxnxFsLXvK2lvcq1iNanJDU$
, which is one of the outstanding issues that Daniel
Dear @AndersMS @davidhassell @erget @oceandatalab and collaborators
Thanks for the enormous amount of hard and thorough work you have put into
this, and for answering all my questions and comments. I have no more concerns.
Looking through the rendered PDF of App J, I see boxes, probably
Closed #315.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This pull request was implemented by
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331__;!!G2kpM7uM-TzIFchu!heS__3pgZweRnRAyOq4Fwh7enKjvrPvzuWgQwOPbKxXS4n-NS04-Pcahh3PS7_06bgeTAGEfOCo$
instead
--
You are receiving this because you are subscribed to this
I notice that the changes made by the merged pull request
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331__;!!G2kpM7uM-TzIFchu!lgJSAvLW1eEgCI0paKZqxbe7oBj0BH614EQ-7fdV4WSkvJs5XgiDuypNBelLjeWGT41nX8qzoPI$
(the recently agreed changes to time coordinates and
Dear Chris and David
I agree that UGRID uses a discrete axis. There isn't necessarily any ordering
implied by such an axis, just as in the case of UGRID. For example, ocean
basins or other geographical regions may be arranged along a discrete axis in
any order.
Best wishes
Jonathan
--
You
Dear Chris and David
Thanks for this discussion.
In David's revised text
> Unlike the domain topology construct's connectivity array, a
> UGRID connectivity variable's data is not stored as a symmetric matrix that
> indicates the connectivity between any two cells. Instead, the trailing
>
Dear @AndersMS
Thanks for your detailed replies. I think there are only two outstanding points
in those you have answered.
**18**: Now I understand what you mean, thanks. To make this clearer to myself,
I would say something like this: Bounds interpolation uses the same tie point
index
Dear all
@AndersMS and colleagues have proposed a large addition to Chapter 8 and an
accompanying new appendix to the CF convention, defining methods for storing
subsampled coordinate variables and the descriptions of the interpolation
methods that should be used to reconstruct the entire
Dear @AndersMS and colleagues
Thanks again for the new version. I find it very clear and comprehensive. I
have a few comments.
## Chapter 8
"Tie point mapping attribute" mentions "target dimension", which is not a
phrase used elsewhere. Should this be "interpolated dimension"?
You say, "For
Great, thanks, @AndersMS. I am still learning about GitHub. I was using the
Diff, which doesn't show the diagrams, rather than Viewing the file, which
works fine. Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I don't know about this subject, but the construction of your proposed standard
name looks fine to me, thanks, @angilkaka
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
There have been no further comments for three weeks and sufficient support has
been expressed, so this change is therefore accepted according to the rules. I
have merged
Closed #298.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
There have been no further comments for three weeks and sufficient support has
been expressed, so this change is therefore accepted according to the rules. I
have merged
Closed #319.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear @AndersMS et al.
Thanks for the new version. Can you tell me where to find versions of Ch 8 and
App J with the figures in place? That would make it easier to follow.
I've just read the text of Ch 8, which I found much clearer than before. I
don't recall reading about bounds last time. Is
Dear @AndersMS
Thanks for the update and your hard work on this. I will read the section again
in conjunction with Appendix J, once you announce that the latter is ready.
Best wishes
Jonathan
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly
Dear David
It's a good point that there may be domain axes which aren't involved in the
topology. Thanks for the correction. We can supply a ?? topology construct
provided it refers to a single domain axis (the UGRID case). I'm not sure there
would be more than topology for a domain, although
Dear @kenkehoe
Thanks for making this proposal. I realise that three months has passed. I
regret that I have not yet had time to study and review it, although it's been
on my agenda all this time.
Best wishes
Jonathan
--
You are receiving this because you are subscribed to this thread.
Thanks, David. If @zklaus and others are also content with the new version, I
suppose it can be accepted three weeks from three days ago, which makes 23rd
July
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
I have made the above changes in
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331__;!!G2kpM7uM-TzIFchu!j38U3qLQlY_X0BZe90tjIihK2dPqHw10OAiefFShqA-jvFxq5MnK0f5JSKxZWbrBetRQ8wtDZnw$
--
You are receiving this because you commented.
Reply to this email directly
@JonathanGregory pushed 1 commit.
bd7498d3625a1ee464f375952bfd202f7fbc4371 remove redundant text about the
standard calendar, clarify the deprecation of year and month units
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://urldefense.us/v3
I realise that we agreed to delete the existing excerpt from the UDUNITS that
describes the `standard` calendar, because we have put that information in the
description of that calendar. I will modify the PR.
I agree with the point @zklaus makes about the deprecated units. Would the
following
@zklaus has made the following comment on the PR
> Perhaps this is a good opportunity to update the second udunits.dat link in
> the following line 217 as well.
> I also wonder if we should be explicit in whether CF follows udunits in the
> definitions of year and month. The way these two
I have prepared
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/331__;!!G2kpM7uM-TzIFchu!mNWKCPD7VbPgGv_jRavr4GE1sCQvz38p0d0wECjY2cjx2_dyEClYOuM6TDVCriSLMMu-I2CF82c$
for this issue and
See issue #298 and #319 for discussion of these changes.
# Release checklist
- [Y] Authors updated in `cf-conventions.adoc`?
- [Y] Next version in `cf-conventions.adoc` up to date? Versioning inspired by
I agree that a cell which is an edge bounded by two nodes is fine in the CF
data model, yes. (H) is correct that CF doesn't explicitly recognise
connectivity, although you could infer it from coincidence - isn't that right?
Jonathan
--
You are receiving this because you are subscribed to this
Dear @AndersMS. Daniel @erget et al.,
> Concerning terminology, following discussion in the group, these terms seem
> good candidates:
> At tie-point level: "subsampled dimension", "non-interpolated dimension"
> At reconstituted level: "interpolated dimension", "non-interpolated dimension"
Dear @AndersMS
In your proposed change 10, you used the word "uncompressed", and "compression"
is in the title of this proposal. I think it would be clear to speak of a
"compressed dimension" of the tie point variable corresponding to an
"uncompressed dimension" of the data variable, or
Dear @AndersMS and colleagues
Thanks very much for taking my comments so seriously and for the modifications
and explanations. I agree with all these improvements, with two reservations:
* Do you somewhere state that the size of a tie point interpolated dimension
must be less than or equal to
If everyone is content with the proposed text, I will make a new pull request
for this issue. In the pull request, I will add Dave Allured to the CF authors
in recognition of his raising the issue and the work he has done on it (unless
he would prefer not). Jonathan
--
You are receiving this
Dear @larsbarring and @davidhassell
Taking Lars's points in reverse.
* I agree with what David proposes for referring to UDUNITS instead of
`udunits.dat`.
* It seems better to me not to have an independent entry for the deprecated
`gregorian`, which would make it more prominent than it is
Dear @davidhassell
Yes, you're right, this does cover
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/issues/319__;!!G2kpM7uM-TzIFchu!hxPKoGI8TGUACUdtrAodtIQisuZ020j3_v0TScwJ4hPfPjXCGGGyfjarhA1OoOMKO8U4VW2Ogqg$
. I hadn't thought of that, but it could be convenient
Dear @AndersMS and Daniel @erget
I see. I misunderstood. If you think my version of the revised paragraph is OK,
it's fine to include it in your pull request for
Dear Daniel @erget
I think it's fine to make this a separate issue, but in that case, will you
leave that paragraph unchanged (as in version 1.8) in
I agree. This specification of precision is good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear all
I have drafted a new version of the affected parts of the text of Sect 4.4,
taking account of the comments made since the pull request was revised, mostly
as suggested but not quite, as follows:
* I included the deprecation of `gregorian` from [issue
Dear @davidhassell et al.
I will produce some text synthesising the comments made since the current pull
request was written.
Since then, the preamble on calendars has been modified as a result of the
agreement of [issue 313 on leap
A `strict_gregorian` calendar would be one which is Gregorian and *must not* be
used before 1582 i.e. that would be an error, whereas `proleptic_gregorian` can
be used both before and after 1582 without error or warning - that is the point
of it. However, I am not in favour of
This is fine, thanks. If we agree, I suppose that we need to write propose some
textual changes in the CF documents for some of these points.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Dear all
I've studied the text of proposed changes to Sect 8, as someone not at all
involved in writing it or using these kinds of technique. (It's easier to read
the files in [Daniel's
I too agree with @davidhassell's proposal. I don't know how to deal with it in
the GitHub repository but I don't think we should be prevented from editing
past versions when (like this) it doesn't alter the convention.
--
You are receiving this because you are subscribed to this thread.
Reply
Dear @zklaus
> We don't have to distinguish positive and negative categories, because they
> are logically related: prohibition = negative requirement, deprecation =
> negative recommendation.
Sorry to be unclear. I meant by this to explain that the conformance document
has only two
Dear all
I'd like to repeat my earlier points that
* We should make use of the existing list, namely the conformance document,
for the purposes being discussed here - I don't think we need a new list.
* We don't have to distinguish positive and negative categories, because they
are
Dear @ethanrd
I would favour simplicity. At the moment, we have two categories in the
conformance document. (1) Recommendations to do something. A recommendation not
to do something is a deprecation. The CF checker gives warnings for
recommendations (including deprecations) that are not met.
I have updated the pull request
https://urldefense.us/v3/__https://github.com/cf-convention/cf-conventions/pull/317__;!!G2kpM7uM-TzIFchu!j5sMTufUekY0HbDkylC29GsZhOicrvn4eaiu8d7agPsFgB2NY8H-NKq-dNTw405OXfD2DYUwfRg$
to include the proposed deprecation text. If there are no further comments,
it
1 - 100 of 309 matches
Mail list logo
