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

Re: isn't clearly defined

Expand Messages
  • rcade
    ... 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
    Message 1 of 29 , Dec 8, 2006
    • 0 Attachment
      --- 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.

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

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

      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.
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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.