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

Re: [ebook-community] Re: DRM as market control

Expand Messages
  • NetWorker
    Technical comments follow herein. Philosophical comments follow in a separate post, with a new subject id. ... Trying to ascertain intentions where they are
    Message 1 of 20 , Jan 1, 2004
    • 0 Attachment
      Technical comments follow herein. Philosophical comments follow in a separate
      post, with a new subject id.

      Ernest G. Allen wrote:


      > === Main Comments ===
      >
      > Networker didn't create the OEBPS DTD, so don't blame him for
      > the "other." prefix hack. He's working as much as possible
      > within the DTD and its accompanying documentation, but has to
      > overload, hijack, or ignore the title attribute, which is meant
      > to contain text that is meaningful to people, such as "Table of
      > Contents" or "List of Illustrations." I think that the sample
      > reference element above assumes that the value of the title
      > attribute will NOT be displayed, which is contrary to the
      > intention of the DTD. But then, the reference element in its
      > entirety is meant to contain usefully displayable information.


      Trying to ascertain intentions where they are not explicit is tricky at best.
      I would agree with you that the notion that the "title" attribute requires a
      human-readable value seems to be plausible. I also see, however, that the
      sample .opf file distributed with the Micro$oft Content SDK contains the
      following lines in the <guide> element:

      <reference type="other.ms-coverimage-standard" title="cover"
      href="coverbvt.jpg" />
      <reference type="other.ms-thumbimage-standard" title="thumb"
      href="thumbbvt.jpg" />
      <reference type="other.ms-titleimage-standard" title="title"
      href="titlebvt.jpg" />
      <reference type="other.ms-firstpage" title="firstpage" href="SDKintro.htm" />

      In this example the values of "cover", "thumb" and "title" are identical to
      the values of the "id" attribute of the corresponding files in the <manifest>.
      I don't believe that this correspondence is actually _required_ by their
      litgen.dll, but it is interesting to see how they have treated this attribute.

      It is thus clear that Micro$oft does not view the "title" attribute as
      requiring a human-readable value, at least not in all cases. And because
      Micro$oft was a major contributor to the OEBPS in the first place I think its
      behavior should carry some weight.

      My own personal bias as a programmer is that attribute/value pairs should
      never provide non-computer parsable values. A <reference> type of "toc" should
      be understood as a "Table of Contents" and a User Agent should be be free to
      display this as it chooses, perhaps as merely a link to a untitled table of
      contents page, or perhaps as a localized title, e.g. "Table des Matières". If
      it were the intention of the Publication Structure Working Group to limit the
      "title" value to purely titular values, I would have rathered that they make
      in possible for the <reference> element to contain PCDATA, so that the syntax
      would be:

      <reference type="toc" href="SDKTOC.htm">Table of Contents</reference>

      This way a programmer could know that the values of the attributes had
      immutable meanings, and the localization team could focus on translating just
      the PCDATA.

      But, as you point out, water under the bridge, and all that.

      > Please don't misunderstand. I like and appreciate most of the
      > OEBPS DTD, and it's a good DTD, but this part is off-base. It's
      > usually a bad idea to store information as special prefixes or
      > suffixes of an attribute's value. It forces a light-weight
      > parsing of the attribute value for every occurrence in order to
      > check for and, if necessary, split out the special prefix or
      > suffix. Much better to store a simple (yes, special) "see also"
      > or "see other" trigger value.


      From a purely programming point of view parsing out "title-page" vs. "other"
      vs. "other.ms-coverimage-standard" is trivial. Indeed, I suspect that the
      amount of code required to parse an additional, optional, attribute when the
      "type" value is "other" would be greater than simply detecting the "other."
      prefix and branching appropriately.


      <!-- snip -->


      I've been mulling this whole thing over in my mind, and perhaps the guide
      section really _isn't_ the best place for file relationships. It would have
      been nice if the OeBF could have given us a specific element for these
      linkages, along the lines of

      <relation type="application/x-dsa-signature" idref="content.html"
      relid="content.html.sig">

      but this raises the questions as to whether the OEBPS _should_ be modified,
      whether it _could_ be modified, and who would be responsible for the
      modifications, questions which are beyond the scope of this reply.

      It seems to me that information about the relationship of content files to
      digital signature files (or DRM support files) is really publication metadata.
      Indeed, because it is metadata about the publication structure itself, and not
      the publication, perhaps it ought to be called metametadata. In any case, the
      OEBPS provides for inclusion of arbitrary metadata in the <x-metadata>
      element. According to the specification:

      "The optional x-metadata element, if present, must contain one or more
      instances of a meta element, analogous to the XHTML 1.1 meta element, but
      applicable to the publication as a whole. The x-metadata element allows
      content providers to express arbitrary metadata beyond the data described by
      the Dublin Core specification."

      The DTD entry for the <x-metadata> element is:

      <!-- <x-metadata> must contain at least one <meta>. -->

      <!ELEMENT x-metadata (meta+)>
      <!ATTLIST x-metadata %CommonAttributes;>

      <!-- Note that 'content' and 'name' are required attributes
      for <meta>. -->

      <!ELEMENT meta EMPTY>
      <!ATTLIST meta
      %CommonAttributes;
      content CDATA #REQUIRED
      name NMTOKEN #REQUIRED
      scheme CDATA #IMPLIED>


      Thus, a sample <x-metadata> element for the "Adventures of Sherlock Holmes"
      could be:

      <x-metadata>
      <meta scheme="digitalsignature" name="toc" content="advensig" />
      <meta scheme="digitalsignature" name="01scan" content="01scansig" />
      <meta scheme="digitalsignature" name="02redh" content="02redhsig" />
      <meta scheme="digitalsignature" name="03iden" content="03idensig" />
      </x-metadata>

      In this case I would expect that the values for the "name" and "content"
      attributes would be identical to corresponding <item> "id" value from the
      manifest. This is important because we need to know the media-type of the
      related files (the "digitalsignature" scheme may accept files of media-types
      "x-dsa-signature", "x-md5-signature", "x-ripemd160-signature", etc.)

      I've never seen an <x-metadata> element ever actually used, although I notice
      that the Mobipocket Publisher throws an empty one into the .opf files it
      creates (in direct contradiction to the DTD that requires at least one <meta>
      element if the <x-metadata> element is included). I have also tried adding an
      <x-metadata> element block to an .opf file and creating a .lit file therefrom.
      Micro$oft's litgen.dll doesn't complain.

      What do you think of this as a compliant implementation?
    • NetWorker
      ... You don t need to reinvent this particular wheel -- we already have exactly what you re talking about: it s called Copyright law. Any unlawful reproduction
      Message 2 of 20 , Jan 1, 2004
      • 0 Attachment
        scythic wrote:

        > Actually, in thinking more about this, there are a couple of ways to
        > make this align with existing principles, given the same fundamental
        > theory - "The reader can be open source, with legal restrictions
        > preventing the illegal dissemination of the content"


        You don't need to reinvent this particular wheel -- we already have exactly
        what you're talking about: it's called Copyright law. Any unlawful
        reproduction of content can be remedied by the "simple" expedient of
        discovering the identity of the offending party and filing a lawsuit. Nothing
        more need be added to a file to gain legal protection.

        <!-- snip details -->

        What the neurotic are seeking is not DRM as much as TPM: not a method that
        will make copying illegal, but one that will make it very difficult.
        Apparently, what is desired is a system where the User Agent (the
        hardware/software combination that displays the content) _enforces_ the rights
        assertions in the document. (I say "apparently" because irrational desires are
        hard to predict.)

        So if you're going to have an open-source DRM system you have to have a
        mechanism whereby you can enforce the requirement that everyone utilizing the
        system also enforce the rights restrictions.

        I'm going to invent a DRM system off the top of my head here.

        Content will be HTML encoded, then compressed with the gzip algorithm
        (compressed files are harder to crack when encrypted, and encrypted files
        don't compress well). The compressed file will then be encrypted using the
        venerable DES algorithm using a "random" 56 bit key.

        When an individual wants to purchase an e-book, an MD5 hash is computed on his
        credit card number, the name as it appears on the credit card, the buyer's
        Social Security Number, and any other embarrassing information you can get him
        to cough up. The MD5 hash is reduced from 128 bits to 64 bits by xor'ing even
        and odd bits. The resulting 64 bit hash is used to encrypt the "random" key
        associated with the book being purchased. This personalized key is distributed
        with the encrypted book.

        Now the buyer's User Agent software collects the same data from the user that
        was used to compute the hash in the first place, condenses the hash and
        _decrypts_ the "random" key that was furnished with the content. It then uses
        the "random" key it derived to decrypt the entire e-book. The content is
        uncompressed and presented to the user using rich HTML formatting. The User
        Agent doesn't allow cutting and pasting of text, doesn't allow printing, and
        performs all it's functions in memory so there are no intermediate files
        hanging around. The buyer is not going to just hand the encrypted file over to
        his/her friend because in order to use it she/he is also going to have to
        provide the private and potentially incriminating data that is used to create
        the hash.

        BUT...

        If this whole process is public knowledge (and it is -- I just published it)
        what is going to prevent Jane Hacker from writing a simple command line
        program that will collect the information from Evil Buyer, compute the hash,
        decrypt the "random" key, decrypt the e-book, decompress the content, and
        write out an HTML file that can now be used by every browser on Earth, without
        restriction? The answer, of course, is nothing.

        And what is going to prevent Ms. Hacker from writing a new User Agent program
        that not only presents the content to the user but also allows pages to be
        printed, text to be copied, and the file to be saved in a number of
        unencumbered and unprotected formats? Right again, nothing.

        This is why an open source DRM project is never going to work. We could easily
        make the MD5 hash unrecoverable by any User Agent but one which is "blessed"
        (contractually encumbered) by using a little bit of secret data in the hash
        calculation that is hidden in the executable portion of the User Agent itself
        (a PID, for example). But as soon as any bit of the process is hidden the
        project can no longer be said to be open-source; it's only open to members of
        the club.

        Now if you could patent the process you might have a fighting chance, because
        then no one could legally use the process without your permission, even
        thought it was fully disclosed. But so long as publishers believe that their
        customers are out to flood the internet with unprotected copies of the the
        works they've purchased, they will not buy in to an open source DRM solution.

        <!-- remainder snipped -->
      • Ghost Cat
        Now that s novel idea. I bet that if the buyer knows that his CC number is encoded in the ebook he will not share it with the friends. As for protecting the
        Message 3 of 20 , Jan 1, 2004
        • 0 Attachment
          Now that's novel idea. I bet that if the buyer knows that his CC number is
          encoded in the ebook he will not share it with the friends. As for
          protecting the content on the book, pay me enough and I'll break any code
          except my own. Only God can break my code.

          o==]===========> www.ghost-cat.com <===========[==o

          Seek no evil and you shall find none.

          ----- Original Message -----
          From: "NetWorker" <networker@...>
          >
          > When an individual wants to purchase an e-book, an MD5 hash is computed on
          his
          > credit card number, the name as it appears on the credit card, the buyer's
          > Social Security Number, and any other embarrassing information you can get
          him
          > to cough up. The MD5 hash is reduced from 128 bits to 64 bits by xor'ing
          even
          > and odd bits. The resulting 64 bit hash is used to encrypt the "random"
          key
          > associated with the book being purchased. This personalized key is
          distributed
          > with the encrypted book.
          >
          >
        • S Bizness
          Hi Networker, I have an unrelated question for you, since you are a programmer. I want to initiate a website for my book, and I want to use paypal for the fund
          Message 4 of 20 , Jan 2, 2004
          • 0 Attachment
            Hi Networker,

            I have an unrelated question for you, since you are a programmer.

            I want to initiate a website for my book, and I want to use paypal for the fund collection part of it. I also want a page for an information submission prior to the payment page for basic info such as name, addy etc.

            I haven't yet had a chance to fully review what paypal's system offers, but I wanted to know if I need a separate program to handle the interaction of data back to me? I mean, I have designed sites, but only in class, and have yet to actually put on online, so I don't know if I need this. I'm thinking that for a basic submit button, it should come straight to my email, but I want an auto link that then takes the person to the payment page because this info would be gathered if they were purchasing. Can you give me some wise counsel on the subject? I'm a bit confused on the exact process, simply because my instructors never had us actually upload a site, and also stated that for data collection, I would need a program like Cold Fusion. Would you know anything about that? Thanks so much.

            Sandra

            NetWorker <networker@...> wrote:
            Technical comments follow herein. Philosophical comments follow in a separate
            post, with a new subject id.

            Ernest G. Allen wrote:


            > === Main Comments ===
            >
            > Networker didn't create the OEBPS DTD, so don't blame him for
            > the "other." prefix hack. He's working as much as possible
            > within the DTD and its accompanying documentation, but has to
            > overload, hijack, or ignore the title attribute, which is meant
            > to contain text that is meaningful to people, such as "Table of
            > Contents" or "List of Illustrations." I think that the sample
            > reference element above assumes that the value of the title
            > attribute will NOT be displayed, which is contrary to the
            > intention of the DTD. But then, the reference element in its
            > entirety is meant to contain usefully displayable information.


            Trying to ascertain intentions where they are not explicit is tricky at best.
            I would agree with you that the notion that the "title" attribute requires a
            human-readable value seems to be plausible. I also see, however, that the
            sample .opf file distributed with the Micro$oft Content SDK contains the
            following lines in the <guide> element:

            <reference type="other.ms-coverimage-standard" title="cover"
            href="coverbvt.jpg" />
            <reference type="other.ms-thumbimage-standard" title="thumb"
            href="thumbbvt.jpg" />
            <reference type="other.ms-titleimage-standard" title="title"
            href="titlebvt.jpg" />
            <reference type="other.ms-firstpage" title="firstpage" href="SDKintro.htm" />

            In this example the values of "cover", "thumb" and "title" are identical to
            the values of the "id" attribute of the corresponding files in the <manifest>.
            I don't believe that this correspondence is actually _required_ by their
            litgen.dll, but it is interesting to see how they have treated this attribute.

            It is thus clear that Micro$oft does not view the "title" attribute as
            requiring a human-readable value, at least not in all cases. And because
            Micro$oft was a major contributor to the OEBPS in the first place I think its
            behavior should carry some weight.

            My own personal bias as a programmer is that attribute/value pairs should
            never provide non-computer parsable values. A <reference> type of "toc" should
            be understood as a "Table of Contents" and a User Agent should be be free to
            display this as it chooses, perhaps as merely a link to a untitled table of
            contents page, or perhaps as a localized title, e.g. "Table des Mati�res". If
            it were the intention of the Publication Structure Working Group to limit the
            "title" value to purely titular values, I would have rathered that they make
            in possible for the <reference> element to contain PCDATA, so that the syntax
            would be:

            <reference type="toc" href="SDKTOC.htm">Table of Contents</reference>

            This way a programmer could know that the values of the attributes had
            immutable meanings, and the localization team could focus on translating just
            the PCDATA.

            But, as you point out, water under the bridge, and all that.

            > Please don't misunderstand. I like and appreciate most of the
            > OEBPS DTD, and it's a good DTD, but this part is off-base. It's
            > usually a bad idea to store information as special prefixes or
            > suffixes of an attribute's value. It forces a light-weight
            > parsing of the attribute value for every occurrence in order to
            > check for and, if necessary, split out the special prefix or
            > suffix. Much better to store a simple (yes, special) "see also"
            > or "see other" trigger value.


            From a purely programming point of view parsing out "title-page" vs. "other"
            vs. "other.ms-coverimage-standard" is trivial. Indeed, I suspect that the
            amount of code required to parse an additional, optional, attribute when the
            "type" value is "other" would be greater than simply detecting the "other."
            prefix and branching appropriately.


            <!-- snip -->


            I've been mulling this whole thing over in my mind, and perhaps the guide
            section really _isn't_ the best place for file relationships. It would have
            been nice if the OeBF could have given us a specific element for these
            linkages, along the lines of

            <relation type="application/x-dsa-signature" idref="content.html"
            relid="content.html.sig">

            but this raises the questions as to whether the OEBPS _should_ be modified,
            whether it _could_ be modified, and who would be responsible for the
            modifications, questions which are beyond the scope of this reply.

            It seems to me that information about the relationship of content files to
            digital signature files (or DRM support files) is really publication metadata.
            Indeed, because it is metadata about the publication structure itself, and not
            the publication, perhaps it ought to be called metametadata. In any case, the
            OEBPS provides for inclusion of arbitrary metadata in the <x-metadata>
            element. According to the specification:

            "The optional x-metadata element, if present, must contain one or more
            instances of a meta element, analogous to the XHTML 1.1 meta element, but
            applicable to the publication as a whole. The x-metadata element allows
            content providers to express arbitrary metadata beyond the data described by
            the Dublin Core specification."

            The DTD entry for the <x-metadata> element is:

            <!-- <x-metadata> must contain at least one <meta>. -->

            <!ELEMENT x-metadata (meta+)>
            <!ATTLIST x-metadata %CommonAttributes;>

            <!-- Note that 'content' and 'name' are required attributes
            for <meta>. -->

            <!ELEMENT meta EMPTY>
            <!ATTLIST meta
            %CommonAttributes;
            content CDATA #REQUIRED
            name NMTOKEN #REQUIRED
            scheme CDATA #IMPLIED>


            Thus, a sample <x-metadata> element for the "Adventures of Sherlock Holmes"
            could be:

            <x-metadata>
            <meta scheme="digitalsignature" name="toc" content="advensig" />
            <meta scheme="digitalsignature" name="01scan" content="01scansig" />
            <meta scheme="digitalsignature" name="02redh" content="02redhsig" />
            <meta scheme="digitalsignature" name="03iden" content="03idensig" />
            </x-metadata>

            In this case I would expect that the values for the "name" and "content"
            attributes would be identical to corresponding <item> "id" value from the
            manifest. This is important because we need to know the media-type of the
            related files (the "digitalsignature" scheme may accept files of media-types
            "x-dsa-signature", "x-md5-signature", "x-ripemd160-signature", etc.)

            I've never seen an <x-metadata> element ever actually used, although I notice
            that the Mobipocket Publisher throws an empty one into the .opf files it
            creates (in direct contradiction to the DTD that requires at least one <meta>
            element if the <x-metadata> element is included). I have also tried adding an
            <x-metadata> element block to an .opf file and creating a .lit file therefrom.
            Micro$oft's litgen.dll doesn't complain.

            What do you think of this as a compliant implementation?




            --------------------------------------------------------------------
            Post a message: ebook-community@yahoogroups.com
            Unsubscribe: ebook-community-unsubscribe@yahoogroups.com
            Switch to digest: ebook-community-digest@yahoogroups.com
            Switch to normal: ebook-community-normal@yahoogroups.com
            Put mail on hold: ebook-community-nomail@yahoogroups.com
            Administrator: ebook-community-owner@yahoogroups.com
            --------------------------------------------------------------------


            Yahoo! Groups SponsorADVERTISEMENT


            ---------------------------------
            Yahoo! Groups Links

            To visit your group on the web, go to:
            http://groups.yahoo.com/group/ebook-community/

            To unsubscribe from this group, send an email to:
            ebook-community-unsubscribe@yahoogroups.com

            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



            ---------------------------------
            Do you Yahoo!?
            New Yahoo! Photos - easier uploading and sharing

            [Non-text portions of this message have been removed]
          • Jeffrey Kraus-yao
            ... although I notice ... files it ... one ... adding an ... therefrom. ... The x-metadata element is used by Gemstar eBook Publisher to create files
            Message 5 of 20 , Jan 2, 2004
            • 0 Attachment
              --- In ebook-community@yahoogroups.com, NetWorker <networker@d...>
              wrote:
              > I've never seen an <x-metadata> element ever actually used,
              although I notice
              > that the Mobipocket Publisher throws an empty one into the .opf
              files it
              > creates (in direct contradiction to the DTD that requires at least
              one <meta>
              > element if the <x-metadata> element is included). I have also tried
              adding an
              > <x-metadata> element block to an .opf file and creating a .lit file
              therefrom.
              > Micro$oft's litgen.dll doesn't complain.

              The x-metadata element is used by Gemstar eBook Publisher to create
              files for the REB1200. An example is

              <x-metadata>
              <meta name="x-SBP-logging" content="on"/>
              <meta name="x-SBP-encrypt" content="off"/>
              <meta name="x-SBP-compress" content="on"/>
              <meta name="x-SBP-widow" content="0"/>
              <meta name="x-SBP-orphan" content="0"/>
              <meta name="x-SBP-zoomstate" content="both"/>
              <meta name="x-SBP-undlinks" content="on"/>
              <meta name="x-SBP-csssupport" content="2"/>
              <meta name="x-SBP-projectversion"
              content="1"/>
              <meta name="x-SBP-RLEtrigger" content="25"/>
              <meta name="x-SBP-devicemodel" content="gs"/>
              <meta name="x-Gemstar-Initial-Content"
              content="false"/>
              <meta name="x-Gemstar-Require-ISBN"
              content="false"/>
              <meta name="x-Gemstar-KeepAnchorLinks"
              content="false"/>
              <meta name="x-SBPNuvo-Build-ID"
              content="ebook:guid-31f7e7b5a59711d7947f000347705bcb"/>
              <meta name="x-SBPNuvo-Timestamp" content="103-
              05-23T16:53:56Z"/>
              <meta name="x-SBP-category" content="General
              Interest"/>
              </x-metadata>

              The key elements are name=x-SBP-category" which groups ebooks by
              category, name="x-SBP-encrypt" which should be false to load
              unencrypted ebooks on the reader, and name="x-SBP-zoomstate" which
              enables both font sizes for enlarging text.
            • Ernest G. Allen
              ... I skipped a step with be human-readable when I meant generate human-readable. In any case, reference elements are part of an _optional_ guide element
              Message 6 of 20 , Jan 2, 2004
              • 0 Attachment
                NetWorker <networker@...> wrote:
                >
                >Technical comments follow herein. Philosophical comments follow in a separate
                >post, with a new subject id.
                >
                >Ernest G. Allen wrote:
                >
                >
                >> === Main Comments ===
                >>
                >> Networker didn't create the OEBPS DTD, so don't blame him for
                >> the "other." prefix hack. He's working as much as possible
                >> within the DTD and its accompanying documentation, but has to
                >> overload, hijack, or ignore the title attribute, which is meant
                >> to contain text that is meaningful to people, such as "Table of
                >> Contents" or "List of Illustrations." I think that the sample
                >> reference element above assumes that the value of the title
                >> attribute will NOT be displayed, which is contrary to the
                >> intention of the DTD. But then, the reference element in its
                >> entirety is meant to contain usefully displayable information.
                >
                >
                >Trying to ascertain intentions where they are not explicit is tricky at best.
                >I would agree with you that the notion that the "title" attribute requires a
                >human-readable value seems to be plausible. I also see, however, that the
                >sample .opf file distributed with the Micro$oft Content SDK contains the
                >following lines in the <guide> element:
                >
                ><reference type="other.ms-coverimage-standard" title="cover"
                >href="coverbvt.jpg" />
                ><reference type="other.ms-thumbimage-standard" title="thumb"
                >href="thumbbvt.jpg" />
                ><reference type="other.ms-titleimage-standard" title="title"
                >href="titlebvt.jpg" />
                ><reference type="other.ms-firstpage" title="firstpage" href="SDKintro.htm" />
                >
                >In this example the values of "cover", "thumb" and "title" are identical to
                >the values of the "id" attribute of the corresponding files in the <manifest>.
                >I don't believe that this correspondence is actually _required_ by their
                >litgen.dll, but it is interesting to see how they have treated this attribute.
                >
                >It is thus clear that Micro$oft does not view the "title" attribute as
                >requiring a human-readable value, at least not in all cases. And because
                >Micro$oft was a major contributor to the OEBPS in the first place I think its
                >behavior should carry some weight.
                >


                I skipped a step with "be human-readable" when I meant "generate
                human-readable." In any case, reference elements are part of an
                _optional_ guide element and, from the docs, "Reading systems are
                not required to use the _guide_ element in any way."

                But still, simply as a point of DTD design, if an attribute's
                value is supposed to (usually) be limited to some small set of
                NMTOKEN values (16 in this case) it's handy to use an enumerated
                list instead of just NMTOKEN or CDATA. That way the validating
                parser can check it. But the "other." prefix approach is
                contrary to using an enumerated list. Hence, the suggestion of
                using a

                type='other' other-type='foobar21'

                approach.

                The "other." prefix approach isn't horrible, but I prefer using
                an enumerated list for the first attribute and storing "special"
                NMTOKEN or CDATA information in a second one.


                >My own personal bias as a programmer is that attribute/value pairs should
                >never provide non-computer parsable values. A <reference> type of "toc" should
                >be understood as a "Table of Contents" and a User Agent should be be free to
                >display this as it chooses, perhaps as merely a link to a untitled table of
                >contents page, or perhaps as a localized title, e.g. "Table des Matières". If
                >it were the intention of the Publication Structure Working Group to limit the
                >"title" value to purely titular values, I would have rathered that they make
                >in possible for the <reference> element to contain PCDATA, so that the syntax
                >would be:
                >
                ><reference type="toc" href="SDKTOC.htm">Table of Contents</reference>
                >


                Yes, if the element was supposed to contain the actual text to
                be displayed, this would be the way to go.


                >This way a programmer could know that the values of the attributes had
                >immutable meanings, and the localization team could focus on translating just
                >the PCDATA.
                >
                >But, as you point out, water under the bridge, and all that.
                >
                >> Please don't misunderstand. I like and appreciate most of the
                >> OEBPS DTD, and it's a good DTD, but this part is off-base. It's
                >> usually a bad idea to store information as special prefixes or
                >> suffixes of an attribute's value. It forces a light-weight
                >> parsing of the attribute value for every occurrence in order to
                >> check for and, if necessary, split out the special prefix or
                >> suffix. Much better to store a simple (yes, special) "see also"
                >> or "see other" trigger value.
                >
                >
                > From a purely programming point of view parsing out "title-page" vs. "other"
                >vs. "other.ms-coverimage-standard" is trivial. Indeed, I suspect that the
                >amount of code required to parse an additional, optional, attribute when the
                >"type" value is "other" would be greater than simply detecting the "other."
                >prefix and branching appropriately.
                >

                Except that no other code is required. The code already exists in
                any XML parser, and the

                type='other' other-type='foobar21'

                would already be parsed, and the "type" and "other-type" variables
                set, without any extra prefix-matching or string-stripping code on
                the part of the application programmer. Even with SAX (or similar)
                output, the "variables" in the SAX "language" would already be set.

                It isn't a huge difference, and either approach is workable, but
                using an optional other-type attribute along with what an XML
                parser will already do would avoid the use of an "other." prefix
                (a "magic value") and make the code more understandable. Any
                normal code written to handle the special values would refer to
                the other-type attribute (or other_type variable) instead of the
                type attribute (or variable), and it would be clear at a micro
                level when examining the code that it referred to the other-type
                attribute instead of the type attribute. By avoiding the semantic
                overloading of a type attribute or variable, one would reduce the
                likelihood of bugs during maintenance and enhancement.

                It boils down to the standard stuff about reducing coupling and
                raising cohesion among and within modules.


                >
                ><!-- snip -->
                >
                >
                >I've been mulling this whole thing over in my mind, and perhaps the guide
                >section really _isn't_ the best place for file relationships. It would have
                >been nice if the OeBF could have given us a specific element for these
                >linkages, along the lines of
                >
                ><relation type="application/x-dsa-signature" idref="content.html"
                >relid="content.html.sig">
                >
                >but this raises the questions as to whether the OEBPS _should_ be modified,
                >whether it _could_ be modified, and who would be responsible for the
                >modifications, questions which are beyond the scope of this reply.
                >
                >It seems to me that information about the relationship of content files to
                >digital signature files (or DRM support files) is really publication metadata.
                >Indeed, because it is metadata about the publication structure itself, and not
                >the publication, perhaps it ought to be called metametadata. In any case, the
                >OEBPS provides for inclusion of arbitrary metadata in the <x-metadata>
                >element. According to the specification:
                >
                >"The optional x-metadata element, if present, must contain one or more
                >instances of a meta element, analogous to the XHTML 1.1 meta element, but
                >applicable to the publication as a whole. The x-metadata element allows
                >content providers to express arbitrary metadata beyond the data described by
                >the Dublin Core specification."
                >
                >The DTD entry for the <x-metadata> element is:
                >
                ><!-- <x-metadata> must contain at least one <meta>. -->
                >
                ><!ELEMENT x-metadata (meta+)>
                ><!ATTLIST x-metadata %CommonAttributes;>
                >
                ><!-- Note that 'content' and 'name' are required attributes
                > for <meta>. -->
                >
                ><!ELEMENT meta EMPTY>
                ><!ATTLIST meta
                > %CommonAttributes;
                > content CDATA #REQUIRED
                > name NMTOKEN #REQUIRED
                > scheme CDATA #IMPLIED>
                >
                >
                >Thus, a sample <x-metadata> element for the "Adventures of Sherlock Holmes"
                >could be:
                >
                > <x-metadata>
                > <meta scheme="digitalsignature" name="toc" content="advensig" />
                > <meta scheme="digitalsignature" name="01scan" content="01scansig" />
                > <meta scheme="digitalsignature" name="02redh" content="02redhsig" />
                > <meta scheme="digitalsignature" name="03iden" content="03idensig" />
                > </x-metadata>
                >
                >In this case I would expect that the values for the "name" and "content"
                >attributes would be identical to corresponding <item> "id" value from the
                >manifest. This is important because we need to know the media-type of the
                >related files (the "digitalsignature" scheme may accept files of media-types
                >"x-dsa-signature", "x-md5-signature", "x-ripemd160-signature", etc.)
                >
                >I've never seen an <x-metadata> element ever actually used, although I notice
                >that the Mobipocket Publisher throws an empty one into the .opf files it
                >creates (in direct contradiction to the DTD that requires at least one <meta>
                >element if the <x-metadata> element is included). I have also tried adding an
                ><x-metadata> element block to an .opf file and creating a .lit file therefrom.
                >Micro$oft's litgen.dll doesn't complain.
                >
                >What do you think of this as a compliant implementation?
                >

                Much better and more sensible.

                I didn't remember the x-metadata element from my reading of the
                docs four years ago, but after re-reading that section I think
                that using meta elements within an x-metadata element would be
                the best match.

                Some people might complain about documentation stating that the
                meta element or elements within an x-metadata element are supposed
                to be "applicable to the publication as a whole" but I won't. It
                wouldn't bother me at all to use meta elements this way. One
                could read the "applicable to the publication as a whole" phrase
                as applying to the x-metadata element, but to me it seems to apply
                to the meta element(s). Tough. Using meta elements within an
                x-metadata element is a good match. Even the name, x-metadata,
                implies something similar to e-mail x-... headers and, quoting
                from the docs, it is for "arbitrary metadata beyond the data
                described by the Dublin Core language."

                It's a good match, makes good sense, and is compliant.


                /s/ Ernest G. Allen
              • Lee Fyock
                ... Yes, it s such a novel idea, we ve been doing it for over five years. I discussed our DRM as part of a panel on eBooks at the Nebula awards in 98 or 99,
                Message 7 of 20 , Jan 6, 2004
                • 0 Attachment
                  Ghost Cat said:

                  > Now that's novel idea. I bet that if the buyer knows that his CC
                  > number is
                  > encoded in the ebook he will not share it with the friends.


                  Yes, it's such a novel idea, we've been doing it for over five years.

                  I discussed our DRM as part of a panel on eBooks at the Nebula awards
                  in 98 or 99, and one science fiction author called it "a brilliant
                  piece of social engineering", and it is. It's worked amazingly well --
                  you can upgrade your hardware, install the book on any number of
                  devices you want, and never have to come back to ask us for more
                  activations or stuff like that.


                  Lee

                  --------------------------------
                  Lee Fyock
                  lee@...
                  Palm Digital Media
                  http://www.palmdigitalmedia.com/
                • Ghost Cat
                  But he will also never buy another ebook from you. ... From: Lee Fyock
                  Message 8 of 20 , Jan 6, 2004
                  • 0 Attachment
                    But he will also never buy another ebook from you.

                    ----- Original Message -----
                    From: "Lee Fyock" <lee@...>


                    > Ghost Cat said:
                    >
                    > > Now that's novel idea. I bet that if the buyer knows that his CC
                    > > number is
                    > > encoded in the ebook he will not share it with the friends.
                    >
                    >
                    > Yes, it's such a novel idea, we've been doing it for over five years.
                    >
                    > I discussed our DRM as part of a panel on eBooks at the Nebula awards
                    > in 98 or 99, and one science fiction author called it "a brilliant
                    > piece of social engineering", and it is. It's worked amazingly well --
                    > you can upgrade your hardware, install the book on any number of
                    > devices you want, and never have to come back to ask us for more
                    > activations or stuff like that.
                    >
                    >
                    > Lee
                    >
                    > --------------------------------
                    > Lee Fyock
                    > lee@...
                    > Palm Digital Media
                    > http://www.palmdigitalmedia.com/
                    >
                    >
                    > --------------------------------------------------------------------
                    > Post a message: ebook-community@yahoogroups.com
                    > Unsubscribe: ebook-community-unsubscribe@yahoogroups.com
                    > Switch to digest: ebook-community-digest@yahoogroups.com
                    > Switch to normal: ebook-community-normal@yahoogroups.com
                    > Put mail on hold: ebook-community-nomail@yahoogroups.com
                    > Administrator: ebook-community-owner@yahoogroups.com
                    > --------------------------------------------------------------------
                    >
                    > Yahoo! Groups Links
                    >
                    > To visit your group on the web, go to:
                    > http://groups.yahoo.com/group/ebook-community/
                    >
                    > To unsubscribe from this group, send an email to:
                    > ebook-community-unsubscribe@yahoogroups.com
                    >
                    > Your use of Yahoo! Groups is subject to:
                    > http://docs.yahoo.com/info/terms/
                    >
                    >
                    >
                    >
                  • Bill Janssen
                    Lee, how do you deal with the one-time use CC#? One can get a new # from AmEx for every purchase, and it s basically a random number after that use. There
                    Message 9 of 20 , Jan 6, 2004
                    • 0 Attachment
                      Lee, how do you deal with the one-time use CC#? One can get a new #
                      from AmEx for every purchase, and it's basically a random number after
                      that use. There would be no problem with giving it to others.

                      Bill

                      Lee Fyock wrote:
                      > > Now that's novel idea. I bet that if the buyer knows that his CC
                      > > number is
                      > > encoded in the ebook he will not share it with the friends.
                      >
                      >
                      > Yes, it's such a novel idea, we've been doing it for over five years.

                      Bill
                    • Lee Fyock
                      ... My guess is that it went this way: Microsoft Guy 1: Hey, we have to make an eBook reader that handles OEB format. Microsoft Guy 2: What s OEB? MSG1:
                      Message 10 of 20 , Jan 7, 2004
                      • 0 Attachment
                        Jon Noring wrote:

                        > This is not compiling as Bill defines. The question to ask is the one
                        > I asked above. If my conclusions are correct, why did Microsoft choose
                        > this route over the deep-compiled route?
                        >
                        > The answer to this question will probably yield interesting insights we
                        > have not yet discussed.
                        >
                        My guess is that it went this way:

                        Microsoft Guy 1: Hey, we have to make an eBook reader that handles OEB
                        format.

                        Microsoft Guy 2: What's OEB?

                        MSG1: It's HTML with a manifest.

                        MSG2: Multi-file stuff is messy, and you can't DRM it easily. Should
                        we compile it down to our own binary format and write a renderer?

                        MSG1: Hey, wait! Why don't we just feed it to the Internet Explorer
                        control? It already does HTML and CSS.

                        MSG2: Sweet! We can just zip up the OEB, DRM it, and be done in jiffy
                        time.

                        MSG1: I'm all over that.


                        That's my fictionalized guess. Pocket PC (and Windows) already had a
                        built-in browser quite capable of displaying HTML with CSS. Writing an
                        application to build on the IE engine, display the bookshelf, take
                        notes, etc. would be the way to go. I doubt there's anything magical
                        about MS's approach.

                        Bill,

                        I'm torn between the binary compiled stuff and the zipped-OEB for a new
                        format.

                        The software designer in me wants to use a text stream with embedded
                        style change codes (although it might be better to keep the style
                        changes somewhere else, for ease of text searching and other things) --
                        that would make rendering almost trivial. You'd end up with smaller
                        Reader applications, and smaller books.

                        On the other hand, you're probably going to lose stuff that you don't
                        know how to handle, and the way the OEB spec keeps growing, that might
                        be bad. Might be.

                        I don't know what happens in a Mobi document if you embed SVG or MathML
                        crap -- does it preserve it, or chuck it? How about a .lit file? What
                        if you include an image of a non-supported type? Does it get pulled
                        into the output file?

                        I suspect that the Mobi and MS "compilers" at least provide
                        normalization of the HTML so that it's well-formed going into the
                        output file. Mobi also puts information into <a href> tags so that the
                        links can be more easily followed.


                        All of this doesn't matter, really. The end-user format for commercial
                        DRM'd books is not going to be (legally) decompilable back to OEB.
                        That means that customers will most likely have to pick the Reader
                        software that will read the books they want on the platform they want.
                        Which isn't the best of all possible worlds, certainly.

                        Personally, I would rather concentrate on getting more content into
                        eBook form rather than flail about trying to push a UCF. I want all of
                        Mack Reynolds to be available. I want all of Heinlein, Niven, Clancy,
                        Grisham, Tolkien, Rowling. That's a far more important issue than a
                        UCF, IMHO.


                        Lee

                        --------------------------------
                        Lee Fyock
                        lee@...
                        Palm Digital Media
                        http://www.palmdigitalmedia.com/
                      • Roy
                        ... into ... all of ... Clancy, ... a ... I agree fully with the above but the only way to get to that point is to get EVERYONE using ebooks so the publishers
                        Message 11 of 20 , Jan 7, 2004
                        • 0 Attachment
                          --- In ebook-community@yahoogroups.com, Lee Fyock <lee@p...> wrote:
                          > Personally, I would rather concentrate on getting more content
                          into
                          > eBook form rather than flail about trying to push a UCF. I want
                          all of
                          > Mack Reynolds to be available. I want all of Heinlein, Niven,
                          Clancy,
                          > Grisham, Tolkien, Rowling. That's a far more important issue than
                          a
                          > UCF, IMHO.

                          I agree fully with the above but the only way to get to that point
                          is to get EVERYONE using ebooks so the publishers all think of
                          offering in ebook format FIRST. The only that will happen is if they
                          can offer ONE format that everyone can read on anything and one that
                          is Secure (or reasonably so) from theft.

                          Roy Lewis
                        • Jeffrey Kraus-yao
                          ... particular digital ... with a ... as the ... for the ... be scandal/01scan.html.sig . This ... approach would ... ... element ... enable ...
                          Message 12 of 20 , Jan 7, 2004
                          • 0 Attachment
                            --- In ebook-community@yahoogroups.com, NetWorker <networker@d...>
                            wrote:
                            > There remains, of course, the problem of how to associate a
                            particular digital
                            > signature file with a particular content file. I solved the problem
                            with a
                            > simple naming scheme: the digital signature file has the same name
                            as the
                            > signed file, but with an extension of ".sig". Thus, the file name
                            for the
                            > signature of "scandal/01scan.html" would
                            be "scandal/01scan.html.sig". This
                            > mechanism was quick and dirty, and not very good. A much better
                            approach would
                            > be to create an explicit association between the two files in the
                            <guide>
                            > section of the .opf file.
                            >
                            > The Open eBook Publication Structure 1.2 says that "The guide
                            element
                            > identifies fundamental structural components of the publication, to
                            enable
                            > Reading Systems to provide convenient access to them." I think
                            digital
                            > signatures can fall under that definition. It also says that
                            the "type"
                            > attribute of a <reference> element may be some as-yet undefined
                            value so long
                            > as it is prefixed with the string "other.". So, we could create an
                            association
                            > between a digital signature file and its associated content file
                            thusly:
                            >
                            > <reference type="other.digitalsignature" title="01scan"
                            > href="scandal/01scan.html.sig" />
                            >
                            > In this case, the value of the "title" attribute would be the "id"
                            of the
                            > manifested file, and the value of the "href" attribute would be the
                            file name
                            > of the digital signature file.

                            An alternate method of associating content with digital signatures is
                            to use an existing standard such as XML Signatures,
                            http://www.w3.org/Signature/

                            The .opf file would then include a reference to a single XML file
                            using the XML Signature schema that then links the files of the ebook
                            to their signatures.

                            <reference type="other.digitalsignature" title="digitalsignature"
                            href="signature.xml" />

                            The value of title is not really used as the specification of the
                            signed content, signature methods, and signatures are all contained
                            in file signature.xml.

                            Another issue is does file signature.xml need to be included in the
                            manifest and does it need a fallback?
                          • NetWorker
                            ... An excellent idea. ... But it would be nice if there were a method of finding a content file s associated digital signature file without having to open
                            Message 13 of 20 , Jan 7, 2004
                            • 0 Attachment
                              Jeffrey Kraus-yao wrote:


                              > An alternate method of associating content with digital signatures is
                              > to use an existing standard such as XML Signatures,
                              > http://www.w3.org/Signature/


                              An excellent idea.


                              > The .opf file would then include a reference to a single XML file
                              > using the XML Signature schema that then links the files of the ebook
                              > to their signatures.
                              >
                              > <reference type="other.digitalsignature" title="digitalsignature"
                              > href="signature.xml" />
                              >
                              > The value of title is not really used as the specification of the
                              > signed content, signature methods, and signatures are all contained
                              > in file signature.xml.


                              But it would be nice if there were a method of finding a content file's
                              associated digital signature file without having to open _all_ the XML
                              Signature files to find the one you want, thus the need for some kind of
                              linkage in the .opf saying "this signature goes with that content".


                              >
                              > Another issue is does file signature.xml need to be included in the
                              > manifest


                              Emphatically yes; the manifest is the authoritative list of all the files that
                              make up the publication.

                              > and does it need a fallback?

                              Technically yes, as that is what the specification requires. The rationale
                              behind this requirement seems to be to prevent manufacturers from creating
                              nominally OEBPS-compliant publications which are nontheless unusable on any
                              thing but a proprietary User Agent by simply including a proprietary format.
                              Thus, Adobe could create an OEB-compliant e-book which includes a PDF file so
                              long as that same content was also included as a media-type of
                              "text/x-oeb1-document". They could even dumb-down the HTML so it looked like
                              PDF was a superior format.

                              This rationale does not apply in cases like checksums, digital signatures or
                              attempts at digital rights mismanagement, but the requirement remains. In
                              these cases I think that the best fallback is an XHTML document that explains
                              how the file can be used to validate the content using other tools if your UA
                              doesn't support the principal media type.
                            • Bill Janssen
                              Lee, ... Yes, I appreciate what you say. There s also the Cathedral and the Bazaar argument espoused in Eric Raymond s now-famous article. I think his
                              Message 14 of 20 , Jan 7, 2004
                              • 0 Attachment
                                Lee,

                                > I'm torn between the binary compiled stuff and the zipped-OEB for a new
                                > format.

                                Yes, I appreciate what you say. There's also "the Cathedral and the
                                Bazaar" argument espoused in Eric Raymond's now-famous article. I
                                think his article is basically a rewrite of Richard Gabriel's classic
                                article on design, "Lisp: Good News, Bad News, How to Win Big"
                                (http://www.ai.mit.edu/docs/articles/good-news/good-news.html).

                                Gabriel contrasts two approaches to design, which he terms the "MIT"
                                and "New Jersey" (after Bell Labs, where UNIX was developed)
                                approaches. The MIT approach is to get everything right in the
                                design, then build the system. The New Jersey approach is to quickly
                                build something which is largely right, but which may have wrong parts
                                and missing parts. He describes these in a section titled "The Rise
                                of ``Worse is Better''", which is his one-second characterization of
                                the New Jersey approach. But he also states that he believes that
                                worse-is-better "has better survival characteristics than
                                the-right-thing", and that, for software, worse-is-better is
                                preferable.

                                This argument might be phrased, "time heals all wounds". That is, the
                                earlier you get *something* out there that seems to work, the more
                                time you will have to improve it. Hardware will get faster, batteries
                                will improve, the code will be re-worked, relatively small efficiency
                                problems simply aren't important in the long run. I think that's truer
                                in software, though, than it is in format design.

                                So, the worse-is-better approach to ebook design is to build something
                                which satisfies consumers and publishers. And do it today. I
                                actually think this is the approach taken by most current ebook
                                systems.

                                Bill
                              • Jim Drew
                                From: Bill Janssen ... The difference might be phrased as give them something now, and improve from there vs. give them the perfect
                                Message 15 of 20 , Jan 7, 2004
                                • 0 Attachment
                                  From: Bill Janssen <bill@...>

                                  >Gabriel contrasts two approaches to design, which he terms the "MIT"
                                  >and "New Jersey" (after Bell Labs, where UNIX was developed)
                                  >approaches. The MIT approach is to get everything right in the
                                  >design, then build the system. The New Jersey approach is to quickly
                                  >build something which is largely right, but which may have wrong parts
                                  >and missing parts. He describes these in a section titled "The Rise
                                  >of ``Worse is Better''", which is his one-second characterization of
                                  >the New Jersey approach. But he also states that he believes that
                                  >worse-is-better "has better survival characteristics than
                                  >the-right-thing", and that, for software, worse-is-better is
                                  >preferable.

                                  The difference might be phrased as "give them something now, and
                                  improve from there" vs. "give them the perfect thing, but only when
                                  it's perfect".

                                  Not only is "worse is better" preferable, but in a world where
                                  standards, user needs, and hardware are all moving targets, it is the
                                  only thing possible. Only when all the targets are nailed down ahead
                                  of time can you provide the other solution.
                                  --

                                  ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
                                  Jim Drew Seattle, WA ciaopubs@...
                                  http://home.earthlink.net/~rubberize/Weblog/index.html (Update: 12/17)
                                • Ernest G. Allen
                                  ... How about having the signature as part of the XML file in question? The W3C s XML-Signature Syntax and Processing allows enveloping signatures that apply
                                  Message 16 of 20 , Jan 9, 2004
                                  • 0 Attachment
                                    NetWorker <networker@...> wrote:
                                    >
                                    >Jeffrey Kraus-yao wrote:
                                    >
                                    >
                                    >> An alternate method of associating content with digital signatures is
                                    >> to use an existing standard such as XML Signatures,
                                    >> http://www.w3.org/Signature/
                                    >
                                    >
                                    >An excellent idea.
                                    >
                                    >
                                    >> The .opf file would then include a reference to a single XML file
                                    >> using the XML Signature schema that then links the files of the ebook
                                    >> to their signatures.
                                    >>
                                    >> <reference type="other.digitalsignature" title="digitalsignature"
                                    >> href="signature.xml" />
                                    >>
                                    >> The value of title is not really used as the specification of the
                                    >> signed content, signature methods, and signatures are all contained
                                    >> in file signature.xml.
                                    >
                                    >
                                    >But it would be nice if there were a method of finding a content file's
                                    >associated digital signature file without having to open _all_ the XML
                                    >Signature files to find the one you want, thus the need for some kind of
                                    >linkage in the .opf saying "this signature goes with that content".
                                    >


                                    How about having the signature as part of the XML file in
                                    question?

                                    The W3C's "XML-Signature Syntax and Processing" allows
                                    enveloping signatures that apply to an element and all of
                                    its children, enveloped signatures that apply to some
                                    element that contains the signature (uses XPath), and
                                    detached signatures that refer to an external file or a
                                    sibling element. The detached signature approach looks
                                    like the best match to me.

                                    All you need to do now is get the OeBF to adopt it! :)

                                    Oh, and get the publishers to adopt it. And the users of
                                    MS Reader and other User Agents to upgrade. But those are
                                    mere implementation details -- we've solved it!


                                    >
                                    >>
                                    >> Another issue is does file signature.xml need to be included in the
                                    >> manifest
                                    >
                                    >
                                    >Emphatically yes; the manifest is the authoritative list of all the files that
                                    >make up the publication.
                                    >
                                    >> and does it need a fallback?
                                    >
                                    >Technically yes, as that is what the specification requires. The rationale
                                    >behind this requirement seems to be to prevent manufacturers from creating
                                    >nominally OEBPS-compliant publications which are nontheless unusable on any
                                    >thing but a proprietary User Agent by simply including a proprietary format.
                                    >Thus, Adobe could create an OEB-compliant e-book which includes a PDF file so
                                    >long as that same content was also included as a media-type of
                                    >"text/x-oeb1-document". They could even dumb-down the HTML so it looked like
                                    >PDF was a superior format.
                                    >
                                    >This rationale does not apply in cases like checksums, digital signatures or
                                    >attempts at digital rights mismanagement, but the requirement remains. In
                                    >these cases I think that the best fallback is an XHTML document that explains
                                    >how the file can be used to validate the content using other tools if your UA
                                    >doesn't support the principal media type.
                                    >
                                    >

                                    Something like:

                                    Attention! You MUST upgrade your system to version 17.5c of MS
                                    Reader and provide the following information: a major credit card
                                    number, social security number, blood type including Rh factor,
                                    marital status, number of children (current known pregnancies count
                                    as 0.5 children regardless of due date), ethnic group, current
                                    annual income, educational degrees earned (with dates and school
                                    names), religious affiliation (if any), and membership status in
                                    any political party. Thank you for choosing Microsoft Reader.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.