We've published an -02 draft of LCI: <http://tools.ietf.org/html/draft-nottingham-linked-cache-inv-02> and intend to request publication as an Individual Submission Informational RFC soon (the link relations have just been submitted for review). Feedback still welcome (http list is best, I think). Cheers, -- Mark Nottingham http://www.mnot.net/
Hi all,
I’d like to discuss the introduction of a new variable name to be defined in WF/SWD beyond the {uri} variable defined in RFC6415, in relation to the use of templates in xrd/jrd descriptors. This variable name should capture the username part only for more flexibility.
This is based on implementation experience for social network federation (ie server to server discovery) where large provider islands need perform discovery on many users of remote islands to discover some endpoints.
Currently in various implementations a first host-meta call is issued to discover the lrdd template, followed by the actual lrdd query for a specific resource. The host-meta of that domain is typically cached to save a call for the next user discovery, but a lrdd query is sent each time for a new user (the response for the specific resource can be cached to limit queries).
On the other hand most of the endpoints discovered through lrdd queries for different resources on the same domain share the same pattern.
The host-meta can typically already contain a number of templates (right now lrdd is clearly the most popular), but lrdd typically contains actual uris. It would be useful (up to the service provider policy of course) to inform the “client” (in this case the querying server) that a specific endpoint uri actually follows a pattern that can be used for any user of that domain (whenever applicable of course).
This could be already achieved for example by exposing such endpoints already in the host-meta using templates.
However currently the only template variable name defined is “{uri}”, which gives very little flexibility to servers to create patterns. I’d like to get your feedback on the introduction in the WF draft of a new variable name related to the userpart only (eg. for “acct:joe <at> example.com”, the userpart is “joe”). This could be “{uri.userpart}” or “{username}” etc and would enable to express templates like:
<Link rel='http://schemas.google.com/g/2010#updates-from'
template='http://example.com/activities/{uri.userpart}'
type='application/atom+xml'/>
<Link rel='http://portablecontacts.net/spec/1.0#me'
template= 'http://example.com/api/people/{uri.userpart}'/>
The client would thus know that this template is generalizable for other users. In case the single href is provided, the client would not know (and may not assume) that the actual url is built according to a specific pattern.
Walter
|
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi
altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. Rispetta l'ambiente. Non stampare questa mail se non è necessario. |
_______________________________________________ apps-discuss mailing list apps-discuss <at> ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
On 31/05/2012 08:49, Dave Crocker wrote: > This review is at my own initiative. Dave, Thank you for the review. I've applied most of your editorial changes (and spelling fixes) as is. I've deleted them from my reply. I will reply to different parts of your review in separate messages. >> 2. Conventions Used in This Document >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in [RFC2119] when they >> appear in ALL CAPS. These words also appear in this document in >> lower case as plain English words, absent their normative meanings. > > "when they appear in ALL CAPS". sigh. In other words, this document > is modifying RFC2119. > > Does anyone seriously expect this new nuance of usage to be read and > remembered by average readers of this document? > FWIW, it took me about 3 minutes to make the relevant changes, below. > Case-sensitivity in semantics invites comprehension problems here. > Worse, there is absolutely no need or benefit in creating the problem > for this document. At a minimum, please do not try to modify IETF > document writing policy on the fly. I will let IESG weight in on this. I've implemented what I was told earlier. I don't have a strong opinion on this. >> 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server >> >> The following rules apply to SMTP transactions in a server that >> supports the MT-PRIORITY parameter: >> >> 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command >> based on the absence of the MT-PRIORITY parameter. > > > hmmm. For some operational environments, it will be essential to > have /all/ handling conform to the priority policy model in force for > the environment. In those cases, the absence of the parameter would > be a violation of the spec. Good point. Deleted. >> >> 5. If no priority has been determined by the above, the server may >> use its normal policies to set the message's priority. By >> default, each message has priority 0. > > ouch. This chooses a particular model for meaning of the numbers, and > without having defined the model beforehand. > > That is, I think the problem with this default is that it really is > assuming a particular policy for meaning of the values, namely that > average mail is mid-priority, assuming the numbers have linear semantics. Why is this a problem (commenting on the last sentence quoted above)? >> however, allow an untrusted source to lower its own message's >> priorities -- consider, for example, an email marketer that >> voluntarily sends its marketing messages at low priority. > > To beat the point a bit deader: this assumes a particular policy for > the meaning of the priority values. Worse, it also appears to > contradict the earlier default of 0, but perhaps I've misunderstood that. Yes, you misunderstood. The example talking about marketing messages is an example of a sender that explicitly requests priority below 0. >> 450 or 550 reply code. The corresponding enhanced status code MUST >> be X.7.TBD1 [RFC2034] if the determined priority level is below the >> lowest priority currently acceptable for the receiving SMTP server. >> Note that this condition might be temporary, in cases where the >> server is temporarily operating in a mode where only high priority >> messages are accepted for transfer and delivery. > > Given a range of 0-9, what qualifies as high priority and what > qualifies as low? > > Perhaps: > > Note that this condition might be temporary. In some environments, > operational policies might permit periods of operation that relay only > higher priority messages and defer lower priority ones. Such handling > choices need to be specified for that operational environment.. Ok. I used a slightly modified version of your suggested text. >> 4.4. Mailing lists and Aliases >> >> Several options exist to translate the address of an email recipient > > "options"? Perhaps you mean mechanisms or services? Yes. > And they really aren't translating an address but are doing a form of > message transmission (relaying, or the like). Suggested replacement? >> into one or more other addresses. Examples for this are aliases and >> mailing lists [RFC5321]. >> >> If a recipient address is to be translated and/or expanded when >> delivered to an alias or a mailing list, the translating or expanding >> entity (MTA, etc.) SHOULD retain the MT-PRIORITY parameter value for >> all expanded and/or translated addresses. > > This appears to expect the extension's semantics to survive delivery > and re-posting via a mailing list. Remember that a mailing list posts > a /new/ message. Offhand, this requirement seems to go considerably > beyond normal SMTP options and beyond most Internet Mail standards > services... This is the same as for the DSN SMTP extension. So no, this is not the first time. > > At the least, this needs considerably more extensive and careful > documentation that it is given here. > > >> 4.5. Gatewaying a message into a foreign environment >> >> The following rules govern the behavior of a conforming MTA, when >> gatewaying a message that was received via the SMTP protocol, into a >> foreign (non-SMTP) environment: >> >> 1. If the destination environment is unable to provide an equivalent >> of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as >> if it is relaying to a non-conformant SMTP server (Section 4.3). > > Given the variable semantics that apply here -- per the different > policy possibilities -- what does it mean to be an equivalent of the > MT-PRIORITY parameter, in specific technical terms? The point is that if I am trying to gateway to the Royal Pigeon Mail Service and it doesn't support anything similar to priorities at the protocol level, then this is treated as relaying to a non-conformant SMTP server. >> 2. If the destination environment is capable of providing an >> equivalent of the MT-PRIORITY parameter, the conforming MTA >> SHOULD behave as if it is relaying to a conformant SMTP server >> (Section 4.2), converting the MT-PRIORITY value to the equivalent >> in the destination environment. > > Is this really enough technical and operational detail to cover > gatewaying? Perhaps it is, but it feels to me as if it isn't. Then > again, I don't know what more/else to suggest. I don't know either. >> 4.6. Interaction with DSN SMTP Extension >> >> An MTA which also conforms to [RFC3461] SHOULD apply the same >> priority value to delivery reports (whether for successful delivery >> or failed delivery) it generates for a message. > > In many operational environments, control messages get higher priority > (or lower priority) than payload messages. What is a control message? Any suggested text? >> Note that rejections based on priority (see Section 4.1) or priority+ >> message size combination SHOULD only be done by an MSA (i.e. they >> SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the > > This presumes that an MSA knows the priority-related policies of > downstream MTAs and MDAs. I don't think so. Why do you say that? >> Mail User Agents (MUAs) which generated the message and is in a >> position to perform a corrective action, such as resubmission of the > > resubmission with lower priority is a big deal but seems to get a > rather casual reference here. > > >> message with lower priority, converting or truncating the message to >> make it smaller, etc. Such actions usually require user interaction. >> For this reason it is also important for MUAs to support enhanced >> >> > >> with a lower one. Additionally, the retry interval and/or default >> timeout before non-delivery report is generated can be lower (more >> aggressive) for messages of higher priority. > > oh? "can be"? Should have been "MAY be". > This sort of language looks like it is specifying something but it > isn't. And the reference to what "can be" carries no cautions or > directions meaningful to implementers. > > >> Note that as this SMTP extension requires some sort of trust >> relationship between a sender and a receiver and thus some for of > > for -> form (?) Yes. > This is treated as a side comment (by introducing it with "Note") but > I believe it is in fact a core predicate for the extension. > > >> authentication (whether using SMTP AUTH, TLS, IP address whitelist, >> etc.), so senders using this SMTP extension will not be subject to >> greylisting [GREYLISTING], unless they are unauthorized to use this >> SMTP extension, due to an explicit policy decision or a >> misconfiguration error. >> >> In order to make implementations of this extension easier, this SMTP >> extension only allows a single priority for all recipients of the >> same message. > > This is quite a good and clear simplification point. However note > that a model which permits selective support of priority values winds > up going counter to that goal of simplification. Well, simplification doesn't apply to everything in this extension. Some tradeoffs were made.... >> >> 5.2. Timely Delivery >> >> An important constraint (usually associated with higher priority >> levels) is that messages with high priority have some delivery time >> constraints. In some cases, higher priorities mean a shorter maximum >> time allowed for delivery. >> >> Unextended SMTP does not offer a service for timely delivery. The >> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in >> [RFC2852] is an example of an SMTP extension providing a service that >> can be used to implement such constraints. But note that use of the >> DELIVERBY extension alone does not guarantee any priority processing. > > It seems as if this section introduces an issue but does not actually > deal with it. Perhaps there should be some discussion of the possible > (or required?) interaction between the two extensions it discusses? There is no issue and no real interaction in this specific case. A client that wants to use both against a server that supports both should consider this issue. >> 8. Deployment Considerations >> >> If multiple DNS MX records are used to specify multiple servers for a >> domain in section 5 of [RFC5321], it is strongly advised that all of > > "strongly advised"? > > This seems the sort of thing that needs normative language yet it is > carefully avoided. That is, by saying 'strongly' the issue is moved > towards the asking why it is not stated normatively. I'd guess this > needs a SHOULD, possibly with discussion of permissible exceptions > (such as the open Internet...?) This section applies to system administrators. It is quite different from the rest of the document which contains mostly protocol level requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose. Suggestions for alternatives are welcomed. > However note that the 'strongly advised' presumes instantaneous > implementation on all hosts within the trust environment. > Since that isn't possible, it's not clear how the advice of this > section is practical. Nothing is instantaneous, so I am not very concerned
. Once some servers start supporting this extension a sysadmin can remove MXes for servers which don't support it. Upgrading all servers nearly simultaneously is another option. >> 10. Security Considerations >> >> Message Submission Agents MUST implement a policy that only allows >> authenticated users (or only certain groups of authenticated users) >> to specify message transfer priorities, and MAY restrict maximum >> priority values different groups of users can request, or MAY >> override the priority values specified by MUAs. > > Presumably the normative MSA language is meant "for those MSAs > supporting this extension"? Of course. I don't think this needs saying.
I've started a draft for using DANE with IMAP, POP3, and message submission, but I've got a bit stuck deciding how to fit in with RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). RFC 6125 has the following example: A mail user agent that is connecting via IMAPS to the email service at "example.net" (resolved as "mail.example.net") might have five reference identifiers: an SRV-ID of "_imaps.example.net" (see [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, as a fallback, CN-IDs of "example.net" and "mail.example.net". (A legacy email user agent would not support [EMAIL-SRV] and therefore would probably be explicitly configured to connect to "mail.example.net", whereas an SRV-aware user agent would derive "example.net" from an email address of the form "user <at> example.net" but might also accept "mail.example.net" as the DNS domain name portion of reference identifiers for the service.) I presume that the client would not actually use mail.example.net as a reference identifier unless DNSSEC is in use, otherwise that would not be secure and is therefore forbidden according to the rules a few paragraphs earlier in RFC 6125. There's also a question about how SNI fits in. RFC 6066 says that it only supports DNS host names, which I take to mean SRV targets not SRV names. RFC 6186 encourages the use of SNI but says nothing about which identity should be used. So I'm inclined to state that the server should have a certificate containing both the SRV name and target as DNS-IDs and offer that certificate if it is given either identity in an SNI. This is so that the server can support new-style clients (supporing DANE and SRV and using the SRV name as the identity) as well as old-style clients (using address records directly and the server host name for the TLS identity). I'll mention the SRV-ID for form's sake but as far as I can tell it's a fantasy that doesn't exist in the real world. Tony. -- -- f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ Dogger: Northwesterly 4 or 5, occasionally 6 in east. Moderate. Showers later. Good.
Hi Tony, --On June 1, 2012 5:47:50 PM +0100 Tony Finch <dot <at> dotat.at> wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). Shouldn't 6125 be updated to account for DANE, rather than doing this per protocol (or set of protocols)? That way anything that references 6125bis would inherit the correct DANE behavior. -- -- Cyrus Daboo
On Fri, Jun 01, 2012 at 05:47:50PM +0100, Tony Finch wrote: > I've started a draft for using DANE with IMAP, POP3, and message > submission, but I've got a bit stuck deciding how to fit in with > RFC 6125 (certificate verification) and RFC 6186 (SRV for MUAs). > > RFC 6125 has the following example: > > A mail user agent that is connecting via IMAPS to the email service > at "example.net" (resolved as "mail.example.net") might have five > reference identifiers: an SRV-ID of "_imaps.example.net" (see > [EMAIL-SRV]), DNS-IDs of "example.net" and "mail.example.net", and, > as a fallback, CN-IDs of "example.net" and "mail.example.net". (A > legacy email user agent would not support [EMAIL-SRV] and therefore > would probably be explicitly configured to connect to > "mail.example.net", whereas an SRV-aware user agent would derive > "example.net" from an email address of the form "user <at> example.net" > but might also accept "mail.example.net" as the DNS domain name > portion of reference identifiers for the service.) > > I presume that the client would not actually use mail.example.net as a > reference identifier unless DNSSEC is in use, otherwise that would not be > secure and is therefore forbidden according to the rules a few paragraphs > earlier in RFC 6125. That sounds correct to me. > There's also a question about how SNI fits in. RFC 6066 says that it only > supports DNS host names, which I take to mean SRV targets not SRV names. > RFC 6186 encourages the use of SNI but says nothing about which identity > should be used. SNI really needs to be extended to support other name types (especially SRVName and URI). > So I'm inclined to state that the server should have a certificate > containing both the SRV name and target as DNS-IDs and offer that > certificate if it is given either identity in an SNI. This is so that the > server can support new-style clients (supporing DANE and SRV and using the > SRV name as the identity) as well as old-style clients (using address > records directly and the server host name for the TLS identity). I'll > mention the SRV-ID for form's sake but as far as I can tell it's a fantasy > that doesn't exist in the real world. This doesn't achieve compartmentalization of security against other services sharing the domain name at the DNS-ID. It might however be necessary until software evolves. I agree that SRV-ID is for the time being a fantasy. Although if DANE usage types 2 and 3 take off, it might not be in the future. -- -- Shumon Huque University of Pennsylvania.
Hi, thanks for your review Murray, apologies for latency. Nice to see you didn't find any major issues. The most major obvious item in this review, concerning ABNF in section 6, was discussed on the list -- and then I neglected to submit a bug for the overall review feedback (sorry). that's now done: HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 ..and I'm working on -09 to incorporate your feedback and will reply to your msg on-list. =JeffH
A few comments are in order here.
> > particularly important during emergencies for first responders and
> > for environments such as military messaging, where messages have high
> > operational significance, and the consequences of extraneous delay
> > can be significant.
> >
> > In order for an SMTP receiver to be able to send higher priority
> send -> relay
Given the imprecise nature of this document overall, it's a stretch to believe
that being precise here is really necessary, but if it is, this fixes only part
of the problem. The message may have been received via SMTP, SUBMIT, or
something else. And the higher *or* *lower* priority may apply to whatever the
next step is: SMTP, LMTP, or something else.
If you want to be precise here, it needs to say something like:
In order for an MSA, MTA, or MDA to be able to relay, deliver, or
otherwise process higher priority messages first, ...
> > messages first, there needs to be a mechanism to communicate (during
> > both Message Submission [RFC6409] and Message Transfer [RFC5321]) the
> > priority of each message. This specification defines this mechanism
> > by specification of an SMTP [RFC5321] extension.
> >
> > Implementors of this document might also consider implementing
> > [PRIORITY-TUNNELING] which talks about tunneling of Message Transfer
> > Priority information through Message Transfer Agents (MTAs) that do
> > not support this extension, using a new message header field
> > [RFC5322].
> Consider replacing above paragraph with:
> In order to permit end-to-end use of this extension across email
> infrastructure that does not support it, a companion tunneling mechanism
> is defined in [PRIORITY-TUNNELING] through use of a new message header
> field [RFC5322].
This is better. These specifications are not just for implementors.
> > 2. Conventions Used in This Document
> >
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> > document are to be interpreted as described in [RFC2119] when they
> > appear in ALL CAPS. These words also appear in this document in
> > lower case as plain English words, absent their normative meanings.
> "when they appear in ALL CAPS". sigh. In other words, this document is
> modifying RFC2119.
On the contrary, all this is doing is being specific about the way RFC 2119 has
actually been used ever since it was created. I can easily produce a long list
of RFCs containing instances of these words in lower case where, even though it
wasn't stated, the intent *clearly* was for lower case versions of these words
to have their regular meanings.
And even if I were to accept the notion that this document specifies a novel
derivation of RFC 2119 (the notion that it *modifies* it being patently
absurd), that ship has also sailed. I can also easily point to RFCs that do
things like specify ALLS CAPS versions of these words have one meaning, Mixed
Case another, and lower case yet another.
> Does anyone seriously expect this new nuance of usage to be read and
> remembered by average readers of this document?
The better question is does anyone seriously expect anyone to assume, given
abundant evidence to the contrary, that the lower case versions of these words
will be taken to have RFC 2119 meaning?
> FWIW, it took me about 3 minutes to make the relevant changes, below.
> Case-sensitivity in semantics invites comprehension problems here.
> Worse, there is absolutely no need or benefit in creating the problem
> for this document. At a minimum, please do not try to modify IETF
> document writing policy on the fly.
You're the one who is arguing for a modification to the *actual* IETF document
writing policy here.
> > The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
> > notation including the core rules defined in Appendix B of RFC 5234
> > [RFC5234].
> >
> > In examples, "C:" and "S:" indicate lines sent by the client and
> > server respectively. Line breaks that do not start with a new "C:"
> > or "S:" exist for editorial reasons and are not a part of the
> > protocol.
> >
> > This document uses the term "priority" specifically in relation to
> > the internal treatment of a message by the server: messages with
> > higher priorities may be given expedited handling, and those with
> may -> can
> > lower priorities may be handled only as resources become available.
> may -> can
Again, given the loosey-goosey nature of this document overall, I don't think
precision is really required, but if it is, both of these changes are somewhat
objectionable.
Like it or not, "may" and "can" are *not* synonyms. "Can" is more assertive,
and carries with it a flavor that's closer to "should", whereas "may" is
expresses a possibilit with no preference.
We're talking about prioritization methodology here, specifically expedited
handling and deferred processing. There can be overhead associated with both of
these, and we should not be encourage the use of these techniques when it isn't
absolutely necessary.
And yes, I'm being very pedantic here. That's what you're going to get when
you elect to go down this path.
> >
> > 3. Definition of the Priority SMTP Extension
> >
> > The Priority SMTP service extension is defined as follows:
> >
> >
> >
> >
> > Melnikov & Carlberg Expires November 25, 2012 [Page 3]
> >
> > Internet-Draft Message Transfer Priority SMTP Extension May 2012
> >
> >
> > 1. The textual name of this extension is "Priority Message
> > Handling".
> >
> > 2. The EHLO keyword value associated with this extension is "MT-
> > PRIORITY".
> >
> > 3. The EHLO keyword has no parameters. Parameters are reserved for
> > possible future extensions and MUST be ignored by clients that
> > don't understand them.
> >
> > 4. No additional SMTP verbs are defined by this extension.
> >
> > 5. One optional parameter ("MT-PRIORITY") is added to the MAIL FROM
> > command. The value associated with this parameter is a decimal
> > integer number from -9 to 9 (inclusive) indicating the priority
> > of the email message. The syntax of the MT-PRIORITY parameter is
> > described by the <priority-value> ABNF non-terminal defined in
> > Section 6. Higher numbers mean higher priority.
> As a minor point, the form of -9 to 9 seems more complicated than
> useful. Is there a need for 19 values? I'd think that 0 to 9 would be
> sufficient.
Well, to be fair, the specification only requires support for six distinct
values:
A message priority is a decimal integer in the range from -9 to 9
(inclusive). SMTP servers compliant with this specification are not
required to support all 19 distinct priority levels (i.e. to treat
each priority value as a separate priority), but they MUST implement
at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
9. I.e. an implementation that only supports the 6 priority levels
will internally round up a syntactically valid level that isn't
supported to the next higher supported number. For example, such an
implementation will treat priority values below and including -4 as
priority -4, priority -3 as priority -2, and all priorities starting
from 5 are treated as priority 9. An SMTP server MAY support more
than 6 different priority levels. Decision about which levels to
support in addition to the 6 mentioned above is a local matter.
Now, I have no idea what it actually means to "support" six values, but I
assume it means that if you only make a processing distinction between five or
fewer values total, if you support only one "lower than normal" priority, or
you support fewer than three "higher than normal" priorities, you cannot
implement this specification. (Note I'm assuming 0 is "normal" here - see
below.)
Of course there's a trivial way around this: You simply state that, as a matter
of implementation policy, you only support X number and here's the mapping.
This would allow, say, a system that only does the old X.400 non-urgent,
normal, urgent thing to claim support.
> For that matter, why are many values needed? What is the basis for
> choosing to have a range of more than a few values?
IMO this is one of the rare cases where X.400 was spot-on correct.
> This appears to be the only place the provides semantics to the priority
> number. As such, it should be more thorough. The critical issue in
> assigning the number, I think, is trying to get independent originators
> to assign numbers according roughly the same criteria. For example, if
> I label "average" messages I send as as 0 and you label them as 1, then
> your messages get preferential treatment over mine, although that was
> not your intent. (Assuming you're not trying to game the service...)
> This issue goes to the core of the usage model for the feature: It
> really needs an environment tailored to its use, with all participants
> not only within the same trust system, but sharing the same priority
> assignment model/policy. It's probably good for this document to permit
> a range of assignment models, but should note that an operational
> requirement for use of the extension is that an assignment policy be
> defined for all participants.
> This document might, then, offer a candidate model, to be use by default
> and absent one specific to an environment.
Well, this goes to the problem I have with the entire document - I have no real
idea what the policy associated with these priorities is supposed to be. We
have a prioritization capability in our product and I can tell you what it
does, but s to whether or not it satisfies the intended target of this
specification, I realy couldn't say.
More generally, in a modern, high performance MTA that's capable of processing
large numbers of messages simultaneously, there's a significant problem
actually implementing mechanisms that are guaranteed to preferentially process
certain messages.
For example, suppose I have several dozen threads/processes/whatever connected
up to a given system, all busy transferring large messages. A higher priority
message comes in. If I shove this message on the thread that is the closest to
being done, there may still be a significant delay. OTOH, if I start a new
connection to handle it, what if I hit the limit on the number of connections
the remote MTA will accept from me?
Put another way, if you assume a fairly strict policy is needed, your point
about this only being applicable in an environment that's specifically tailored
for it is, if anything, an massive understatement. For this to provide a real
priority boost with high reliability it's actually necessary to closely
coordinate operational policies across all involved ADMDs. And not to put too
fine a point on it, the level of technical acumen needed to actually do this
sort of thing is something I've observed to be the exception and not the rule.
All that said, I think this actually argues for putting in some statements
as to what this document does *not* do. It calls for best effort to
provide preferential processing, nothing more. It does *not* provide
any sort of guarantees.
And if that's not the case, then this needs to be experimental.
> > 6. The maximum length of a MAIL FROM command line is increased by 15
> > octets by the possible addition of a space, the MT-PRIORITY
> > keyword and value.
> >
> > 7. The MT-PRIORITY extension is valid for the submission service
> > [RFC6409] and LMTP [RFC2033].
> >
> > 4. Handling of messages received via SMTP
> >
> > This section describes how a conforming SMTP server should handle any
> > messages received via SMTP.
> >
> > 4.1. Handling of the MT-PRIORITY parameter by the receiving SMTP server
> >
> > The following rules apply to SMTP transactions in a server that
> > supports the MT-PRIORITY parameter:
> >
> > 1. A conforming SMTP server MUST NOT refuse a MAIL FROM command
> > based on the absence of the MT-PRIORITY parameter.
> hmmm. For some operational environments, it will be essential to have
> /all/ handling conform to the priority policy model in force for the
> environment. In those cases, the absence of the parameter would be a
> violation of the spec.
Interesting point. I'm not sure what, if anything, to do about it.
> > 2. If any of the associated <esmtp-value>s (as defined in Section
> > 4.1.2 of [RFC5321]) are not syntactically valid, or if there is
> > more than one MT-PRIORITY parameter in a particular MAIL FROM
> > command, the server MUST return an error, for example "501 syntax
> > error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).
> >
> > 3. When inserting a Received header field as specified in Section
> > 4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
> > "PRIORITY" clause whose syntax is specified in Section 6.
> >
> >
> >
> > Melnikov & Carlberg Expires November 25, 2012 [Page 4]
> >
> > Internet-Draft Message Transfer Priority SMTP Extension May 2012
> >
> >
> > 4. If the sending SMTP client specified the MT-PRIORITY parameter to
> > the MAIL FROM command, then the value of this parameter is the
> > message priority.
> >
> > 5. If no priority has been determined by the above, the server may
> may -> can
> > use its normal policies to set the message's priority. By
> > default, each message has priority 0.
> ouch. This chooses a particular model for meaning of the numbers, and
> without having defined the model beforehand.
I for one was assuming 0 was the normal, default priority. But now that you
mention it, at least this needs to be made explicit.
> That is, I think the problem with this default is that it really is
> assuming a particular policy for meaning of the values, namely that
> average mail is mid-priority, assuming the numbers have linear semantics.
That sure was what I was assuming.
> > The SMTP server MUST NOT allow upgraded priorities from untrusted
> > (e.g. unauthenticated) or insufficiently trusted sources. (One
> > example of an "insufficiently trusted source" might be an SMTP sender
> > which authenticated using SMTP AUTH, but which is not explicitly
> > whitelisted to use the SMTP MT-PRIORITY service.) The server MAY,
> It is good that this issue is raised, but it really requires an earlier,
> separate and careful discussion of the need for this extension to be
> used within an administered trust environment. Given such an
> introductory section, the above text would be sufficient.
Agreed.
> In its absence, the reference to a whitelist is based on the very large
> assumption that participants in the extension are whitelisted. This is
> not document elsewhere.
True.
> > however, allow an untrusted source to lower its own message's
> > priorities -- consider, for example, an email marketer that
> > voluntarily sends its marketing messages at low priority.
> To beat the point a bit deader: this assumes a particular policy for
> the meaning of the priority values. Worse, it also appears to
> contradict the earlier default of 0, but perhaps I've misunderstood that.
I think that's a misunderstanding.
I generally agree with the remainder of your comments, although I think some
of them become less important as long as it's clear this doesn't provide
guaranteees, but they still should be addressed.
Ned
On 6/1/2012 12:28 PM, Alexey Melnikov wrote:
> On 31/05/2012 08:49, Dave Crocker wrote:
>> FWIW, it took me about 3 minutes to make the relevant changes, below.
>> Case-sensitivity in semantics invites comprehension problems here.
>> Worse, there is absolutely no need or benefit in creating the problem
>> for this document. At a minimum, please do not try to modify IETF
>> document writing policy on the fly.
>
> I will let IESG weight in on this. I've implemented what I was told
> earlier. I don't have a strong opinion on this.
So we don't follow IETF consensus documents anymore for process and
documentation conventions? The IESG establishes those details at its whim?
>>> 5. If no priority has been determined by the above, the server may
>>> use its normal policies to set the message's priority. By
>>> default, each message has priority 0.
>>
>> ouch. This chooses a particular model for meaning of the numbers, and
>> without having defined the model beforehand.
>>
>> That is, I think the problem with this default is that it really is
>> assuming a particular policy for meaning of the values, namely that
>> average mail is mid-priority, assuming the numbers have linear semantics.
>
> Why is this a problem (commenting on the last sentence quoted above)?
It's quite basic.
The document specifies a standard but does not specify it completely.
First, it periodically relies on undocumented policy assumptions.
Second, policies will vary from one environment to the next.
As I note in the review, proper operation of a QOS mechanism requires
all participants to operate according to the same policies. I gave the
example of two posters meaning 'average priority' but happening to
choose different values for that semantic. To get proper system
operation, you and I and the other guy all need to choose the same value
for the same semantic. That requires a definition of the semantic; in
this case that means rules for when to assign specific values.
In effect, the current document is a syntax mechanism for expressing
priority, but it doesn't really specify actual priority semantics for
making assignments, although it does hint at a particular set of
semantics/policies.
So the document is both incomplete and overly rigid, IMO. That's why I
suggested providing an explicit and complete policy section as a
default, but designed to allow alternative policy sections for other
environments.
>>> however, allow an untrusted source to lower its own message's
>>> priorities -- consider, for example, an email marketer that
>>> voluntarily sends its marketing messages at low priority.
>>
>> To beat the point a bit deader: this assumes a particular policy for
>> the meaning of the priority values. Worse, it also appears to
>> contradict the earlier default of 0, but perhaps I've misunderstood that.
>
> Yes, you misunderstood. The example talking about marketing messages is
> an example of a sender that explicitly requests priority below 0.
But there is no inherent meaning to "low priority", absent a policy
statement that defines the meaning of values. Low is relative to other
values, but which ones? In some environments -5 is low and in others 0
is low and I'll bet some others will treat 5 as low.
>>> 4.4. Mailing lists and Aliases
>>>
>>> Several options exist to translate the address of an email recipient
>>
>> "options"? Perhaps you mean mechanisms or services?
>
> Yes.
>
>> And they really aren't translating an address but are doing a form of
>> message transmission (relaying, or the like).
>
> Suggested replacement?
Several types of mechanisms exist to redirect or forward messages
to alternative or multiple addresses.[RFC5598] Examples for this are
aliases and mailing lists [RFC5321].
If a message is subject to such processing, the Mediator node
[rfc5598, Sec 2.1] SHOULD retain the MT-PRIORITY parameter value for all
expanded and/or translated addresses.
>>> 4.6. Interaction with DSN SMTP Extension
>>>
>>> An MTA which also conforms to [RFC3461] SHOULD apply the same
>>> priority value to delivery reports (whether for successful delivery
>>> or failed delivery) it generates for a message.
>>
>> In many operational environments, control messages get higher priority
>> (or lower priority) than payload messages.
>
> What is a control message?
Chatter about handling activity is distinct from traffic comprising user
payload (messages) even if a user is the recipient. The chatter
consists of control messages. A delivery report is a control message.
> Any suggested text?
Messages concerning email handling, such as delivery reports,
constitute control information rather than direct message payload. In
some environments, control traffic is subject to higher priority
handling and in others it receives the same priority as the message that
caused the report to be generated. Determining the priority to assign
is a matter for the policy statements applying to the environment in
which [RFC3461] is supported.
>>> Note that rejections based on priority (see Section 4.1) or priority+
>>> message size combination SHOULD only be done by an MSA (i.e. they
>>> SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the
>>
>> This presumes that an MSA knows the priority-related policies of
>> downstream MTAs and MDAs.
>
> I don't think so. Why do you say that?
A rejection means that the message is outside an acceptable range.
That's a policy for the environment and it does not make sense for an
MSA to have one set of policies and MTAs to have another.
>>> 5.2. Timely Delivery
>>>
>>> An important constraint (usually associated with higher priority
>>> levels) is that messages with high priority have some delivery time
>>> constraints. In some cases, higher priorities mean a shorter maximum
>>> time allowed for delivery.
>>>
>>> Unextended SMTP does not offer a service for timely delivery. The
>>> "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>>> [RFC2852] is an example of an SMTP extension providing a service that
>>> can be used to implement such constraints. But note that use of the
>>> DELIVERBY extension alone does not guarantee any priority processing.
>>
>> It seems as if this section introduces an issue but does not actually
>> deal with it. Perhaps there should be some discussion of the possible
>> (or required?) interaction between the two extensions it discusses?
>
> There is no issue and no real interaction in this specific case. A
> client that wants to use both against a server that supports both should
> consider this issue.
Specifications that say an implementer should consider something but
which gives no guidance about the consideration aren't doing much
useful, in my view.
As this set of text was proceeding, I thought it was going to provide
some useful guidance about possible uses of the combined options, since
it seemed like the combination could be, well, useful.
>>> 8. Deployment Considerations
>>>
>>> If multiple DNS MX records are used to specify multiple servers for a
>>> domain in section 5 of [RFC5321], it is strongly advised that all of
>>
>> "strongly advised"?
>>
>> This seems the sort of thing that needs normative language yet it is
>> carefully avoided. That is, by saying 'strongly' the issue is moved
>> towards the asking why it is not stated normatively. I'd guess this
>> needs a SHOULD, possibly with discussion of permissible exceptions
>> (such as the open Internet...?)
>
> This section applies to system administrators. It is quite different
> from the rest of the document which contains mostly protocol level
> requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose.
I think that is merely confusing. Normative direction to operators is
an entirely reasonable part of a specification. Since that's really
what you are doing, go ahead and use officially normative language.
> Suggestions for alternatives are welcomed.
Just convert to the normative terms that are appropriate.
>> However note that the 'strongly advised' presumes instantaneous
>> implementation on all hosts within the trust environment.
>> Since that isn't possible, it's not clear how the advice of this
>> section is practical.
>
> Nothing is instantaneous, so I am not very concerned .
So the document is strongly advising something that is impossible to
achieve, during a transition period. It's worth considering how to
handle that.
> Once some servers start supporting this extension a sysadmin can remove
> MXes for servers which don't support it. Upgrading all servers nearly
> simultaneously is another option.
Is it practical?
>>> 10. Security Considerations
>>>
>>> Message Submission Agents MUST implement a policy that only allows
>>> authenticated users (or only certain groups of authenticated users)
>>> to specify message transfer priorities, and MAY restrict maximum
>>> priority values different groups of users can request, or MAY
>>> override the priority values specified by MUAs.
>>
>> Presumably the normative MSA language is meant "for those MSAs
>> supporting this extension"?
>
> Of course. I don't think this needs saying.
And yet the document says exactly that sort of qualifier earlier: "An
MTA which also conforms to [RFC3461]..."
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Hi Ned, On 01/06/2012 17:18, Ned Freed wrote: > A few comments are in order here. > >> > particularly important during emergencies for first responders and >> > for environments such as military messaging, where messages have >> high >> > operational significance, and the consequences of extraneous delay >> > can be significant. >> > >> > In order for an SMTP receiver to be able to send higher priority > >> send -> relay > > Given the imprecise nature of this document overall, it's a stretch to > believe > that being precise here is really necessary, but if it is, this fixes > only part > of the problem. The message may have been received via SMTP, SUBMIT, or > something else. And the higher *or* *lower* priority may apply to > whatever the > next step is: SMTP, LMTP, or something else. > > If you want to be precise here, it needs to say something like: > > In order for an MSA, MTA, or MDA to be able to relay, deliver, or > otherwise process higher priority messages first, ... Yeah, I think this is less readable than what I have. I am sure readers understand the meaning of what is being said. > >> > messages first, there needs to be a mechanism to communicate >> (during >> > both Message Submission [RFC6409] and Message Transfer >> [RFC5321]) the >> > priority of each message. This specification defines this >> mechanism >> > by specification of an SMTP [RFC5321] extension. >> > >> > Implementors of this document might also consider implementing >> > [PRIORITY-TUNNELING] which talks about tunneling of Message >> Transfer >> > Priority information through Message Transfer Agents (MTAs) that do >> > not support this extension, using a new message header field >> > [RFC5322]. > >> Consider replacing above paragraph with: > >> In order to permit end-to-end use of this extension across email >> infrastructure that does not support it, a companion tunneling mechanism >> is defined in [PRIORITY-TUNNELING] through use of a new message header >> field [RFC5322]. > > This is better. These specifications are not just for implementors. Yes, already used in -15. >> > 2. Conventions Used in This Document >> > >> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in >> this >> > document are to be interpreted as described in [RFC2119] when they >> > appear in ALL CAPS. These words also appear in this document in >> > lower case as plain English words, absent their normative meanings. > >> "when they appear in ALL CAPS". sigh. In other words, this document is >> modifying RFC2119. > > On the contrary, all this is doing is being specific about the way RFC > 2119 has > actually been used ever since it was created. I can easily produce a > long list > of RFCs containing instances of these words in lower case where, even > though it > wasn't stated, the intent *clearly* was for lower case versions of > these words > to have their regular meanings. > > And even if I were to accept the notion that this document specifies a > novel > derivation of RFC 2119 (the notion that it *modifies* it being patently > absurd), that ship has also sailed. I can also easily point to RFCs > that do > things like specify ALLS CAPS versions of these words have one > meaning, Mixed > Case another, and lower case yet another. > >> Does anyone seriously expect this new nuance of usage to be read and >> remembered by average readers of this document? > > The better question is does anyone seriously expect anyone to assume, > given > abundant evidence to the contrary, that the lower case versions of > these words > will be taken to have RFC 2119 meaning? > >> FWIW, it took me about 3 minutes to make the relevant changes, below. >> Case-sensitivity in semantics invites comprehension problems here. >> Worse, there is absolutely no need or benefit in creating the problem >> for this document. At a minimum, please do not try to modify IETF >> document writing policy on the fly. > > You're the one who is arguing for a modification to the *actual* IETF > document > writing policy here. Agreeing with that. >> > The formal syntax use the Augmented Backus-Naur Form (ABNF) >> [RFC5234] >> > notation including the core rules defined in Appendix B of RFC 5234 >> > [RFC5234]. >> > >> > In examples, "C:" and "S:" indicate lines sent by the client and >> > server respectively. Line breaks that do not start with a new "C:" >> > or "S:" exist for editorial reasons and are not a part of the >> > protocol. >> > >> > This document uses the term "priority" specifically in relation to >> > the internal treatment of a message by the server: messages with >> > higher priorities may be given expedited handling, and those with > >> may -> can > > >> > lower priorities may be handled only as resources become available. > >> may -> can > > Again, given the loosey-goosey nature of this document overall, I > don't think > precision is really required, but if it is, both of these changes are > somewhat > objectionable. > > Like it or not, "may" and "can" are *not* synonyms. "Can" is more > assertive, > and carries with it a flavor that's closer to "should", whereas "may" is > expresses a possibilit with no preference. > > We're talking about prioritization methodology here, specifically > expedited > handling and deferred processing. There can be overhead associated > with both of > these, and we should not be encourage the use of these techniques when > it isn't > absolutely necessary. > And yes, I'm being very pedantic here. That's what you're going to get > when > you elect to go down this path.
RSS Feed147 | |
|---|---|
178 | |
179 | |
175 | |
201 | |
266 | |
571 | |
282 | |
487 | |
159 | |
340 | |
316 | |
557 | |
615 | |
395 | |
148 | |
210 | |
164 | |
403 | |
68 | |
104 | |
145 | |
231 | |
121 | |
182 | |
85 | |
148 | |
60 | |
89 | |
104 | |
54 | |
80 | |
101 | |
9 | |
140 | |
44 | |
35 | |
86 | |
29 | |
50 | |
69 | |
67 | |
38 | |
91 | |
41 | |
96 | |
134 | |
129 | |
58 | |
121 | |
107 | |
41 | |
75 | |
11 | |
21 | |
7 | |
39 | |
5 | |
44 | |
34 | |
10 | |
31 | |
7 | |
67 | |
66 | |
76 | |
76 | |
66 | |
61 | |
24 | |
23 | |
75 | |
168 | |
2 | |
6 | |
37 | |
47 | |
1 | |
32 | |
22 | |
22 | |
34 | |
5 | |
5 | |
5 | |
7 | |
1 | |
1 | |
3 | |
4 | |
1 | |
21 | |
9 | |
2 | |
8 | |
11 | |
1 | |
5 | |
4 | |
28 | |
2 |
