New drafts failing to be announced

I have noticed a couple of instances in the last week where new I-Ds have been posted and NOT notified on the I-D announce list: http://www.ietf.org/mail-archive/web/i-d-announce/current/maillist.html These two drafts are not to be found in the archive and I don't recall receiving emails:

Late comment on draft-ietf-sippping-sip-offeranswer-14

I know last call finished already, but the following has just been brought to my attention: In section 5.2.5 Changing the o-line, except version number value, during the session is an error case. The behavior when receiving such a non-compliant offer/answer SDP body is

RE: [siprec] Last Call:draft-ietf-siprec-req-09.txt(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC

(mperumal); Elwell, John; Ram Mohan R (rmohanr); ietf@ietf.org Cc: sip...@ietf.org Subject: RE: [siprec] Last Call:draft-ietf-siprec-req-09.txt(Use CasesandRequirements forSIP-based MediaRecording (SIPREC)) toInformational RFC I agree, we should have dedicated wall clock requirement

RE: [siprec] Last Call: draft-ietf-siprec-req-09.txt(Use Cases andRequirements for SIP-based MediaRecording (SIPREC)) toInformational RFC

The mechanism MUST provide means for relating recordings to wall clock time. John (as individual) -Original Message- From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperu...@cisco.com] Sent: 14 April 2011 21:42 To: Ram Mohan R (rmohanr); Leon Portman; Elwell, John; ietf@ietf.org Cc: sip

RE: [siprec] Last Call: draft-ietf-siprec-req-09.txt (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

-Original Message- From: siprec-boun...@ietf.org [mailto:siprec-boun...@ietf.org] On Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: 14 April 2011 07:34 To: ietf@ietf.org Cc: sip...@ietf.org Subject: Re: [siprec] Last Call: draft-ietf-siprec-req-09.txt (Use Cases

RE: [siprec] Last Call: draft-ietf-siprec-req-09.txt (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC

] Sent: 14 April 2011 13:19 To: Elwell, John; Muthu ArulMozhi Perumal (mperumal); ietf@ietf.org Cc: sip...@ietf.org Subject: RE: [siprec] Last Call: draft-ietf-siprec-req-09.txt (Use Cases andRequirements for SIP-based Media Recording (SIPREC)) toInformational RFC Actually REQ-022 and REQ

RE: IETF Attendance by continent

Agreed. On several evening, the 20 minute walk into the city centre or back provided a refreshing opportunity to talk to somebody whom otherwise I might hardly have spoken to. John -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark

RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC

Just catching up on this discussion, after a period of absence. As chair of the SIP Forum Task Group that carried out this work, I concur with the summary below from Scott and also his various earlier postings answering questions raised on this list - thanks Scott. A further comment below.

RE: Last Call: draft-peterson-rai-rfc3427bis (Change Process for theSession Initiation Protocol (SIP)) to Proposed Standard

The SIPCORE Working Group is required to protect the architectural integrity of SIP and must not add features that do not have general use beyond the specific case. Also, SIPCORE must not add features just to make a particular function more efficient at the expense of simplicity or

RE: [MMUSIC] Last Call: draft-ietf-mmusic-sdp-capability-negotiation(SDP Capability Negotiation) to Proposed Standard

Except in closed situations like 3GPP, how would the UA know whether to insert this new attribute? John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ingemar Johansson S Sent: 07 October 2008 13:38 To: ietf@ietf.org Cc: Flemming Andreasen;