[Ietf-message-headers] Re: Jabber-ID header field

[Frank Ellermann <[e-mail]>]

Bruce Lilly wrote:

>> Do you have a tool for this ?

> None needed; the list of RFC 822/2822 specials is small and
> easily remembered

Admittedly I often lose track with specials / tspecials / uric
and other important subsets of VCHAR.

> I can immediately see (in "resallow") conflicts DQUOTE, "(",
> ")", ":", ";", "<", ">", "[", "]", and ",", and of course
> "@" in pathxmpp itself.

For "(" and ")" we're clear without CFWS, or rather I claimed
that a Jabber-ID can't work as is with CFWS in
<http://article.gmane.org/gmane.ietf.rfc822/11777>

Some other specials might be also harmless.  But for DQUOTE and
backslash we're very far away from "like <id-left> @ <id-right>,
only different".

> the particular troublesome characters should be explicitly
> listed in the ABNF and normative text

Okay, a note that it's no <addr-spec>, even if it might look
like it, and also no <id-left> "@" <id-right>

> But RFC 2369 references RFC 1738 whereas RFC 4622 references
> RFC 3986, and the lists of "reserved" / "unreserved"
> characters are markedly different between 1738 and 3986.

Yes, RFC 2369 is too old, and the JID is no complete xmpp-URL.

> the 1738 characters are going to continue to be used [for
> backward compatibility], no matter what RFC 3986 says.

I doubt that, with RFC 1738 you'd exclude IPv6 literals.

> The combination of the necessity of encoding/decoding and
> the separation of client functionality means that naive
> copy-and-paste (between MUA and chat applications) is
> unlikely to work well.

That's why there is no tricky encoding in the JID, I'd expect
naive copy and paste to work.  UAs can support X-FACE or FACE,
they will also manage to support a JID.  The minimal support
"leave it alone" is good enough.

> There is no reason for a newly defined field to incorporate
> any obs- construct

It gets that automatically as soon as it says FWS, who knows
what old gateways or MDAs might do ?  In another discussion
you seriously argued that the order of header fields could be
rearranged by some utter dubious software.

Of course obs-FWS can't be generated under 2822 rules, but it
must be accepted if some pre-2822 entity introduces it.  For a
2822-generator the situation is clear, it can add trailing
white space, but not a bogus trailing folding.

Killing the complete trailing white space including any obs-FWS
might be an idea.  For the hidden obs-FWS in the leading FWS we
would need a "NNFWS" (no nonsense FWS) to eliminate its obs-FWS.

>> It's no Resent-Jabber-ID, the Resent-* are out.
> So where is the prohibition against a resender adding such a
> field?

What resenders must or may do is specified in 2822, "add new
random header fields as you see fit" isn't.

> where is the specification of who may insert/modify/interpret
> such a field (see RFC 4249 sect. 3.3.1)?

It's no trace header field, otherwise the draft would mention
it.  The number of _new_ trace header fields in published RFCs
in the last twenty years or so is AFAIK limited to one.

Skipping the Sender-part of your article, nobody suggested to
send mail to the address in a Sender header field.

> As for msg-id, the domain name or literal bounds still apply;
> the left-hand-side is limited in length by the overall line
> length limit of 998 octets due to the prohibition of folding
> within msg-id.

Right, that's also good enough for the JID.

> there's not much point in defining a field that simply will
> not work for some subset of otherwise valid (outside of the
> Internet Message Format) IDs.

I haven't met any JID with more than 100 characters so far,
but playing with it for less than a week that's just my first
personal impression.

> it might (or might not) be possible to adapt existing
> mechanisms for handling long URIs

We had that in USEFOR, yes.  In addition to ignoring leading and
trailing white space also ignore FWS within the field body.

> if a suitable media type needs to be defined anyway (for
> fallback), then one might as well use that as the primary
> mechanism

There probably are RFCs dealing with bounces of syntactically
invalid mails, for an error report folding the too long line
anywhere is an idea.

> In cases where the message initiator has delegated handling
> of errors, the initiator may be unaware of a failure

That's entirely the problem of the sender, the limit 1000 is
no new or suprising feature.

> I expect that the 1738/3986 conflict would arise (RFC
> 2426 references 1738)].

The im: URI scheme is based on <uric> in 2396.  If that's used
in some newer than RFC 2426 vcard-standard, I've no clue.

> A new application media subtype seems to be the fast track to
> getting the desired functionality.

>> Nobody would use it

> And your evidence to support that assertion is...? (N.B.
> vcards ARE in use)

Maybe, but not in any mails or news I care about.  If you want
a JID in attachments propose it, I'm not forced to use it, or
to be interested in it.

> vcards are not header fields, they are in fact conveyed as a
> MIME media type.

Yes, that's why they're not used, any multipart has excellent
chances to go to junk folders without questions asked.  Which
isn't nice from my POV, multipart/signed is decent in relation
to ugly plain text signatures.

As a header field I like the draft, as an attachment I wouldn't
care about it.

Frank



_______________________________________________
Ietf-message-headers mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers