--On Thursday, May 26, 2011 16:58 -0400 Derek Diget <[email protected]> wrote:
> > On May 26, 2011 at 09:56 -0700, S Moonesamy wrote: > =>This message starts a Working Group Last Call for "Message > Submission for =>Mail" (draft-ietf-yam-rfc4409bis-00). The > I-D can be accessed at > =>http://tools.ietf.org/html/draft-ietf-yam-rfc4409bis-00 > > Raising hand timidly..... > > > 1) Is it possible to insert a blank line between data rows in > Table 1? I find it hard to read with each column having > something wrapped at some point. For example... > > | PIPELINING | Pipelining | SHOULD | >... > Maybe since the "Name" column has just one entry that wraps > (ENHANCEDSTATUSCODES), it could be made one character narrower > so that the "Submission" column header wouldn't wrap? (I > think that you could even make it (Name) a total of 3 > characters narrower which would also allow the "Reference" > column to grow by two and not wrap a cell.) Derek, Writing as co-author and, for this iteration, lead pen-holder, I've got a longstanding bias that says, approximately, that the RFC Editor staff is extremely competent, does their jobs well when we let them, and does final reformatting of documents anyway. For some reason, I seem to feel more strongly about that over time. One of the implications of that principle is that I have not, for example, tried to fuss with column widths to improve readability, much less spent time on vertical formatting (blank lines or ruled lines between rows). That level of fussing (e.g., making one column a character or three narrower or trying to insert blank lines when there doesn't seem to be a directive for that and the DTD doesn't permit <vspace> elements within a <texttable> is not how I think I, or other IETF authors, should be spending our time... and is easier to do in nroff anyway. I've assumed that the RFC Editor would just straighten these things out and intended to put a note into the XML asking specifically that they take a look at it. I've now inserted that note as a comment in the working copy. If you, or others, think that a more explicit note (in a comment that shows up in the ASCII text) is needed, I'm happy to convert the comment, but I can't imagine its making a difference in the long run. > 2) I am not sure if a mention to RFC 6186 - Use of SRV Records > for Locating Email Submission/Access Services and its section > 3.1 would be appropriate in this RFC? Say, by adding > something like the following to section 3.1: > > A site [can|SHOULD?] publish the SRV record that provides a > client the site's preferred submission port [RFC6186]. Speaking as editor, I don't have a strong preference and will put in whatever text the WG prefers. However, please note that 4409bis is a candidate for full Standard and that your text above, even with MAY, creates a normative reference or close to it. Perhaps more important, while I haven't been looking and might not have seen it, I haven't seen a lot of evidence of wide adoption of 6186. I'd be a lot more comfortable with the idea of incorporating that sort of text if someone felt like compiling and posting an implementation report on 6186 (not a bad idea in its own right). john _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
