headers
apps-discuss | 1 Aug 21:25
Picon
Favicon

Confirm: apps-discuss <at> ietf.org:paPm0MSJNjHQ:ehLRL5FomOjfedYTwRk7EJ5A61L7sq7yBsYCCA


Confirmation of list posting -- confirmation ID: paPm0MSJNjHQ

The ietf.org mailing-list server has received a list posting from 
gia-discuss <at> m.gmane.org to apps-discuss <at> ietf.org with the subject 
'Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt'

As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address.
To confirm the address, send a message to apps-discuss <at> ietf.org,
with the same subject line as this message.

(Simply sending a 'reply' to this message should work from most email
interfaces, since that usually leaves the subject line in the right
form.  The reply's additional "Re:" is ok.)

If you do not wish your posting to the list to go through, simply
disregard this message.  Questions to postmaster <at> ietf.org.
Permalink | Reply | 0 comments |
headers
Frank Ellermann | 1 Aug 21:26
Picon
Picon

Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt

Kurt Zeilenga wrote on the SASL list:

> 1) revise the CRAM-MD5 specification, resolving known technical  
> issues, such that it is suitable for progression (eventually all
> the way to Internet Standard) on the Standards Track,
> 2) seek a waiver from the IESG of certain requirements placed upon  
> SASL mechanism specifications (such as RFC 4422 requirement that
> mechanism specifications detail how character data inputs to
> cryptographic functions be precisely specified to ensure
> interoperability), or
> 3) documenting existing CRAM-MD5 practice in an Informational  
> document, noting the known technical issues.

> Consensus has been, and continued to be, that fixing known technical
> issues would be too disruptive to existing deployments (which as you  
> note are quite significant).  With this consensus, the third path  
> seems quite appropriate as seems to make no sense to progress a  
> document on the standard track that you wouldn't put on the standards  
> track if considered anew.

Objection:  There are various protocols such as SMTP and HTTP that
would be not "put on the standards track if considered anew" as is,
where they disagree with RFC 2277 and UTF-8.  HTTP has a charming
default Latin-1, while at it overriding MIME text/* in weird ways.

This is a red herring.  RFC 2026 demands maturity, IMO it does not
ask "would you do this again exactly as is now, six years later ?".

RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
If implementations do something that is not specified it is their
(Continue reading)

Permalink | Reply | 6 comments |
headers
Kurt Zeilenga | 12 Aug 04:52
Favicon

Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt


On 1 Aug 2008, at 12:26 PM, Frank Ellermann wrote:

> This is a red herring.  RFC 2026 demands maturity, IMO it does not
> ask "would you do this again exactly as is now, six years later ?".

I would argue that what RFC 2026 demands specifications which  
developers can independently produce interoperable implementations from.

When I said "considered anew", I didn't mean "would we do this again  
exactly as we before".  What I mean was that a document shouldn't get  
a bye from currently in place requirements simply because it was  
originally engineered before those requirements were in place.   And  
while we do now have a "use UTF-8" requirement in IETF protocols, that  
doesn't necessarily mean that non-UTF-8 character data fields in  
fields should be respecified as carrying UTF-8 character data.   There  
are other approaches for providing internationalization in existing  
protocols (such as taken in IDN), and then there is the approach of  
replacing the old protocol with a new protocol that has adequate  
internationalization.

While my discussion above utilizes i18n issues, the I-Ds failure to  
met requirements placed upon it are not believed to be limited to i18n  
issues.

> RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
> If implementations do something that is not specified it is their
> problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
> choice of "something" they also own the pieces of whatever breaks.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kurt Zeilenga | 12 Aug 05:18
Favicon

Re: I-D ACTION:draft-ietf-sasl-crammd5-10.txt


On 11 Aug 2008, at 7:52 PM, Kurt Zeilenga wrote:

>>
>> RFC 2195 uses an RFC 822 Message-ID as challenge, that is US-ASCII.
>> If implementations do something that is not specified it is their
>> problem.  If they ignored RFC 2277 and didn't pick UTF-8 for their
>> choice of "something" they also own the pieces of whatever breaks.
>
> I see reason why an implementor of RFC 2195 would read RFC 2277, and  
> if they did, why they would take its statements as imparting any  
> requirement upon implementations of any protocol.   RFC 2277  
> discussions requirements upon technical specifications produced by  
> the IETF, not requirements upon implementors of IETF produced  
> technical specifications.

s/see/see no/

Sorry, Kurt
Permalink | Reply | 0 comments |
headers
Kurt Zeilenga | 22 Aug 01:09
Favicon

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

Given http://www.ietf.org/meetings/73/ says:

> IETF Meetings start Monday morning and run through Friday lunchtime,  
> with late scheduling changes. Newcomers' training and technical  
> tutorials take place the previous Sunday afternoon. Participants  
> should plan their travel accordingly.

I assume this proposed experiment will not be taking place.

-- Kurt
Permalink | Reply | 0 comments |

Gmane