[Top] [All Lists]

Re: BATV pseudo-Last Call

2008-05-18 18:59:22

Nothing like asking for comments and then getting them.  Such a pain.

Meta-comment, mostly on the meta-syntax:

   The draft notes that the meta-syntax is expected to have broader utility.
The syntax has been changed before, and there is no religion against
changing it again.  However the challenge is to formulate and agree on the
requirements that mandate change.

   Some concerns impose absolute limits.  Say, for example, we ain't gonna
choose @ as a delimiter.

   Some concerns would be ill-advised, given popular usage.  I suspect "+" is
an example of that.

   Some concerns go too far, because they relate to non-standards that have
minimal deployment.  My current impression is that SRS falls in this category,
and yes, I'm citing it as an example knowing it might be a tad delicate.

So let's hear what constraints and requirements folks deem essential for this
meta-syntax, and why.  And given that the spec already has a proposal, I'll
suggest that anyone claiming it is not sufficient would help things a lot by
explaining why.

My model for the current spec uses

    <registered string> "="

as the template.  As Ned noted it could also be modeled as

   <string> "=" <string> "="

I had thought that the current template would be a sufficiently distinct pattern but can well imagine that it needs tweaking.

Again before we can change it, we need to know what the requirements and constraints are, for the generic usage. But we need to be careful not to get bogged down. Not that there is any reason we have to.

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
Additionally, in order for this to work BATV encapsulation must be uniquely
identifiable as such, must be removable, and must allow nesting. The scheme the
draft defines come fairly close to meeting these requirements: Look for two
equals signs with alphanumeric stuff between them, if found remove up through
the second equals sign, repeat. However, I do worry that the "signature' of two
equals signs is not sufficiently unique. At least one obvious conflict is with
SRS encoding.

What characteristics of the meta-syntax are you seeing as necessary, that the
current spec lacks?

As for nesting, please explain why?  What scenarios are you wanting to cover?

I think there is a strong argument against nesting, for BATV itself, but perhaps there are other scenarios that make sense with nesting. What might they be?

Another, bigger, concern is that the draft seems seriously deficient in
substantive discussion of the actual handling of BATV addresses. For one thing,
nowhere do I see an explication of the stripping process I just (casually and
somewhat incorrectly) described. Including this sort of information is
essential if you expect implementors to get this stuff right.

I keep switching about this. On the one hand, yeah, it's easy to imagine writing explicit encode/decode steps and plugging them in to some sort of larger, abstract service model. On the other hand, this is a pretty minimal mechanism, we have a number of implementation, and no one has felt the spec was deficient. Yes, these were early adopters, with attendant motivations and skills. On the other, this really *is* a simple mechanism.

I guess I'll ask:  What is the added handling discussion intended to enable?

Another one: A key step in the stripping procedure is that last "repeat",
because a single address may undergo multiple BATV operations. Maybe I missed

In the case of BATV, I'm pretty sure that that MUST NOT happen. I think it makes no sense to have layers of BATV encoding. And yes, that probably needs to be stated in the spec explicitly.

Another one: Registration requirements. This part of the draft is obviously
incomplete so this may not seem like fair game.

Yeah.  That's one's my bad.  Totally forgot to worry about adding the 

down I'm actually more concerned about something a little different: Without
specific guidance that pretty much says "if it passes muster syntactically as a
BATV address it needs to be treated as one for validation purposes", you are
going to have people attempting to validate the leading tag with some sort of
registered scheme list.


Another one: String lengths. One of the issues with BATV and similar schemes is
that they necessarily increase the length of local parts. You may not have run
into them, but there are some exceptionally long local parts out there. Some
discussion of how to handle them is definitely needed (even if all it ends up
saying is essentially "punt"), and if it is there I couldn't find it.

As John noted:  yup.

Another one: Quoting. Again, you may run into them, but quoted local parts are
used in some corners of the Internet. The draft needs to discuss how BATV
handles quoted local parts. (I suggest dequoting before and requoting after.)

Ack. Again, I totally missed that point and I agree with you and John on the handling.

Oh, and one final note. The document talks a bit about defining a public key
BATV scheme but doesn't actually define anything. I personally have no problem
with this and even applaud the rather brutal comment that "none of the multiple
existing public key services has yet gained wide adoption", but it strikes me
as exactly the sort of thing that tends to cause bad cases of panty-wadding
among the security mavens. I don't know how to finesse it, but some finesse is
probably in order here.

We decided to leave a generic comment in, both because some of us really like the idea of that enhancement and to show that we thought of it. But we can't do more than than and we didn't want to do less. So the current text is merely meant to acknowledge one direction of possible enhancement. I don't see that that causes any problems.


  Dave Crocker
  Brandenburg InternetWorking