Subject: [marf] Time slot at IETF 78

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Thu, 8 Jul 2010 15:28:29 -0500

Barry,
Murray,

Could you please give us a time slot (10 minutes) at the IETF 78 for presenting the recently-published draft An Extensible Format for SMSC/MMSC Feedback Reports? (The draft is at http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ).

With thanks,

Zachary Zeltsan

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 8 Jul 2010 23:43:40 -0400

Zachary,

Before commenting on the technical aspects, can you tell us the
background for this? Is this part of the OMA or MAAWG efforts, or is
this something that you are submitting privately to the IETF? What is
Alcatel's role here?

Thanks,
Yakov

On Thu, Jul 8, 2010 at 4:28 PM, Zeltsan, Zachary (Zachary)
<[email-masked]> wrote:
> Barry,
> Murray,
>
> Could you please give us a time slot (10 minutes) at the IETF 78 for
> presenting the recently-published draft An Extensible Format for SMSC/MMSC
> Feedback Reports? (The draft is at
> http://datatracker.ietf.org/doc/draft-cai-smsc-mmsc-reporting-marf/ ).
>
> With thanks,
>
> Zachary Zeltsan
>
> _______________________________________________
> marf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/marf
>
>

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 9 Jul 2010 10:15:39 -0500

Yakov,

Moh, who is one of the draft's co-authors, has been involved in the OMA work and is in a better position to answer questions related to the OMA effort. (I have copied this message to Moh).

Zachary

-----Original Message-----
From: Yakov Shafranovich [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 11:44 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Time slot at IETF 78

Zachary,

Thanks,
Yakov

---

From: "Torabi, Mohammad (Moh)" <[email-masked]>
Date: Fri, 9 Jul 2010 10:25:40 -0500

Hi Yakov,
This work is trying to address a gap that is seen in the ongoing work of IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals as is the usual procedure to follow in IETF. However, all authors/contributors are Alcatel-Lucent employees.

Regards,

Moh 

-----Original Message-----
From: Zeltsan, Zachary (Zachary) 
Sent: Friday, July 09, 2010 8:16 AM
To: 'Yakov Shafranovich'
Cc: [email-masked]; Torabi, Mohammad (Moh)
Subject: RE: [marf] Time slot at IETF 78

Yakov,

Zachary

-----Original Message-----
From: Yakov Shafranovich [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 11:44 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Time slot at IETF 78

Zachary,

Thanks,
Yakov

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 9 Jul 2010 11:19:25 -0500

Sent on Moh's behalf...

-----Original Message-----
From: Torabi, Mohammad (Moh) 
Sent: Friday, July 09, 2010 11:26 AM
To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich'
Cc: [email-masked]
Subject: RE: [marf] Time slot at IETF 78

Hi Yakov,

Regards,

Moh 

-----Original Message-----
From: Zeltsan, Zachary (Zachary) 
Sent: Friday, July 09, 2010 8:16 AM
To: 'Yakov Shafranovich'
Cc: [email-masked]; Torabi, Mohammad (Moh)
Subject: RE: [marf] Time slot at IETF 78

Yakov,

Zachary

-----Original Message-----
From: Yakov Shafranovich [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 11:44 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Time slot at IETF 78

Zachary,

Thanks,
Yakov

---

From: "Alex Bobotek" <[email-masked]>
Date: Sat, 10 Jul 2010 19:49:24 -0700

Could someone help explain what gap in OMA SpamRep is addressed by this?

Regards,

Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zeltsan, Zachary (Zachary)
Sent: Friday, July 09, 2010 9:19 AM
To: 'Yakov Shafranovich'
Cc: Torabi, Mohammad (Moh); [email-masked]
Subject: Re: [marf] Time slot at IETF 78

Sent on Moh's behalf...

-----Original Message-----
From: Torabi, Mohammad (Moh) 
Sent: Friday, July 09, 2010 11:26 AM
To: Zeltsan, Zachary (Zachary); 'Yakov Shafranovich'
Cc: [email-masked]
Subject: RE: [marf] Time slot at IETF 78

Hi Yakov,
This work is trying to address a gap that is seen in the ongoing work of
IETF's MARF and OMA's SpamRep WA. The draft is submitted by individuals
as is the usual procedure to follow in IETF. However, all
authors/contributors are Alcatel-Lucent employees.

Regards,

Moh 

-----Original Message-----
From: Zeltsan, Zachary (Zachary) 
Sent: Friday, July 09, 2010 8:16 AM
To: 'Yakov Shafranovich'
Cc: [email-masked]; Torabi, Mohammad (Moh)
Subject: RE: [marf] Time slot at IETF 78

Yakov,

Moh, who is one of the draft's co-authors, has been involved in the OMA
work and is in a better position to answer questions related to the OMA
effort. (I have copied this message to Moh).

Zachary

-----Original Message-----
From: Yakov Shafranovich [mailto:[email-masked]] 
Sent: Thursday, July 08, 2010 11:44 PM
To: Zeltsan, Zachary (Zachary)
Cc: [email-masked]
Subject: Re: [marf] Time slot at IETF 78

Zachary,

Thanks,
Yakov

---

From: "Torabi, Mohammad (Moh)" <[email-masked]>
Date: Tue, 13 Jul 2010 09:07:49 -0500

There are two areas of work and this draft to fill some gaps in these two areas: OMA SpamRep, IETF MARF and this Draft proposal:

1.         OMA Work Area

OMA draft of "Mobile Spam Reporting Technical Specification" (OMA-TS-SpamRep-V1_0-20100601-D) defines spam reporting (SpamRep) messages between client and server. It provides a capability wherein media content that is received on a device can be designated, either by the user or automatically by the SpamRep client, as Spam and a report containing information about the Spam message is sent to a Server for further processing. Furthermore, the work and the protocol are applicable to email, SMS, MMS and IM message spam reporting from end user device to/from the server. However, it does not specify the spam reporting from a message center (email server, email gateway, SMSC, MMSC, web portal, and other applications). This is an area that market (operators/service providers) may be interested in. Furthermore, the OMA work does not address how to carry SpamRep XML Document in existing mobile protocols from mobile device to/from the server - SIP, MAP, SMPP, etc.

2.         IETF Work Area

IETF has produced two drafts so far on the subject: draft-ietf-marf-base-06 & draft-ietf-marf-dkim-reporting-00.

draft-ietf-marf-base-06: This draft specifies an email spam reporting/feedback protocol and attributes from email operator/server when discovering either incoming or outgoing email suspicious. However, it does not address spam reporting from end user or end user device. Furthermore, it does not cover other message types (SMS, MMS, IM)

draft-ietf-marf-dkim-reporting-00: This draft presents an extension to the DomainKeys Identified Mail (DKIM) specifications to allow public keys for verification to include a reporting address to be used for reporting message verification issues. It extends an Internet Message reporting format to be followed when generating such reports. It also extends MARF-Base to add features required for DKIM reporting.

3. Our proposal (draft-cai-smsc-mmsc-reporting-marf-00.txt)

This proposal (to IETF MARF in IETF 78) addresses one area of gap and that is for the message centers, SMSC and MMSC spam reporting, to filter and detect spam messages (machine only) and report them to network spam control server. This draft will be an extent to MARF's Base Draft. It defines an extensible format and MIME type that may be used by SMSC or MMSC to report feedback about received SMS and MMS with message abuses.

-M

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: Saturday, July 10, 2010 7:49 PM
To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)
Cc: [email-masked]
Subject: RE: [marf] Time slot at IETF 78

Regards,

Alex

-----Original Message-----

To: 'Yakov Shafranovich'

Sent on Moh's behalf...

-----Original Message-----

Cc: [email-masked]

Hi Yakov,

Regards,

Moh

-----Original Message-----

To: 'Yakov Shafranovich'

Yakov,

Zachary

-----Original Message-----

Cc: [email-masked]

Zachary,

Alcatel's role here?

Thanks,

Yakov

> presenting the recently-published draft An Extensible Format for

SMSC/MMSC

marf mailing list

[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jul 2010 10:32:06 -0700

Hello Mohammad,

I disagree with the first argument presented in (1) below.  SpamRep defines the format for reporting from a SpamRep Client to a SpamRep Server.  It doesn't stipulate what specific devices those are.  There's nothing in SpamRep that stipulates, for example, that a SpamRep Client could not be an email server, email gateway, SMSC, MMSC, web portal, or any other application.  It simply names the two roles for the purposes of specifying what to send and expect in the same way RFC5321 says the client uses four-letter verbs as commands and the server uses three-digit numbers as replies.

Transport is a separate issue.  SpamRep mandates use of HTTP POST as its transport, which seems to be a reasonable first approach especially since the payload will usually be large and the usable space of an SMPP message is rather small.  That said, one could propose a supplemental transport mechanism that deals with fragmentation and reassembly of a SpamRep report into pieces that fit inside a batch of SMPP messages.  This is a whole other work area though, and one could argue that it "belongs" to OMA and not IETF.

Given the scope you're attempting to cover in (3) below, perhaps a faster route forward would be to make a draft that updates draft-ietf-marf-base to permit the third MIME part to be of the MIME type defined by SpamRep.  That MIME type already covers the ability to report on SMS and MMS spam, and would use MARF (and thus email) as the transport.  It seems to me that would cover all of your requirements except for the transport one discussed above.

-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Torabi, Mohammad (Moh)
Sent: Tuesday, July 13, 2010 7:08 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: Re: [marf] Time slot at IETF 78

1.         OMA Work Area

2.         IETF Work Area

-M

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: Saturday, July 10, 2010 7:49 PM
To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)
Cc: [email-masked]
Subject: RE: [marf] Time slot at IETF 78

Regards,

Alex

-----Original Message-----

To: 'Yakov Shafranovich'

Sent on Moh's behalf...

-----Original Message-----

Cc: [email-masked]

Hi Yakov,

Regards,

Moh

-----Original Message-----

To: 'Yakov Shafranovich'

Yakov,

Zachary

-----Original Message-----

Cc: [email-masked]

Zachary,

Alcatel's role here?

Thanks,

Yakov

SMSC/MMSC

marf mailing list

[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 Jul 2010 19:15:47 -0400

What is the MIME type defined by SpamRep?

On Tue, Jul 13, 2010 at 1:32 PM, Murray S. Kucherawy <[email-masked]> wrote:
> Hello Mohammad,
>
>
>
> I disagree with the first argument presented in (1) below.  SpamRep defines
> the format for reporting from a SpamRep Client to a SpamRep Server.  It
> doesn’t stipulate what specific devices those are.  There’s nothing in
> SpamRep that stipulates, for example, that a SpamRep Client could not be an
> email server, email gateway, SMSC, MMSC, web portal, or any other
> application.  It simply names the two roles for the purposes of specifying
> what to send and expect in the same way RFC5321 says the client uses
> four-letter verbs as commands and the server uses three-digit numbers as
> replies.
>
>
>
> Transport is a separate issue.  SpamRep mandates use of HTTP POST as its
> transport, which seems to be a reasonable first approach especially since
> the payload will usually be large and the usable space of an SMPP message is
> rather small.  That said, one could propose a supplemental transport
> mechanism that deals with fragmentation and reassembly of a SpamRep report
> into pieces that fit inside a batch of SMPP messages.  This is a whole other
> work area though, and one could argue that it “belongs” to OMA and not IETF.
>
>
>
> Given the scope you’re attempting to cover in (3) below, perhaps a faster
> route forward would be to make a draft that updates draft-ietf-marf-base to
> permit the third MIME part to be of the MIME type defined by SpamRep.  That
> MIME type already covers the ability to report on SMS and MMS spam, and
> would use MARF (and thus email) as the transport.  It seems to me that would
> cover all of your requirements except for the transport one discussed above.
>
>
>
> -MSK
>
>
>
>
>
> Torabi, Mohammad (Moh)
> There are two areas of work and this draft to fill some gaps in these two
> areas: OMA SpamRep, IETF MARF and this Draft proposal:
>
> 1.         OMA Work Area
>
> OMA draft of “Mobile Spam Reporting Technical Specification”
> (OMA-TS-SpamRep-V1_0-20100601-D) defines spam reporting (SpamRep) messages
> between client and server. It provides a capability wherein media content
> that is received on a device can be designated, either by the user or
> automatically by the SpamRep client, as Spam and a report containing
> information about the Spam message is sent to a Server for further
> processing. Furthermore, the work and the protocol are applicable to email,
> SMS, MMS and IM message spam reporting from end user device to/from the
> server. However, it does not specify the spam reporting from a message
> center (email server, email gateway, SMSC, MMSC, web portal, and other
> applications). This is an area that market (operators/service providers) may
> be interested in. Furthermore, the OMA work does not address how to carry
> SpamRep XML Document in existing mobile protocols from mobile device to/from
> the server – SIP, MAP, SMPP, etc.
>
>
>
> 2.         IETF Work Area
>
> draft-ietf-marf-base-06: This draft specifies an email spam
> reporting/feedback protocol and attributes from email operator/server when
> discovering either incoming or outgoing email suspicious. However, it does
> not address spam reporting from end user or end user device. Furthermore, it
> does not cover other message types (SMS, MMS, IM)
>
> draft-ietf-marf-dkim-reporting-00: This draft presents an extension to the
> DomainKeys Identified Mail (DKIM) specifications to allow public keys for
> verification to include a reporting address to be used for reporting message
> verification issues. It extends an Internet Message reporting format to be
> followed when generating such reports. It also extends MARF-Base to add
> features required for DKIM reporting.
>
>
>
> This proposal (to IETF MARF in IETF 78) addresses one area of gap and that
> is for the message centers, SMSC and MMSC spam reporting, to filter and
> detect spam messages (machine only) and report them to network spam control
> server. This draft will be an extent to MARF’s Base Draft. It defines an
> extensible format and MIME type that may be used by SMSC or MMSC to report
> feedback about received SMS and MMS with message abuses.
>
>
>
> -M
>
>
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Jul 2010 22:41:54 -0700

"application/vnd.oma.spamrep+xml".  There are no I-Ds for it yet, but I believe the current technical specifications that define it are public:

http://member.openmobilealliance.org/ftp/Public_documents/COM/COM-SpamRep/Permanent_documents/OMA-TS-SpamRep-V1_0-20100708-D.zip
________________________________________
From: Yakov Shafranovich [[email-masked]]
Sent: Tuesday, July 13, 2010 4:15 PM
To: Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [marf] Time slot at IETF 78

---

From: "Cai, Yigang (Yigang)" <[email-masked]>
Date: Fri, 16 Jul 2010 16:22:32 -0500

Moh,

Please see my responses on Murry's comments.

Yigang

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, July 13, 2010 12:32 PM
To: Torabi, Mohammad (Moh); [email-masked]'
Cc: [email-masked]'
Subject: Re: [marf] Time slot at IETF 78

Hello Mohammad,

I disagree with the first argument presented in (1) below.  SpamRep defines the format for reporting from a SpamRep Client to a SpamRep Server.  It doesn't stipulate what specific devices those are.  There's nothing in SpamRep that stipulates, for example, that a SpamRep Client could not be an email server, email gateway, SMSC, MMSC, web portal, or any other application.  It simply names the two roles for the purposes of specifying what to send and expect in the same way RFC5321 says the client uses four-letter verbs as commands and the server uses three-digit numbers as replies.
[Cai, Yigang (Yigang)] He is right. I will modify my analysis of gaps.

Transport is a separate issue.  SpamRep mandates use of HTTP POST as its transport, which seems to be a reasonable first approach especially since the payload will usually be large and the usable space of an SMPP message is rather small.  That said, one could propose a supplemental transport mechanism that deals with fragmentation and reassembly of a SpamRep report into pieces that fit inside a batch of SMPP messages.  This is a whole other work area though, and one could argue that it "belongs" to OMA and not IETF.
[Cai, Yigang (Yigang)] Actually our products do not care of transports, either way work for us.

Given the scope you're attempting to cover in (3) below, perhaps a faster route forward would be to make a draft that updates draft-ietf-marf-base to permit the third MIME part to be of the MIME type defined by SpamRep.  That MIME type already covers the ability to report on SMS and MMS spam, and would use MARF (and thus email) as the transport.  It seems to me that would cover all of your requirements except for the transport one discussed above.
[Cai, Yigang (Yigang)] I don't understand his point here. We would like to re-use MIME type in MARF. But I will re-study them.

-MSK

1.         OMA Work Area

2.         IETF Work Area

-M

-----Original Message-----
From: Alex Bobotek [mailto:[email-masked]]
Sent: Saturday, July 10, 2010 7:49 PM
To: Zeltsan, Zachary (Zachary); Yakov Shafranovich; Torabi, Mohammad (Moh)
Cc: [email-masked]
Subject: RE: [marf] Time slot at IETF 78

Regards,

Alex

-----Original Message-----

To: 'Yakov Shafranovich'

Sent on Moh's behalf...

-----Original Message-----

Cc: [email-masked]

Hi Yakov,

Regards,

Moh

-----Original Message-----

To: 'Yakov Shafranovich'

Yakov,

Zachary

-----Original Message-----

Cc: [email-masked]

Zachary,

Alcatel's role here?

Thanks,

Yakov

SMSC/MMSC

marf mailing list

[email-masked]