Re: [yam] Issue #4

[SM <[e-mail]>]

Hi Ned,
At 11:32 08-12-2009, Ned Freed wrote:
>Again, the point was to avoid the downref to draft the IESG was complaining
>about.

We could take a different approach for the downrefs as you 
mentioned.  We already know the documents the WG is taking on.

>That sort of says it all, doesn't it? To the extent this document was rejected
>on the basis of its content and not because of process pother, it was because
>of downrefs that weren't actually needed or relevant, but downrefs that are
>needed and which could actually be relevant and which should receive scrutiny
>are apparently just fine and dandy. And at least two actual errors (bogus ABNF
>reference, no IANA considerations) weren't noticed.

On the bright side, it got the WG to discuss about these two "errors" 
now rather than at the next stage.

>There is one MAY, and it is in fact an error. The document currently says:
>
>   Finally, although the
>   content body contains arbitrary lines of octet-aligned material, the
>   length of each line (number of octets between two CR-LF pairs), is
>   still subject to SMTP server line length restrictions (which may
>   allow as few as 1000 octets on a single line). This restriction means
>   that this extension MAY provide the necessary facilities for
>   transferring a MIME object with the 8BIT content-transfer-encoding,
>   it DOES NOT provide a means of transferring an object with the BINARY
>   content-transfer-encoding.
>
>This was written when RFC 1521 was still in effect, and it wasn't clear what
>restrictions were imposed by the 8bit encoding itself. This was clarified in
>RFC 2045, which made it clear that the 1000 character limit applies 
>to anything
>with an 8bit encoding. So the weasely MAY (which, incidentally, was 
>intended as
>emphasis and is not in the form of compliance language in any case) is wrong.

I was curious about the "DOES NOT" in that section.  Thanks for the 
explanation.

>This section needs to be redone to say;
>
>   Finally, although the
>   content body contains arbitrary lines of octet-aligned material, the
>   length of each line (number of octets between two CR-LF pairs), is
>   still subject to SMTP server line length restrictions (which may
>   allow as few as 1000 octets, inclusive of the CR-LF pair, on a single
>   line). This restriction means that this extension provides the necessary
>   facilities for transferring a MIME object with the 8BIT
>   content-transfer-encoding, it DOES NOT provide a means of transferring an
>   object with the BINARY content-transfer-encoding.
>
>And there goes the MAY and with it the need to reference RFC 2119.

That sounds fine.

>Modulo the 2119 thing, this looks right to me. However, at least one 
>additional
>change is needed - an IANA considerations section registering this extension.

The extension is registered but I don't see where it was done.  RFC 
4409 mentions 8BITMIME.  The Submit registration could go in there.

Regards,
-sm