Loading ...
Sorry, an error occurred while loading the content.

Re: [rss-public] Re: isn't clearly defined

Expand Messages
  • James Holderness
    ... That would be RFC1036. I m not sure how best to word it, but my suggestion for spec text would be something like: No particular address format is
    Message 1 of 29 , Dec 8, 2006
    • 0 Attachment
      Geoffrey Sneddon wrote:
      > Surely we should have some formal definition of what the importance
      > of the final comment in <author> is, though?

      That would be RFC1036.

      I'm not sure how best to word it, but my suggestion for spec text would be
      something like: "No
      particular address format is prescribed, but the comment format documented
      in
      RFC1036 is recommended." Possibly follow that up with exactly details of the
      format and example usage.

      Since the original spec doesn't actually give a formal definition of what
      the address should be, we can't forbid other address formats that people
      have chosen to use, but I think it's fair to at least recommed the RFC1036
      format given that all the examples look like that.

      In the profile document I'd also include a bunch of the "non-standard"
      formats that are likely to be encountered in the wild to assist clients that
      want to do something meaningful with those addresses.

      Regards
      James
    • James Holderness
      ... The best I could find was Userland RSS 0.91: The suggested format for email addresses in RSS elements is bull@mancuso.com (Bull Mancuso). ... I would go
      Message 2 of 29 , Dec 8, 2006
      • 0 Attachment
        rcade wrote:
        > You're right that the definition needs to be reviewed. I've always
        > assumed that any e-mail address format is OK in RSS 2.0, but I need to
        > reread the definitions of that element in old versions.

        The best I could find was Userland RSS 0.91:

        "The suggested format for email addresses in RSS elements is
        bull@... (Bull Mancuso)."

        > 2. Only the forms "username@..." and "username@... (real
        > name)" are OK.

        I would go with these forms being RECOMMENDED, but not necessarily REQUIRED.

        > If people here favor 1 or 3, I'd like to hear your reasoning, since
        > the current spec only uses "username@... (real name)" in examples.

        Based on the examples, you could also assume that the only valid domains are
        boyer.net, herald.com and oxygen.net. I know that's a ridiculous argument to
        make, but my point is that the examples by themselves aren't enough for us
        to forbid other forms.

        I think if we're going to make something REQUIRED or a MUST that's going to
        break existing feeds we'd better have very solid evidence in the original
        spec text to back that up. At this stage all we have is a couple of examples
        and a suggestion - I'm not sure that's enough.

        Regards
        James
      • Geoffrey Sneddon
        ... Definitely not: this ll break compatibility with the current spec s examples and far too many implementation. ... I think this SHOULD be the form… ...
        Message 3 of 29 , Dec 13, 2006
        • 0 Attachment
          On 9 Dec 2006, at 01:06, rcade wrote:

          > --- In rss-public@yahoogroups.com, Geoffrey Sneddon <foolistbar@...>
          > wrote:
          >> Surely we should have some formal definition of what the importance
          >> of the final comment in <author> is, though?
          >
          > You're right that the definition needs to be reviewed. I've always
          > assumed that any e-mail address format is OK in RSS 2.0, but I need to
          > reread the definitions of that element in old versions.
          >
          > Before I do, there seem like three possibilities:
          >
          > 1. Only the form "username@..." is OK.

          Definitely not: this'll break compatibility with the current spec's
          examples and far too many implementation.

          >
          > 2. Only the forms "username@..." and "username@... (real
          > name)" are OK.

          I think this SHOULD be the form…

          >
          > 3. Any email address that can be used in email as a From: header is
          > OK.

          … and it MUST be this form (as the real name at the end is just a
          comment).

          >
          > If people here favor 1 or 3, I'd like to hear your reasoning, since
          > the current spec only uses "username@... (real name)" in
          > examples.

          3 gives the widest choice of possibilities, which are still all valid
          email address. Is there any real reason not to allow any valid email
          address?


          On 9 Dec 2006, at 02:00, James Holderness wrote:
          > I think if we're going to make something REQUIRED or a MUST that's
          > going to
          > break existing feeds we'd better have very solid evidence in the
          > original
          > spec text to back that up. At this stage all we have is a couple of
          > examples
          > and a suggestion - I'm not sure that's enough.

          <http://www.rssboard.org/rss-
          specification#ltauthorgtSubelementOfLtitemgt>: "It's the email
          address of the author of the item."

          That's pretty much the same as 3, as it doesn't limit the format of
          the email address.

          Also, should there just be an email data type, that applies to
          <managingEditor>, <webMaster>, as well as <author>?


          - Geoffrey Sneddon
        • James Holderness
          ... Option 3 (and now draft 1.16) limits the format to RFC 2822 - that *is* a limitation! That barely covers the format used in the examples (sure they re
          Message 4 of 29 , Dec 15, 2006
          • 0 Attachment
            Geoffrey Sneddon wrote:
            > <http://www.rssboard.org/rss-
            > specification#ltauthorgtSubelementOfLtitemgt>: "It's the email
            > address of the author of the item."
            >
            > That's pretty much the same as 3, as it doesn't limit the format of
            > the email address.

            Option 3 (and now draft 1.16) limits the format to RFC 2822 - that *is* a
            limitation! That barely covers the format used in the examples (sure they're
            valid RFC 2822 addresses, but they'll have lost part of their meaning under
            that interpretation). It also doesn't cover any of the following:

            mailto:name@host
            name@host?subject=something
            fullname (name@host)
            fullname, name@host

            I've encountered all of these at one time or another.

            The way I see it the original specs recommend (or at least suggest) one of
            two formats:

            name@host
            name@host (fullname)

            I could understand making *those* the only forms allowed (although I think
            that's going too far), and I can understand allowing *anything* (including
            all the examples I gave above). But to only allow RFC 2822 forms (when none
            of the RSS specs ever mentioned that) seems wrong to me.

            Regards
            James
          • rcade
            ... think ... (including ... (when none ... If we agree that the intent of defining an element s value as an email address is to enable that person to be
            Message 5 of 29 , Dec 16, 2006
            • 0 Attachment
              --- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
              wrote:
              > I could understand making *those* the only forms allowed (although I
              think
              > that's going too far), and I can understand allowing *anything*
              (including
              > all the examples I gave above). But to only allow RFC 2822 forms
              (when none
              > of the RSS specs ever mentioned that) seems wrong to me.

              If we agree that the intent of defining an element's value as an email
              address is to enable that person to be contacted via e-mail, anything
              that works in RFC 2822 must be allowed in RSS.

              Since mailto links also define valid email addresses, I think you're
              right that any valid mailto link must be allowed in RSS.

              Are there any other e-mail addressing schemes that must be considered?

              Incidentally, since around April 2004, the Feed Validator has said
              that the address must be valid RFC 2822:

              http://feedvalidator.org/docs/error/InvalidContact.html

              I tried to validate feeds with your test values using the validator,
              and here's how they did:

              mailto:name@host (valid)
              name@host?subject=something (invalid,
              mailto:name@...?subject=something also invalid)
              fullname (name@host) (invalid)
              fullname, name@host (invalid)
            • Geoffrey Sneddon
              ... I ve encountered fullname . Does that mean we should allow it? No. RFC 2822 is the de facto standard (as it s only actually a proposed standard) for
              Message 6 of 29 , Dec 16, 2006
              • 0 Attachment
                On 16 Dec 2006, at 03:33, James Holderness wrote:

                > Option 3 (and now draft 1.16) limits the format to RFC 2822 - that
                > *is* a
                > limitation! That barely covers the format used in the examples
                > (sure they're
                > valid RFC 2822 addresses, but they'll have lost part of their
                > meaning under
                > that interpretation). It also doesn't cover any of the following:
                >
                > mailto:name@host
                > name@host?subject=something
                > fullname (name@host)
                > fullname, name@host
                >
                > I've encountered all of these at one time or another.

                I've encountered "fullname". Does that mean we should allow it? No.

                RFC 2822 is the de facto standard (as it's only actually a proposed
                standard) for emails, and seeming we don't have any formal definition
                of what valid constitutes as a valid email address, I'm all for using
                it.

                My only issue is that we now refer to RFC 822 for dates, and RFC 2822
                for email addresses. I know we can't move to RFC 2822 for dates due
                to the military timezone issue, and we can't use RFC 822 for email
                addresses as there are email addresses that don't comply with it :(

                Lastly, how come the Feed Validator allows _some_ RFC 2368 mailto
                URLs, but not others? IMO we should either fully allow RFC 2368 or
                not at all.


                - Geoffrey Sneddon
              • James Holderness
                ... I wouldn t necessarily say that. You could also argue that the intent of mailto links is to enable the person to be contacted via email, but that doesn t
                Message 7 of 29 , Dec 16, 2006
                • 0 Attachment
                  rcade wrote:
                  > If we agree that the intent of defining an element's value as an email
                  > address is to enable that person to be contacted via e-mail, anything
                  > that works in RFC 2822 must be allowed in RSS.

                  I wouldn't necessarily say that. You could also argue that the intent of
                  mailto links is to enable the person to be contacted via email, but that
                  doesn't mean anything that works in RFC 2822 must also be allowed in a
                  mailto link.

                  Not that I'm saything RFC 2822 addresses shoudn't be allowed - I think they
                  should. I'm just arguing over the reasoning. I think the only reason they
                  should be allowed is because the original spec doesn't explicitly disallow
                  them.

                  > Are there any other e-mail addressing schemes that must be considered?

                  I think that's the wrong question. Why do you think we should be prohibiting
                  certain schemes? If the original spec just says that the element should be
                  an email address and the feed publisher fills in an email address (in
                  whatever format - say FidoNet), what gives us the right to say that it's
                  invalid?

                  I think we have only two choices: either permit any form of email address
                  (essentiall free form text); or only permit the form recommended in RSS 0.91
                  and used in the examples in RSS 2.0. Making up some restricted subset of
                  addresses that has never been defined in any RSS specification seems like
                  invention to me (useful for the profile perhaps, but not appropriate here).

                  Regards
                  James
                • James Holderness
                  ... The difference is that fullname by itself doesn t represent an email address. All the examples I listed do. ... Not emails in general - just Internet
                  Message 8 of 29 , Dec 16, 2006
                  • 0 Attachment
                    Geoffrey Sneddon wrote:
                    > I've encountered "fullname". Does that mean we should allow it? No.

                    The difference is that "fullname" by itself doesn't represent an email
                    address. All the examples I listed do.

                    > RFC 2822 is the de facto standard (as it's only actually a proposed
                    > standard) for emails

                    Not emails in general - just Internet emails. And it's not the standard used
                    in USENET messages or mailto links. It's not a terrible choice for an email
                    address format, but it's not the only choice.

                    Also, remember that RFC 2822 wasn't even an option at the time of RSS 0.91
                    and 0.92. At best you could make a case for RFC 822, but I don't think
                    there's enough evidence to suggest that was the intention of any of the
                    specs.

                    It's also worth noting that RFC 2822 doesn't allow characters outside
                    US-ASCII. Is "rzellweger@... (Renée Zellweger)" an acceptable
                    email address in RSS? Are publishers supposed to use MIME encoded words for
                    names containing foreign characters?

                    It really shouldn't have to be this complicated. The RSS 0.91 spec had a
                    nice simple recommendation: "The suggested format for email addresses in RSS
                    elements is bull@... (Bull Mancuso)". Why can't we just leave it at
                    that? No strict requirements - just a recommendation.

                    Regards
                    James
                  • rcade
                    ... address ... RSS 0.91 ... subset of ... like ... here). In another message, you state that fullname by itself doesn t represent an email address. On
                    Message 9 of 29 , Dec 18, 2006
                    • 0 Attachment
                      --- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
                      wrote:
                      > I think we have only two choices: either permit any form of email
                      address
                      > (essentiall free form text); or only permit the form recommended in
                      RSS 0.91
                      > and used in the examples in RSS 2.0. Making up some restricted
                      subset of
                      > addresses that has never been defined in any RSS specification seems
                      like
                      > invention to me (useful for the profile perhaps, but not appropriate
                      here).

                      In another message, you state that "'fullname' by itself doesn't
                      represent an email address." On what grounds do you say that, lacking
                      a definition of what constitutes an email address in RSS?

                      RSS 2.0 includes an email address data type but doesn't define it.

                      Permitting free form text in email addresses contradicts years of
                      implementers being told that usernames are not valid in author,
                      managingEditor and webMaster elements.

                      Permitting only "username@... (First Last)" goes beyond RSS 0.91
                      -- "The suggested format for email addresses in RSS elements is
                      bull@... (Bull Mancuso)" -- and would declare thousands of
                      existing RSS 2.0 feeds invalid.

                      RFC 2822+mailto has been the rule for years in the Feed Validator,
                      which the board endorsed earlier this year.

                      Let's accept that definition and give the email address type some
                      meaning rather than punting and leaving it undefined.
                    • James Holderness
                      ... All I meant was that we shouldn t explicitly allow a fullname in terms of what we write in the spec. I agree that there s no way to validate such a
                      Message 10 of 29 , Dec 18, 2006
                      • 0 Attachment
                        rcade wrote:
                        > In another message, you state that "'fullname' by itself doesn't
                        > represent an email address." On what grounds do you say that, lacking
                        > a definition of what constitutes an email address in RSS?

                        All I meant was that we shouldn't explicitly allow a fullname in terms of
                        what we write in the spec. I agree that there's no way to validate such a
                        restriction. We can't validate whether a title contains markup either, but
                        that doesn't stop the spec from declaring it invalid.

                        > Permitting free form text in email addresses contradicts years of
                        > implementers being told that usernames are not valid in author,
                        > managingEditor and webMaster elements.

                        Permitting free form text is not the same as saying that usernames are
                        valid. We just have no way to automatically invalidate them. However, by
                        providing a RECOMMENDED email format, we'll at least be able to flag them
                        with a warning.

                        > Permitting only "username@... (First Last)" goes beyond RSS 0.91
                        > -- "The suggested format for email addresses in RSS elements is
                        > bull@... (Bull Mancuso)" -- and would declare thousands of
                        > existing RSS 2.0 feeds invalid.

                        Which is why I would prefer we make that a recommendation.

                        > RFC 2822+mailto has been the rule for years in the Feed Validator,
                        > which the board endorsed earlier this year.

                        Are you saying that board's endorsement of the feed validator is also an
                        implicit endorsement of its current email validation rules? I doubt most
                        board members even know what those rules are. In fact I'm not convinced that
                        the rule is RFC2822+mailto. It may accept most RFC2822 and mailto addresses,
                        but I suspect that's just coincidence.

                        > Let's accept that definition and give the email address type some
                        > meaning rather than punting and leaving it undefined.

                        As much as I'd like to, I don't think we have a right to invent a definition
                        for it.

                        The three questions I suggest we ask ourselves are:
                        1. Will a strict definition be any more useful to feed publishers than the
                        suggestion in RSS 0.91?
                        2. Will a strict definition help feed aggregators parse existing feeds more
                        accurately?
                        3. Does this definition reflect the original spec text and/or the intention
                        of the original spec text?

                        If we can't answer yes to any of those questions (and I don't think we can),
                        then what are our reasons for doing this?

                        Regards
                        James
                      • Geoffrey Sneddon
                        ... Yes to number two. Big yes. This was the entire reason I brought it up - try parsing it into the name and email address when you don t know what format it
                        Message 11 of 29 , Dec 18, 2006
                        • 0 Attachment
                          On 18 Dec 2006, at 19:06, James Holderness wrote:

                          > The three questions I suggest we ask ourselves are:
                          > 1. Will a strict definition be any more useful to feed publishers
                          > than the
                          > suggestion in RSS 0.91?
                          > 2. Will a strict definition help feed aggregators parse existing
                          > feeds more
                          > accurately?
                          > 3. Does this definition reflect the original spec text and/or the
                          > intention
                          > of the original spec text?
                          >
                          > If we can't answer yes to any of those questions (and I don't think
                          > we can),
                          > then what are our reasons for doing this?


                          Yes to number two. Big yes. This was the entire reason I brought it
                          up - try parsing it into the name and email address when you don't
                          know what format it is in.

                          - Geoffrey Sneddon
                        • Geoffrey Sneddon
                          ... I stay by that - either allow it fully or not. - Geoffrey Sneddon
                          Message 12 of 29 , Dec 18, 2006
                          • 0 Attachment
                            On 18 Dec 2006, at 19:06, James Holderness wrote:

                            > In fact I'm not convinced that
                            > the rule is RFC2822+mailto. It may accept most RFC2822 and mailto
                            > addresses,
                            > but I suspect that's just coincidence.


                            On 16 Dec 2006, at 20:47, Geoffrey Sneddon wrote:
                            > Lastly, how come the Feed Validator allows _some_ RFC 2368 mailto
                            > URLs, but not others? IMO we should either fully allow RFC 2368 or
                            > not at all.

                            I stay by that - either allow it fully or not.

                            - Geoffrey Sneddon
                          • James Holderness
                            ... Let s say we changed the spec so it said email addresses MUST be RFC2822. Do you think feed publishers will suddenly start paying any attention to that
                            Message 13 of 29 , Dec 18, 2006
                            • 0 Attachment
                              Geoffrey Sneddon wrote:
                              > On 18 Dec 2006, at 19:06, James Holderness wrote:
                              >> 2. Will a strict definition help feed aggregators parse existing
                              >> feeds more
                              >> accurately?
                              >
                              > Yes to number two. Big yes. This was the entire reason I brought it
                              > up - try parsing it into the name and email address when you don't
                              > know what format it is in.

                              Let's say we changed the spec so it said email addresses MUST be RFC2822. Do
                              you think feed publishers will suddenly start paying any attention to that
                              requirement? Adding a strict definition to the spec when there wasn't one
                              before is not going to change anything. At best it gives you something to
                              point to as an excuse when your parser fails.

                              If you want your parser to work with existing feeds, you're still going to
                              need to be able to parse mailto URIs, solitary names, and whatever other
                              formats are out there, regardless of what we put in the spec. You'd be far
                              better off knowing what is really being used in the wild (something I think
                              we should adding to the profile). IMHO.

                              Regards
                              James
                            • rcade
                              ... I don t see how we can recommend a particular form of email address without also defining the email address data type that describes all permitted forms.
                              Message 14 of 29 , Dec 18, 2006
                              • 0 Attachment
                                --- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
                                wrote:
                                > Which is why I would prefer we make that a recommendation.

                                I don't see how we can recommend a particular form of email address
                                without also defining the email address data type that describes all
                                permitted forms.

                                > Are you saying that board's endorsement of the feed validator is
                                > also an implicit endorsement of its current email validation rules?

                                Not exactly. But we should be more like the developers of the Feed
                                Validator, who deal with gray areas like this one by making their best
                                guess at an interpretation and running with it.

                                > As much as I'd like to, I don't think we have a right to invent a
                                > definition for it.

                                I think we're being too cautious in the false belief there's a path we
                                can take that doesn't invite controversy.

                                We should make our best effort to interpret the spec and go forward
                                with our interpretation. RSS 2.0 includes an email address data type.
                                The lack of a spec definition for that type is the kind of issue the
                                board was created to deal with in 2003.
                              • Sam Ruby
                                ... I object to this characterization, at least as it applies to spec writing. Yes, we have had to make guesses. But when corrections have been pointed out
                                Message 15 of 29 , Dec 20, 2006
                                • 0 Attachment
                                  rcade wrote:
                                  > --- In rss-public@yahoogroups.com, "James Holderness" <j4_james@...>
                                  > wrote:
                                  >
                                  >> Are you saying that board's endorsement of the feed validator is
                                  >> also an implicit endorsement of its current email validation rules?
                                  >
                                  > Not exactly. But we should be more like the developers of the Feed
                                  > Validator, who deal with gray areas like this one by making their best
                                  > guess at an interpretation and running with it.

                                  I object to this characterization, at least as it applies to spec writing.

                                  Yes, we have had to make guesses. But when corrections have been
                                  pointed out (particularly, corrections with test cases), the Feed
                                  Validator has always responded.

                                  So, if the Feed Validator doesn't accept all forms of e-mail addresses,
                                  by all means, open bug reports. If some of the rarer forms are less
                                  widely supported, then perhaps a warning is in order.

                                  If this spec were a simply a profile, then subsetting is quite
                                  appropriate. But as it stands, version 2.0.8 both extends the RSS
                                  specification in at least one subtle way, and subsets it in at least one
                                  other subtle way; I don't see how that is good for anybody.

                                  - Sam Ruby
                                • Rogers Cadenhead
                                  ... Do you mean 2.0.9 (the draft spec)? Version 2.0.8 is the current spec.
                                  Message 16 of 29 , Dec 20, 2006
                                  • 0 Attachment
                                    On 12/20/06, Sam Ruby <rubys@...> wrote:
                                    > If this spec were a simply a profile, then subsetting is quite
                                    > appropriate. But as it stands, version 2.0.8 both extends the RSS
                                    > specification in at least one subtle way, and subsets it in at least one
                                    > other subtle way; I don't see how that is good for anybody.

                                    Do you mean 2.0.9 (the draft spec)? Version 2.0.8 is the current spec.
                                  • Rogers Cadenhead
                                    James -- do you envision an Email data type definition along these lines? Several elements MUST contain an email address, but there s no requirement to follow
                                    Message 17 of 29 , Dec 20, 2006
                                    • 0 Attachment
                                      James -- do you envision an Email data type definition along these lines?

                                      "Several elements MUST contain an email address, but there's no
                                      requirement to follow a specific format for such addresses. Publishers
                                      could format e-mail addresses according to the RFC 2822 Address
                                      Specification, the guidelines for mailto links, or some other scheme."

                                      "The RECOMMENDED format for email addresses in RSS elements is
                                      username@... (Real Name), as in the following example:"

                                      "<author>bull@... (Bull Mancuso)</author>"
                                    • Geoffrey Sneddon
                                      ... Time to ask a near-philosophical question: what is an email address? ... It gives a standard form of email address, allowing us to extract the name (and
                                      Message 18 of 29 , Dec 20, 2006
                                      • 0 Attachment
                                        On 19 Dec 2006, at 00:08, rcade wrote:

                                        > We should make our best effort to interpret the spec and go forward
                                        > with our interpretation. RSS 2.0 includes an email address data type.
                                        > The lack of a spec definition for that type is the kind of issue the
                                        > board was created to deal with in 2003.

                                        Time to ask a near-philosophical question: what is an email address?


                                        On 18 Dec 2006, at 23:32, James Holderness wrote:
                                        > Let's say we changed the spec so it said email addresses MUST be
                                        > RFC2822. Do
                                        > you think feed publishers will suddenly start paying any attention
                                        > to that
                                        > requirement? Adding a strict definition to the spec when there
                                        > wasn't one
                                        > before is not going to change anything. At best it gives you
                                        > something to
                                        > point to as an excuse when your parser fails.

                                        It gives a standard form of email address, allowing us to extract the
                                        name (and actual email address) in a standard way, counting anything
                                        that isn't as a name (thereby keeping us compatible with those feeds
                                        that choose to go against the already vague spec).


                                        - Geoffrey Sneddon
                                      • James Holderness
                                        ... I actually envisioned something simpler than that, but I like what you ve done. I think that text is useful for both aggregator authors and feed
                                        Message 19 of 29 , Dec 20, 2006
                                        • 0 Attachment
                                          Rogers Cadenhead wrote:
                                          > James -- do you envision an Email data type definition along these lines?

                                          I actually envisioned something simpler than that, but I like what you've
                                          done. I think that text is useful for both aggregator authors and feed
                                          publishers, and doesn't (IMO) stray from the intention of the original spec.

                                          Regards
                                          James
                                        • Rogers Cadenhead
                                          ... Cool. I can live with it, so that s two in support. Any other opinions on replacing the E-mail data type definition with the language I ve proposed?
                                          Message 20 of 29 , Dec 20, 2006
                                          • 0 Attachment
                                            On 12/20/06, James Holderness <j4_james@...> wrote:
                                            > I actually envisioned something simpler than that, but I like what you've
                                            > done. I think that text is useful for both aggregator authors and feed
                                            > publishers, and doesn't (IMO) stray from the intention of the original spec.

                                            Cool. I can live with it, so that's two in support. Any other opinions
                                            on replacing the E-mail data type definition with the language I've
                                            proposed?
                                          • James Holderness
                                            ... Most of the email formats I mentioned earlier in the thread aren t accepted by the feed validator. However, it s worth mentioning that those weren t
                                            Message 21 of 29 , Dec 20, 2006
                                            • 0 Attachment
                                              Sam Ruby wrote:
                                              > So, if the Feed Validator doesn't accept all forms of e-mail addresses,
                                              > by all means, open bug reports.

                                              Most of the email formats I mentioned earlier in the thread aren't accepted
                                              by the feed validator. However, it's worth mentioning that those weren't
                                              necessarily found in base RSS 2.0 email elements. They could just as easily
                                              have come from a dc:creator (or even atom:author/email) element since I
                                              process all email fields the same way.

                                              If anyone thinks it worthwhile, I could run some feed tests to see what
                                              formats people are using in just the author, managingEditor and webMaster
                                              fields. I need a decent database of feeds to work from though. I don't think
                                              the syndic8 list I used last time was very representative. I might try a
                                              combination of feeds from various top N lists.

                                              > If some of the rarer forms are less
                                              > widely supported, then perhaps a warning is in order.

                                              I ran a few tests on aggregators a while back. At the time, the vast
                                              majority either ignored authors altogether, or just plonked them down in the
                                              user interface as is. Some appeared to strip the angle address part from
                                              RFC822 emails, but I think that was probably them mistakenly treating it as
                                              markup (this was before the August security scares).

                                              Amongst those that actually tried to process addresses in some meaningful
                                              way, the formats that worked best were the RFC822 addresses (the angle-addr
                                              form as well as the simple addr-spec RFC1036 form). I wasn't testing any of
                                              the fancy RFC822 features though.

                                              Regards
                                              James
                                            • Mark Woodman
                                              ... Jittos to James H s comments on the new language... I like the balance it strikes. (+1) -- Mark Woodman http://inkblots.markwoodman.com
                                              Message 22 of 29 , Dec 20, 2006
                                              • 0 Attachment
                                                On 12/20/06, Rogers Cadenhead <cadenhead@...> wrote:
                                                > Cool. I can live with it, so that's two in support. Any other opinions
                                                > on replacing the E-mail data type definition with the language I've
                                                > proposed?

                                                Jittos to James H's comments on the new language... I like the balance
                                                it strikes. (+1)

                                                --
                                                Mark Woodman
                                                http://inkblots.markwoodman.com
                                              • Geoffrey Sneddon
                                                ... I d rather there be nominative references to RFC 2822 (Internet Message Format), RFC 2368 (The mailto URL scheme), and RFC 1036 (Standard for USENET
                                                Message 23 of 29 , Jan 4, 2007
                                                • 0 Attachment
                                                  On 20 Dec 2006, at 17:08, Rogers Cadenhead wrote:

                                                  > James -- do you envision an Email data type definition along these
                                                  > lines?
                                                  >
                                                  > "Several elements MUST contain an email address, but there's no
                                                  > requirement to follow a specific format for such addresses. Publishers
                                                  > could format e-mail addresses according to the RFC 2822 Address
                                                  > Specification, the guidelines for mailto links, or some other scheme."
                                                  >
                                                  > "The RECOMMENDED format for email addresses in RSS elements is
                                                  > username@... (Real Name), as in the following example:"
                                                  >
                                                  > "<author>bull@... (Bull Mancuso)</author>"

                                                  I'd rather there be nominative references to RFC 2822 (Internet
                                                  Message Format), RFC 2368 (The mailto URL scheme), and RFC 1036
                                                  (Standard for USENET Messages), with the latter being RECOMMENDED
                                                  (giving us a full definition of the form "bull@... (Bull
                                                  Mancuso)").

                                                  - Geoffrey Sneddon
                                                Your message has been successfully submitted and would be delivered to recipients shortly.