Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-marf draft at MARF IETF 78

From: Jeff Macdonald <[email-masked]>
Date: Wed, 1 Sep 2010 10:35:57 -0400

On Wed, Sep 1, 2010 at 2:35 AM, Alex Bobotek <[email-masked]> wrote:

<snip>

> Here's some information that has led me to the above conclusion:
>
> At IETF78.MARF, I recall hearing that:
>   * marf-base (now an RFC) is in use by probably around 25 companies

nice!

>   * many people stand up and assert that XML is a better choice
> technically

It depends on the data. If MARF data is really complex and has tree
like characteristics, then ok. But I don't think it is. XML seems like
overkill to me.

>   * nobody suggest that unstructured name-value pairs (a la email
> headers) are best

well, I was on vacation, so I do think they are adequate for the job at hand.

> OMA SpamRep is working towards IETF convergence.  It has changed to
> adopt the multipart/report MIME structure which, in its simple form, is
> nearly that of marf-base, providing an XML encoded second part.

So doing a HTTP post has been abandoned? Where can I find the latest
drafts again?

-- 
Jeff Macdonald
Ayer, MA

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Sep 2010 09:43:01 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jeff Macdonald
> Sent: Wednesday, September 01, 2010 7:36 AM
> To: [email-masked]
> Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-
> marf draft at MARF IETF 78
> 

You're confusing format with transport.  It's still HTTP POST of an XML document.

---

From: "Alex Bobotek" <[email-masked]>
Date: Wed, 1 Sep 2010 09:51:23 -0700

I agree that XML becomes advantageous and eventually compelling when structure beyond a simple list of names/values is needed, and _may_ introduce unneeded complexity.  In some cases an implementer might find either name/value or XML simpler due to its syntax checks, error handling, etc handled by their tools and libraries.  IMHO, we're well past the point of 'advantage XML' -- consider the complexity of parsing trace headers and how structure would simplify this.  

RFC2965 does not specify transport, only format.  SpamRep specifies both. Currently SpamRep specifies HTTP, but for most SpamRep messages, either SMTP or HTTP would work.  SpamRep is not moving away from HTTP, but could be trimmed and adapted (for email) to SMTP transport.  Personally, I'm not happy with the lack of layer separation in RFC2965 - the reporter is generally assumed to be the sender (Mail From  or From) of the doc - .  

http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permanent_documents contains all the draft versions of the SpamRep spec.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff Macdonald
Sent: Wednesday, September 01, 2010 7:36 AM
To: [email-masked]
Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-marf draft at MARF IETF 78

<snip>

nice!

-- 
Jeff Macdonald
Ayer, MA
_______________________________________________
marf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/marf

---

From: "Cai, Yigang (Yigang)" <[email-masked]>
Date: Wed, 1 Sep 2010 13:36:37 -0500

Yakov,

Thank a lot!

The draft-cai-smsc-mmsc-reporting-marf draft at MARF IETF 78 has some overlap with OMA SpamRep, but the draft contains important part of SMS/MMS abuse reporting info, such as abuse detection information and additional optional spam reporting attributes for SMS/MMS. 

Alex's document of OMA SpamRep revision sent last Monday focused in reporting format (HTTP/XML/MIME). 

Alex pointed out in his email today that IETF/MARF has two ways to process SMS/MMS from the draft-cai-smsc-mmsc-reporting-marf draft, i.e.,
1) Update OMA SpamRep with this draft, then MARF turns the resulting OMA spec into an RFC
2) Proceed along the lines of draft-cai-smsc-mmsc-reporting-marf

Since the content of SMS/MMS abuse reporting is format independent, and the reported attributes we proposed are critical important to many tier 1 operators we contacted, we would suggest IETF/MARF to proceed the draft-cai-smsc-mmsc-reporting-marf. We can make modification so it will be reporting format independent.

Thanks,

Yigang

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yakov Shafranovich
Sent: Tuesday, August 31, 2010 4:09 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-marf draft at MARF IETF 78

Can't speak for the rest of the WG, but my personal opinion that with sufficient work, we can converge. However - how does this draft play with the OMA draft presented by Alex?

Yakov

On Tue, Aug 31, 2010 at 5:06 PM, Zeltsan, Zachary (Zachary) <[email-masked]> wrote:
> The draft draft-cai-smsc-mmsc-reporting-marf was on the agenda and was 
> presented at the IETF 78. The meeting minutes 
> (http://www.ietf.org/proceedings/78/minutes/marf.txt), however, do not 
> reflect this.
> In my opinion the main proposal of the draft - extending MARF to 
> support the reports on abuse of the SMS and MMS messages - did not 
> meet any strong objections and generated some interest at the meeting.
>
> Is the WG interested in the proposed extension to MARF?
>
> Zachary
>
>

---

From: Kevin Zeng <[email-masked]>
Date: Wed, 01 Sep 2010 14:05:21 -0500

I will sign up for the 1st path described by Alex below.
Thanks.

-Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alex
Bobotek
Sent: Wednesday, September 01, 2010 1:36 AM
To: Yakov Shafranovich; Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-marf
draft at MARF IETF 78

In my view, IETF (e.g., MARF) should be working on standards that extend
the function of MARF to support more messaging formats and protocols.
There are several ways to proceed for SMS/MMS, including:

1.  Let OMA continue with SpamRep (which has SMSC/MMSC reporting within
its scope), and 
    turn the resulting OMA spec into an RFC.  Murray and I have both
announced our 
    interest and willingness to make major contributions towards this.  
2.  Proceed along the lines of draft-cai-smsc-mmsc-reporting-marf.

In my opinion, #1 is the right path.  And there is much momentum along
this route.  IMHO, the two standards and encodings could easily converge
interoperably in practice by having servers accept either format and/or
by allowing the client to send a message containing both XML and
name/value (e.g., with the second part being a multipart/alternative).

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yakov Shafranovich
Sent: Tuesday, August 31, 2010 2:09 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Discussion of the draft-cai-smsc-mmsc-reporting-marf
draft at MARF IETF 78

Can't speak for the rest of the WG, but my personal opinion that with
sufficient work, we can converge. However - how does this draft play
with the OMA draft presented by Alex?

Yakov

> In my opinion the main proposal of the draft - extending MARF to
support the
> reports on abuse of the SMS and MMS messages - did not meet any strong
> objections and generated some interest at the meeting.
>

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 1 Sep 2010 15:36:28 -0700

> the function of MARF to support more messaging formats and protocols.

Agreed, that's a logical thing to do now that marf-base is done.

>    interest and willingness to make major contributions towards this.  

I think this makes the most sense.  It looks like OMA has the right people/companies involved to be able to get SpamRep implemented and tested in the real world.  And, with you and Murray participating, I have no doubt that whatever the OMA develops will stay compatible with MARF-BASE.

> 2.  Proceed along the lines of draft-cai-smsc-mmsc-reporting-marf.

Reading through draft-cai-smsc-mmsc-reporting-marf, it looks like there are only a few concepts which aren't in the OMA document.  Given that all of the listed authors are employed by an OMA sponsor member, is it possible that these could be discussed within OMA and perhaps added to SpamRep?

If not, I think the only thing the MARF WG can do is wait to see which of the competing proposals gets implemented by the mobile carriers & vendors.

>   * marf-base (now an RFC) is in use by probably around 25 companies

Far more than that!  Across the complaint feedback loops that Return Path operates on behalf of various mailbox providers, there are 19320 unique domain names (RHS) in the email addresses that the reports are sent to.  I don't know how many use the same ARF-reading code, or indeed any ARF-reading software at all, but these all count as Report Consumers.

>   * nobody suggest that unstructured name-value pairs (a la email

Except that there's actually already a very large installed base.

---

From: Shmuel (Seymour J.) Metz <[email-masked]>
Date: Thu, 02 Sep 2010 09:19:48 -0400

In
<[email-masked]>,
on 08/31/2010
   at 04:06 PM, "Zeltsan, Zachary (Zachary)"
<[email-masked]> said:

>draft-cai-smsc-mmsc-reporting-marf

Reference to draft-ietf-marf-base should now be to RFC 5965.

>Is the WG interested in the proposed extension to MARF?

I see convergence as a good thing. I also believe that there should be
standards for recipient reporting of e-mail spam and discovery for
those senders accepting formatted reports from individual recipients
coordinated with the work currently in progress.

One question that should be addressed is how much leeway the working
group has in the event of conflict between IETF and MAAWG
requirements.

-- 
     Shmuel (Seymour J.) Metz, SysProg and JOAT
     Atid/2        <http://patriot.net/~shmuel>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 2 Sep 2010 11:21:13 -0400

On Wed, Sep 1, 2010 at 12:43 PM, Murray S. Kucherawy <[email-masked]> wrote:
> You're confusing format with transport.

Um, no. But I can see how you came to that conclusion. I've never seen
a POST with multipart/report MIME structure before, thus the query. I
obviously need to read the latest drafts.

-- 
Jeff Macdonald
Ayer, MA

---

From: "Alex Bobotek" <[email-masked]>
Date: Thu, 2 Sep 2010 11:43:31 -0700

We'll be seeing POSTs with multipart/report from SpamRep.  It's the outermost MIME structure in the OMA SpamRep technical specification.  

Regards,

Alex