Subject: [Tools-discuss] pushing tables hard in xml2rfc

From: =JeffH <[email-masked]>
Date: Fri, 21 Dec 2007 13:31:50 -0800

just fyi/fwiw, I pushed <texttable>'s kinda hard in this paper..

   http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html

..and am not unhappy with the results in .html output (I haven't looked at the 
.txt output for a while for this paper).

Anyway, there's figures inside of texttables, and it works. Pretty cool.

=JeffH

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: =JeffH <[email-masked]>
Date: Fri, 21 Dec 2007 13:36:11 -0800

oh, yeah, and I made extensive use of <vspace> both within and without the tables.

=JeffH

---

From: =JeffH <[email-masked]>
Date: Fri, 21 Dec 2007 15:32:49 -0800

I got asked about what my xml source looks like. Here's relevant to the 
terminlogy section and figures-in-tables (use fixed pitch font)..

         <vspace blankLines="2"/>
         <section anchor="sctn-term" title="Terminology">

             <t>
                 <list style="hanging" hangIndent="20">

                     <t hangText="deployer">
                         <vspace blankLines="1"/>

                         In this document, the
                         term <spanx style="emph">deployer</spanx>
                         refers to one who installs (and configures)
                         one or more <spanx
                         style="emph">implementations</spanx>, of one
                         or more of the protocols or profiles discussed
                         herein, onto systems for use by some group of
                         <spanx style="emph">users</spanx>. Also, the
                         deployer role is considered distinct from the
                         <spanx style="emph">implementor</spanx> role.
                     </t>
                 <vspace blankLines="2"/>

             <t hangText="deployment">
                 <vspace blankLines="1"/>

                 A <spanx style="emph">deployment</spanx> is the
                 operating installation of <spanx
                 style="emph">implementations</spanx>, of one or more
                 of the protocols or profiles discussed
                 herein. Deployments are created by <spanx
                 style="emph">deployers</spanx>.
             </t>
             <vspace blankLines="2"/>

             <t hangText="key-value">
                 <vspace blankLines="1"/>
                 A shorthand <spanx style="emph">OpenID</spanx>
                 term describing a
                 &quot;<spanx style="emph">key</spanx> and
                 <spanx style="emph">value</spanx>&quot;
                 pair, or, more generally, the overall
                 notion of conveying information as sets of key-value
                 pairs. This term is used in both senses in <xref
                 target="OpenID.openid-authentication-2_0"/>.

                 <vspace blankLines="1"/>

                 Note: often, this &quot;key-value&quot; notion
                 is also
                 referred to as &quot;name-value&quot; or
                 &quot;name-value pairs&quot;.  Also, in the LDAP/X.500
                 world(s), similar constructs are referred to as
                 &quot;attribute value assertions&quot; (AVAs).
             </t>
             <vspace blankLines="2"/>

                 <vspace blankLines="2"/>
                 <section  title="Web Browser SSO with Association">
                 <t>
                     <xref target="tbl-openid-saml-sso-cmp-w-assoc"/>: <xref
                     target="tbl-openid-saml-sso-cmp-w-assoc" format="title"/>,
                     below,
                     illustrates web browser SSO where no
                     &quot;callbacks&quot; from the RP to the OP/IDP
                     are employed.

                     As can be seen from <xref
                     target="fig-openid-authn-assoc"/> and <xref
                     target="fig-saml-sso-no-artifact"/> therein, the flows for
                     both OpenID authentication and SAML web browser
                     SSO Profile are the same for this variation where
                     the RP has already been introduced to the
                     OP/IDP.

                     In the OpenID case, this means that RP
                     discovered (if necessary) and formed an
                     association with the OP/IDP prior to beginning the
                     flow in <xref target="fig-openid-authn-assoc"/>.
                     In SAML it means that the RP discovered the
                     IDP before the flow (via some unspecified means, though
                     possibly using the
                     OpenID initiation and discovery mechanism
                     <xref target="draft-hodges-saml-openid-profile-02"/>),

                     or had been configured with the information (this
                     is a subtle-but-key point in that SAML per se
                     is not wedded to particular initiation and
                     discovery mechanisms as discussed in <xref
                     target="sctn-idents-compare"/>: <xref
                     target="sctn-idents-compare" format="title"/>, above, and
                     <xref target="sctn-disco"/>: <xref
                     target="sctn-disco" format="title"/>, below).
                 </t>

                 <texttable anchor="tbl-openid-saml-sso-cmp-w-assoc" style="all"
                     title="Web Browser SSO with Association"

                 <ttcol width="50%" align="left">
                     OpenID
                 </ttcol>

                 <ttcol width="50%" align="left">
                     SAML
                 </ttcol>

            <!--    OpenID  -->
                 <c>
         <vspace blankLines="1"/>

                 <figure title="OpenID Authentication with an Established
                         Association"
                     anchor="fig-openid-authn-assoc">
                     <artwork>
                         <![CDATA[
  +----+                  +----+               +--------+
  | UA |                  | RP |               | OP/IDP |
  +-+--+                  +-+--+               +---+----+
    |                       |                      |
    | 1. Authentication Req |                      |
    | and assoc_handle!=null|                      |
  +<- - - - - - - - - - - - |                      |
  . | (HTTP redirect resp)  |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |  (HTTP GET or POST)   |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2. OP/IDP authenticates user                 |
    | (methods vary, realization is out of scope)  |
    |<============================================>|
    |(Step 2 transparent to user if openid.mode is |
    | checkid_immediate)    |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 3. Authentication Resp|                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . | (HTTP redirect resp)  |                      |
  . |                       |                      |
  +------------------------>|                      |
    |  (HTTP GET or POST)   |                      |
    |                       |                      |
    |                       |                      |
    | 4. User is signed-on  |                      |
    | or some form of       |                      |
    | error msg is displayed|                      |
    |<----------------------|                      |
    |                       |                      |
                        ]]>
                     </artwork>
                 </figure>
         <vspace blankLines="1"/>
                 </c>

                     <!--    SAML  -->
                     <c>
                         <vspace blankLines="1"/>

                     <figure title="SAML HTTP Redirect- or HTTP POST-based Web
                         Broswer SSO Profile"
                     anchor="fig-saml-sso-no-artifact">
                         <artwork>
                             <![CDATA[
  +----+                  +----+                +-----+
  | UA |                  | RP |                | IDP |
  +-+--+                  +-+--+                +--+--+
    |                       |                      |
    | 1. <AuthnRequest> msg |                      |
  +<- - - - - - - - - - - - |                      |
  . |   (redirect to IDP)   |                      |
  . |                       |                      |
  +-------------------------+--------------------->|
    |  (HTTP GET OR POST)   |                      |
    |                       |                      |
    |                       |                      |
    |                       |                      |
    | 2. Identity Provider authenticates user      |
    | (methods vary, realization is out of scope)  |
    |<============================================>|
    |(this step transparent to user if IsPassive=T)|
    |                       |                      |
    |                       |                      |
    | 3. <Response> message |                      |
  +<- - - - - - - - - - - - - - - - - - - - - - - -|
  . |   (redirect to SP)    |                      |
  . |                       |                      |
  +------------------------>|                      |
    |  (HTTP GET OR POST)   |                      |
    |                       |                      |
    |                       |                      |
    | 4. user is signed-on  |                      |
    | or some form of       |                      |
    | error msg is returned |                      |
    |<----------------------|                      |
    |                       |                      |
                             ]]>
                         </artwork>
                     </figure>

                     <vspace blankLines="1"/>
                 </c>
                 </texttable>
                     <vspace blankLines="2"/>

                 </section>

             <!--  =========== M E S S A G E   F O R M A T S =============  -->
             <vspace blankLines="2"/>
             <section anchor="sctn-msg-formats"
                 title="Message Formats and Protocol Bindings">

             <t>
                 <texttable anchor="tbl-msg-formats" style="all"
                     title="Message Formats and Protocol Bindings"

                 <ttcol width="10%" align="left">
                     Topic
                 </ttcol>

                 <ttcol width="40%" align="left">
                     OpenID
                 </ttcol>

                 <ttcol width="40%" align="left">
                     SAML
                 </ttcol>

                     <!--  topic  -->

                     <c>
                         Overall message formats:
                     </c>

                 <!--  OpenID  -->
                 <c>
                     <vspace blankLines="1"/>

                     OpenID Authentication
                     protocol messages are
                         comprised of
                     sets of
                     <spanx style="emph">key-value</spanx>
                         pairs, e.g this figure from
                         <xref target="OpenID.openid-authentication-2_0"/>
                         section 4...

                 <figure>
                     <artwork>
                         <![CDATA[
Key     | Value
--------+---------------------------
mode    | error
error   | This is an example message
                         ]]>
                     </artwork>
                 </figure>

                 ...which are encoded into HTTP messages, in varying
                 fashions dependent upon
                 whether the underlying HTTP message is an HTTP request or
                 response, and also whether (if it is a request)
                 the HTTP method being employed
                 is GET or POST. These variations are delineated in
                 <xref target="OpenID.openid-authentication-2_0"/>
                 by the notions of
                 &quot;Data Formats&quot; (section 4) and
                 &quot;Communication Types&quot; (section 5).

                 <vspace blankLines="1"/>
                 </c>

                 <!--  SAML  -->
                 <c>
                     <vspace blankLines="1"/>

                     Abstract SAML Messages are defined in
                     <xref target="OASIS.saml-core-2.0-os"/>, are
                     expressed in XML
                     <xref target="W3C.REC-xml"/>, and are structured
                     according to message definitions expressed in
                     XML Schema <xref target="W3C.REC-xmlschema-1"/>.
                     This is regardless of the particular underlying
                     protocol messages they are ultimately bound to.

                     <vspace blankLines="1"/>

                     SAML assertions and protocol messages are
                     comprised of many various &quot;parameters&quot;
                     &mdash; essentially corresponding to the OpenID
                     notion of <spanx style="emph">keys</spanx> &mdash;
                     and are configurable (i.e. various parameters are
                     optional), thus explicitly extensible.

                     <vspace blankLines="1"/>
                 </c>

---
end

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Dec 2007 11:48:02 +0100

...I'll have to say you're pushing them too hard, at least if you're 
concerned about the ability to produce TXT from it, or to run it trhough 
a different implementation :-).

---

From: =JeffH <[email-masked]>
Date: Wed, 26 Dec 2007 22:12:51 -0800

Julian Reschke wrote:
> ...I'll have to say you're pushing them too hard,

no such thing given the code didn't core-dump and produces reasonable, useful 
output.

> at least if you're 
> concerned about the ability to produce TXT from it,

not for this paper.

> or to run it trhough 

i'm not aware of any other xml2rfc impl, are you?

=JeffH

---

From: Julian Reschke <[email-masked]>
Date: Thu, 27 Dec 2007 10:11:42 +0100

> i'm not aware of any other xml2rfc impl, are you?

There's one from Bill Fenner, and there's also 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html>.

BR, Julian